×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

number limit
2

number limit

number limit

(OP)
i'm doing a calcul program and when i'm multipliing or divising number a get a number with an exposant.  ex:1283450E+2. or 1.002344E-3 there is a way to allow variable to get more digits.
tanx in advance

miguel
migoul@hotmail.com
QBasic page (not been updated recently)

RE: number limit

typically not, normally when you get exponitial increases there is just too much data for it to handle, and requires representing it that way, so even if you tried to increase the decimal range, you would just end up with zeros on all the parts you didnt see before, by the way what type are you storing it in? Also have you looked at the print using# in the help file, I hear it has some pretty usefull options in formating your output.

Karl
kb244@kb244.com

Experienced in : C++(both VC++ and Borland),VB1(dos) thru VB6, Delphi 3 pro, HTML, Visual InterDev 6(ASP(WebProgramming/Vbscript)
http://www.brainbench.com/transcript.jsp?pid=629151

RE: number limit

A dear genius friend of mine, recently deceased, wrote a BASIC program to find all of the prime numbers (an impossible task, obviously). The program was printing out numbers more than a hundred digits in length on the day that he died.

I had asked him how he managed to get his rather primitive computer to handle numbers that large and he told me it was easy "You just do it one digit at a time."

If you have two very large numbers (say 10 to 100 digits) convert them into strings and do the math one digit at a time. Try this: grab a piece of paper and a pencil. Write down two large numbers and start multiplying them by hand.

Watch your hand and your brain. Your program will have to duplicate those steps.





A plain black box

RE: number limit

may I ask how you asked him that question, or was it prior to death?

Karl
kb244@kb244.com

Experienced in : C++(both VC++ and Borland),VB1(dos) thru VB6, Delphi 3 pro, HTML, Visual InterDev 6(ASP(WebProgramming/Vbscript)
http://www.brainbench.com/transcript.jsp?pid=629151

RE: number limit

Here's an example of the BASIC math my friend told me about. The task here is to simply add two numbers and print the result.
It wouldn't take a huge leap of imagination to apply the method to subtraction, multiplication or division.

'Start with two rather large numbers. These numbers can be almost any size as long as they and the resulting "Answer" string don't exceed the string limitations imposed by Qbasic.

CLS
Num1$ = "5882451358123631651151861331133779121514779413347"
Num2$ = "819447512325887801515201452014235892514689231"
IF LEN(Num2$) > LEN(Num1$) THEN
    Num1$ = STRING$(LEN(Num2$) - LEN(Num1$), "0") + Num1$
END IF
IF LEN(Num1$) > LEN(Num2$) THEN
    Num2$ = STRING$(LEN(Num1$) - LEN(Num2$), "0") + Num2$
END IF
Carry$ = "0"
FOR R = LEN(Num2$) TO 1 STEP -1
    A$ = LTRIM$(STR$(VAL(MID$(Num1$, R, 1)) +  _
    VAL(MID$(Num2$, R, 1)) + VAL(Carry$)))
    IF LEN(A$) > 1 THEN
    Carry$ = LEFT$(A$, 1)
    ELSE
    Carry$ = "0"
    END IF
    Answer$ = RIGHT$(A$, 1) + Answer$
NEXT
PRINT "  "; Num1$
PRINT "+ "; Num2$
PRINT "  "; STRING$(LEN(Num2$), "-")
PRINT "  "; Answer$
PRINT : PRINT "...OR..."
PRINT VAL(Num1$) + VAL(Num2$)

The concept of applying this method to a routine that finds and stores 100-digit prime numbers is way beyond my simple grasp of math but, someday, another bored programmer will attempt it on a Commodore 64 and, perhaps, inspire the rest of us the way Paul inspired me.

And Karl... your question... well I think you can figure that one out.



A plain black box

RE: number limit

Alt255 --

That is the most ingenious way I have ever seen it done.  I've never really conseptulized seeing beyond the QB limits.  But that is something.




Secrete of life: If Husband = Happy then Wife = Unhappy. If Wife = Happy then Husband = Unhappy. If Parents = Happy then Kids = Unhappy. If Kids = Happy then Parents = Unhappy.

RE: number limit

Your code works great, but you should add this line to it right before all the print statements:

IF Carry$<>"0" then Answer$=Carry$+Answer$

This checks to see if the numbers carried over one more place.

RE: number limit

DOH! I missed that one, Rogue2. My code only works if one of the numbers has more digits than the other or the sum of the left-most digits plus the carry is less than ten. You could check for Carry$ <> "0" or add a "0" at the beginning of both numbers. But your solution is much more efficient.

I've thought about using Paul's "string math" to perform some truly astronomical calculations but, of course, realized that the use of this simple addition function would require a full compliment of other math functions to be useful. I tried to create a MULTIPLYhugeNumXhugeNum(Num1$, Num2$) function and caught myself trying to add X to X, Y number of times. Not very efficient (but a good example of the way my math-deprived brain performs multiplication... using my fingers as markers. My function mirrored the movements of my fingers.)

Has anybody thought of a reliable way to multiply a thousand-digit number by a two-digit number? I know it can be done.

Thanks in advance,
Alt255




A plain black box

RE: number limit

Here's a suppliment to the quest for "huge number" QB math. The Multiply$ function listed here multiplies the values in Num1$ and Num2$ and prints a 100-digit solution.
I'm sorry if I couldn't use my calculator to verify the accuracy. <grin>

DEFINT A-Z
DECLARE FUNCTION Multiply$ (Num1$, Num2$)
CLS

Num1$ = "583416511508123631651151861331133779121514779413347"
Num2$ = "4357489407512325887801515201452014235892514689231"

PRINT Multiply$(Num1$, Num2$)
PRINT : PRINT "...or settle for..."
PRINT VAL(Num1$) * VAL(Num2$)

FUNCTION Multiply$ (Num1$, Num2$)

'Format the number strings so they'll be easy to use...
IF LEN(Num2$) > LEN(Num1$) THEN
    Num1$ = STRING$(LEN(Num2$) - LEN(Num1$), "0") + Num1$
END IF
IF LEN(Num1$) > LEN(Num2$) THEN
    Num2$ = STRING$(LEN(Num1$) - LEN(Num2$), "0") + Num2$
END IF
Num1$ = "0" + Num1$: Num2$ = "0" + Num2$: Carry$ = "0"

'Loop through the digits of the first number
FOR R2 = LEN(Num2$) TO 1 STEP -1
    Temp2$ = Answer$: Answer$ = ""
    Temp1$ = STRING$(ABS(R2 - LEN(Num2$)), "0")
    IF MID$(Num2$, R2, 1) <> "0" THEN

    'If we aren't trying to multipy by zero then
    'loop through the digits of the second number.
        FOR R1 = LEN(Num1$) TO 1 STEP -1
            A$ = LTRIM$(STR$(VAL(MID$(Num1$, R1, 1)) * VAL(MID$(Num2$, R2, 1)) + VAL(Carry$)))
            IF LEN(A$) > 1 THEN
                Carry$ = LEFT$(A$, 1)
            ELSE
                Carry$ = "0"
            END IF
            Temp1$ = RIGHT$(A$, 1) + Temp1$
        NEXT
    END IF

    'Format the temporary number strings for easy of use
    IF LEN(Temp2$) > LEN(Temp1$) THEN
        Temp1$ = STRING$(LEN(Temp2$) - LEN(Temp1$), "0") + Temp1$
    END IF
    IF LEN(Temp1$) > LEN(Temp2$) THEN
        Temp2$ = STRING$(LEN(Temp1$) - LEN(Temp2$), "0") + Temp2$
    END IF
    Temp1$ = "0" + Temp1$: Temp2$ = "0" + Temp2$: Carry$ = "0"

    'Add the temporary strings together
    FOR R = LEN(Temp2$) TO 1 STEP -1
        A$ = LTRIM$(STR$(VAL(MID$(Temp1$, R, 1)) + VAL(MID$(Temp2$, R, 1)) + VAL(Carry$)))
        IF LEN(A$) > 1 THEN
            Carry$ = LEFT$(A$, 1)
        ELSE
            Carry$ = "0"
        END IF
        Answer$ = RIGHT$(A$, 1) + Answer$
    NEXT
NEXT

'Strip off the leading zeros...

FOR Re = 1 TO LEN(Answer$)
    IF MID$(Answer$, Re, 1) <> "0" THEN
        Answer$ = RIGHT$(Answer$, LEN(Answer$) - Re + 1)
        EXIT FOR
    END IF
NEXT

Multiply$ = Answer$

'This is your 100-digit answer.
'It should require a fraction of a second on modern systems but I would hate to try it with two 4000-digit numbers. You might have to wait a while... go out for dinner and a movie.

END FUNCTION




A plain black box

RE: number limit

Hey Alt255,

Here's my version of Large Multiply. (note I constructed around your request of having 1000 digits times by 2 digits.  But then I thought why limit to 2? So I've increased the input to receive 5 instead.

(1000 (numbers) * 5 digits)

And, as you said, sorry if I don't acutally use a calculator to verify accuracy. <smile>

----<program code>----
'generate 1000 psudoe numbers and store in String X$
RANDOMIZE (TIMER)
CLS
FOR Cycle = 1 TO 1000
    PsNum$ = LTRIM$(STR$(INT(RND * 9)))
    MigNum1$ = MigNum1$ + PsNum$
    CLS
    PRINT MigNum1$
    'FOR SlowDown = 1 TO 10000: NEXT
NEXT



'show number
CLS
PRINT "numbers generated for multiplication:"
PRINT MigNum1$



'prove len
PRINT
PRINT "number of digits above:"; LEN(MigNum1$)

'prove Exp: E+/D+
PRINT
PRINT "Exponetion # is :"; VAL(MigNum1$)
SLEEP 2


'get upto 5 digits to Multiply by
PRINT
INPUT "Enter up to 5 digits to times by: ", MigNum2$
IF LEN(MigNum2$) > 5 THEN MigNum2$ = RIGHT$(MigNum2$, 5)



'create arrays & store "0"s to end
DIM MigTemp$(LEN(MigNum2$))
IF UBOUND(MigTemp$) >= 2 THEN
    FOR LowSect = LEN(MigNum2$) TO 2 STEP -1
        MigTemp$(LowSect) = STRING$(LowSect - 1, "0")
    NEXT LowSect
END IF



MultiplySection:
FOR LowSect = LEN(MigNum2$) TO 1 STEP -1
    WorkLowNum = VAL(MID$(MigNum2$, LowSect, 1))
    CarryOvr = 0
    Array = LowSect
    FOR HighSect = LEN(MigNum1$) TO 1 STEP -1
        WorkHighNum = VAL(MID$(MigNum1$, HighSect, 1))


'---Multiply and add stuff---
        WorkResult = (WorkLowNum * WorkHighNum) + CarryOvr

'---logic routines---
        IF LEN(LTRIM$(STR$(WorkResult))) = 2 THEN         'Max 9x9=81
            MigTemp$(Array) = RIGHT$(LTRIM$(STR$(WorkResult)), 1) + MigTemp$(Array)
            CarryOvr = VAL(LEFT$(LTRIM$(STR$(WorkResult)), 1))
        ELSEIF LEN(LTRIM$(STR$(WorkResult))) = 1 THEN     'Min 1x9=9 & 1x0=0
            MigTemp$(Array) = LTRIM$(STR$(WorkResult)) + MigTemp$(Array)
            CarryOvr = 0
        END IF
    NEXT HighSect

'---add carry overs to front if no more to times by---
    IF CarryOvr <> 0 THEN MigTemp$(Array) = LTRIM$(STR$(CarryOvr)) + MigTemp$(Array)
NEXT LowSect


AdditionSection:
'---per ALT255's code---Small modifications my MIGGYD---
'***NOTE--I'm using Dim #0 for storage...therefore, don't OPT BASE this code
'***if you do then you'll have to modify this module.
FOR Cycle = 1 TO LEN(MigNum2$)
    MigNum1$ = MigTemp$(0)              'Store current total
    MigNum2$ = MigTemp$(Cycle)          'Store total from next array for add'g
    MigTemp$(0) = ""                    'clear the storage array for use later
    IF LEN(MigNum2$) > LEN(MigNum1$) THEN
        MigNum1$ = STRING$(LEN(MigNum2$) - LEN(MigNum1$), "0") + MigNum1$
    ELSEIF LEN(Num1$) > LEN(Num2$) THEN
        MigNum2$ = STRING$(LEN(MigNum1$) - LEN(MigNum2$), "0") + MigNum2$
    END IF
    CarryOvr$ = "0"
    FOR Rep = LEN(MigNum2$) TO 1 STEP -1
        A$ = LTRIM$(STR$(VAL(MID$(MigNum1$, Rep, 1)) + VAL(MID$(MigNum2$, Rep, 1)) + VAL(Carry$)))
        IF LEN(A$) > 1 THEN
            Carry$ = LEFT$(A$, 1)
        ELSE
            Carry$ = "0"
        END IF
        MigTemp$(0) = RIGHT$(A$, 1) + MigTemp$(0)
    NEXT
    IF Carry$ <> "0" THEN MigTemp$(0) = Carry$ + MigTemp$(0)
    PRINT
    PRINT "  "; MigNum1$
    PRINT "+ "; MigNum2$
    PRINT STRING$(80, "-")
    PRINT MigTemp$(0)
    PRINT : PRINT "...OR...": PRINT
    PRINT VAL(MigTemp$(0)): PRINT
    SLEEP 1
NEXT Cycle
PRINT "total is: "
PRINT MigTemp$(0)
PRINT : PRINT "...OR...": PRINT
PRINT VAL(MigTemp$(0))
END

---<end program code>---

Obviously, you can use LPRINT to have a hardcopy for review.
Comments? Errors? Let me know, please.




By the twitching of my thumb, something wicked this way comes........oh, it's only a boogy.

RE: number limit

Good work, MiggyD. I tried your code (after removing the print statements in the FOR/NEXT loop) then used the TIMER function get get an idea of how fast the multiplication section ran. It came in at .759765625 seconds (the TIMER isn't known for its great accuracy but it gave me "a" number to use for comparison).

Then I added your 1000-digit random string generator to my code, fixed a bug I hadn't noticed... the function kept trying to multiply the leading zero strings in Num2$ so I took the original length of Num2$ (Num2Size& = LEN(Num2$)) and changed one of the FOR statements to read
FOR R2 = LEN(Num2$) TO LEN(Num2$) - Num2Size& STEP -1.

My code executed in 1.220703125 seconds (substantially slower)

I like your way better (for obvious reasons). Now... how can we coerce your code into multiplying any two numbers?



A plain black box

RE: number limit

Alt255,

Firstly, I didn't give a second thought to speed--I just wanted to see if I could do it.  I don't necessarily need speed on my home computer, but may be if you needed this code for work or something then I could see where speed is a factor.

Secondly, you could use an input statment in place of the psudeo generator and ammend the input upto 5 digits.

Originally, I conceived how to input upto 1000 digits (took too long to enter them) in to a string var so I had a FOR/NEXT statement do it for me.

Approximately, how many digits are we talking about??  

Because QB (I have 4.5) allows one string variable to contain upto only 32,767 chars. which I believe is just about enough numbers to work with.

And, since I'm using dims to store the answers for each number in Num2$, I just don't know if Qb could handel that many DIMs even with Dynamic set "on".  Hum...may be? have to conentate certain vars or something

(screen shot of help file)
Limits to QuickBASIC - Arrays

                                       Maximum                 Minimum
Array size (all elements)
  Static                               65,535 bytes (64 K)     1
  Dynamic                              Available memory
Number of dimensions allowed           60                      1
Dimensions allowed if unspecified      8                       1
Array subscript value                  32,767                 -32,768

  Note: The maximum range between array subscript values is 32,767


If you want me to post some more code on this, let me know.




By the twitching of my thumb, something wicked this way comes........oh, it's only a boogy.

RE: number limit

Thanks for the reply, MiggyD. The need for speed is indeed a work requirement (my day-job is in an environment where high precision is very desirable and my night-job - "home work", if you will - is currently focused on a project that requires deadly precision in huge numbers.

No, I'm not a physicist trying to account for every electron in the universe. I'm just working on an anti-crack module for some software that my wife thinks will support us in our old age. I don't think the final version will be written in QB (but it's possible!)

Anyway... this discussion has been very helpful to me and I hope it has stimulated other members to explore the possibilities. Qbasic might not be the latest or greatest language but it is accessible to the most users. Its flexibility fosters a creative urge in beginners that would be quickly stifled by the more "advanced" languages.

Remember the guy who wanted to create a new operating system with Qbasic? I don't doubt he will succeed. The OS won't be written in Qbasic but Qbasic opened his eyes and will always remind him that the possibilities are without limit.





A plain black box

RE: number limit

Seem like this Forum will stand still for a while, Alt255!
I joined a few weeks ago and it seems like many stars had born since.

Keep going on that way, folks!!!

RE: number limit

Alt255,

Yes, I remember the person wanting to create an OS; and I'm sure that most of us (the more seasoned ones) are rooting for him--I know I'd like to see where his preseverence leads him.

Good luck with your nest egg.  I would not recommend you write your program in QB if it could be helped, but that's just my personal opinion.  I mean what would have been the time frame (Oh...I don't know) to, let's say, write in the code for the program ACCESS in QB than to use say C or something else?  Maybe a year more than was really needed? Think of your audiance (they'll most likely be using Windows 3,000,000 by then and QB doesn't interface with 32 bit systems all that great (or 128 bits if using Win 3-Million [hehe]).  But seriously good luck, hope I brought back some memories for you and made you laugh a Bit or 128 of them [hehe].

But getting back to QB programming...I'm trying to figuer something out...how many digits did you enter into NUM1$ (or in my case MigNum1$) and how many digits did you enter into Num2$ (or MigNum2$)?

And then I thought, how come my code is faster than yours? and I thought that you may have only entered the 5 digits in as the number for NUM2$ instead of a really really large number.

So, on that train of thought, I pasted your "ADD LARGE" 's NUM1$ and NUM2$ into my code, removed (actually REM'd) the number generator and the 3 lines for inputing upto 5 digits so that NUM2$ would be indicitive of the NUM2$ in your add code.

After running the numbers (and removing (actually relocated) the print statements) a few times it averaged out to be approx 2.0 seconds (the lowest I got was approx. 1.8 seconds).  AND, when I'd enter upto 5 digits it would average out to about .64-.68 seconds--see PPS.  Again, I believe that the speed is relevant to the number of digits in NUM2$; but, I want to confirm it with you that the lower number of digits to work with will infact increase result response time.

Please respond to the above paragraph.  I'm going to make it a point to check out this post daily for the next 7 days or so.

PS--I'm also conceiving a modification to my code to maybe push the speed (dependening of the nubmers to multiplay against) a little bit faster.  More details later, but you may like it--if it works that is.

PPS--My PC: 16 megs, 486DX (so internal math proc.), slushing through at 75Hz...don't know if that's a difference in processing speed also, FYI.




By the twitching of my thumb, something wicked this way comes........oh, it's only a boogy.

RE: number limit

MiggyD, you made me laugh in full 256 bit mode (I guess that's one more than Alt255 deserves).

Regarding the speed thing: I used 1000 random digits in Num1$ and 5 random digits in Num2$ (didn't use a input statement). I tested the functions 10 times and posted the averages. Computer = AMD 350 MHz w/ 64MB, Win 98. I repeated the tests on one of my work machines (AMD 500 MHz w/ 128MB, Win 98 SE) and had similar results. Odd... but stranger still, I wrote equivalent VB6 functions to emulate both sets of code, ran them on the faster machine and found that both executed in about the same amount of time (BTW, both, with a few modifications, multiplied two 1000 digit numbers in about 47 seconds).

This is a true head scratcher. Perhaps Windows is the great equalizer... all code, slow or fast, runs at the same speed. (?????)

I'm pretty sure that fewer digits in Num2$ will result in faster performance across the board but, aside from my comparisons of 1000x5 and 1000x1000 test runs I don't have any experimental data to support that assumption.

I'm looking forward to seeing your modifications. This is getting very interesting.





A plain black box

RE: number limit

If you need arbitrary precision arithmetic, use scheme, a dialect of lisp.  I remember easily handled 80! = (eighty factorial) =~ 7x10^118   There are plenty of fast arbitrary precision packages in C too.  

RE: number limit

Alt255--

Your first line made ME laugh, too. I'm glad it did. I had a hard day.

Anyways, I way able to get some more speed in the Multiplication Section of the above code.  

Testing:  I maintained using 1000 x 5. However, I used one thousand 9's times against five 9's [using highest numbers is best for worst case seniaros, I believe] and came to a baseline for both the original code and the modified one.  Only my code was modified, I'll try to get to yours as soon as I can, unless someone else has already, so you can paste the following code over the Multiplication section completely, and it will still function as before only a little bit faster.

Here's some of the details.  Just remember that my system is a 486DX (obsolete really).  And you kind of scared me with the 1000 x 1000 numbers, whew!  That's alot of numbers...Are you sure you're not trying to find the origins of the Univers????[hehe].  Anyway, I hope this helps a little.

Original Code:
     Multiply speed=1.75

     Addition speed=1.87
     Over all speed=3.57

Modified Code:
     Multiply Speed= .88

     Addition Speed=1.869
     Over all speed=2.69

Instead of multiplying just 1(Num1) digit against 1(Num2) why not multiply 2(num1) by 1(num2)?  {I didn't want to try 3 x 1 cause it may slow things down--see red star below.}

MultiplySection:
FOR LowSect = LEN(MigNum2$) TO 1 STEP -1
    WorkLowNum = VAL(MID$(MigNum2$, LowSect, 1))
    CarryOvr = 0
    Array = LowSect

'++++begin test block++++
'--get first 2 numbers in MigNum1$, work them, set CarryOvr (as needed)
'--and setup cycling routine for rest of numbers
    HighSect = LEN(MigNum1$) - 2
    WorkHighNum = VAL(RIGHT$(MigNum1$, 2))

    WorkResult = (WorkLowNum * WorkHighNum) + CarryOvr

    IF LEN(LTRIM$(STR$(WorkResult))) = 3 THEN         
'
'--max possible result 3 digits
'--9 x 99 = 891 (keep 91, carry 8)
'
        MigTemp$(Array) = RIGHT$(LTRIM$(STR$(WorkResult)), 2) + MigTemp$(Array)
        CarryOvr = VAL(LEFT$(LTRIM$(STR$(WorkResult)), 1))
    ELSEIF LEN(LTRIM$(STR$(WorkResult))) = 2 THEN     '
        '
'--intermediate results 2 digits
'--1 x 99 = 99
'
MigTemp$(Array) = LTRIM$(STR$(WorkResult)) + MigTemp$(Array)
        CarryOvr = 0
    ELSEIF LEN(LTRIM$(STR$(WorkResult))) = 1 THEN
'
'--Minimum possible results 1 digit
'--1 x 00 = 0 & 1 x 09 = 9*
'--NOTE:   #1...09 = 9 (leading 0 is removed from disply & results therefore add the carry over in front)
'--    #2...00 = 0 (only one 0 is returned, place Carry Over in front that, there's no need to write in more code to fill in the additional spaces*note it may slow prg.*)
'
        MigTemp$(Array) = "0" + LTRIM$(STR$(WorkResult)) + MigTemp$(Array)
        CarryOvr = 0
    END IF

    FOR HighSect = HighSect TO 1 STEP -2
        WorkHighNum = VAL(MID$(MigNum1$, HighSect, 2))

'---Multiply and add stuff---
        WorkResult = (WorkLowNum * WorkHighNum) + CarryOvr

'---logic routines---
        IF LEN(LTRIM$(STR$(WorkResult))) = 3 THEN         'Max 9x99=891
            MigTemp$(Array) = RIGHT$(LTRIM$(STR$(WorkResult)), 2) + MigTemp$(Array)
            CarryOvr = VAL(LEFT$(LTRIM$(STR$(WorkResult)), 1))
        ELSEIF LEN(LTRIM$(STR$(WorkResult))) = 2 THEN     'Min 1x9=99
            MigTemp$(Array) = LTRIM$(STR$(WorkResult)) + MigTemp$(Array)
            CarryOvr = 0
        ELSEIF LEN(LTRIM$(STR$(WorkResult))) = 1 THEN     'Min 1x00=0 & 1x09=9
            MigTemp$(Array) = "0" + LTRIM$(STR$(WorkResult)) + MigTemp$(Array)
            CarryOvr = 0
        END IF
'+++end test block+++


    NEXT HighSect

'---add carry overs to front if no more to times by---
    IF CarryOvr <> 0 THEN MigTemp$(Array) = LTRIM$(STR$(CarryOvr)) + MigTemp$(Array)
NEXT LowSect

All the bold stuff is modified code the rest (what little there is of it) is the same as before. Please let me know if it readly does speed up on your system OR if you have any problem/questions/comments.

Enjoy!




By the twitching of my thumb, something wicked this way comes........oh, it's only a boogy.

RE: number limit

i know i am joining in a little late, but this multiply large numbers thing was an assignment of mine back when i was taking qbasic in high school (just a couple years ago). It was part of a 20 problem semester exam that we had 3 weeks to do. that was the one problem I never figured out how to do, and haven't thought of it since then. kind of neat that you guys still use basic to do neat things like this.

ray
rheindl@bju.edu

RE: number limit

Thanks for the compliment froggerIII and I'm glad you've joined in...you know the old saying "It's never too late to join in".

By the way if you should have any input on increasing the speed of the addition section, please don't hesitate to show off your handy work.  I'm swamped with work and could use any input you or anyone else may have.

I think you'll find Tek-Tips in general to be one of the more (if not the most) challenging sites around.  With the multitude of members and forums to choose from, you should't be bored trying to help (and even get helped) on certain topics.

Again, feel free to submit anything you think may be pertainent to ANY of the forums or discussions you come across.

On behalf of this forum, welcome abord!  :]

--MiggyD

PS -- If you see any typo's...sorry. I'm currently having a problem with trying to stay online. I think my ISP is getting inundated with new members--but it's the cheaps I can get...so, I'll have to suffer awhile.




By the twitching of my thumb, something wicked this way comes........oh, it's only a boogy.

RE: number limit

Hi, FroggerIII. Glad to have you with us.

MiggyD, I'm still evaluating. Use of an array to store some of the numbers appears to speed up the calculations considerably but without special considerations you run out of string space pretty quickly. As a new test I took your new code, basically as posted, and placed it inside a loop that multiplied 1000 "9"s by 1 "9", then 2 "9"s... and so forth, writing the calculation times to a file between loops. Then I tried the same with my old code.

The array method ran out of string space after the 27th set of nines and I stopped the other after 200 "9"s. Then I opened the two files in Excel and created charts so I could "see" what was happening. The purely string oriented method showed an almost perfect linear relationship between the number of digits and the calculation time. The array method started out very flat and then changed to a smooth upward curve that went almost vertical on the 27th set of digits (almost expotential).

I didn't have time to root through the code but I suspected that either a temporary value was receiving unwanted string concatenations or a portion of a loop was being repeated unnecessarily as the size of the numbers increased.

I'll take another look at it this morning. Oh, and I think your assessment of the addition section is accurate. This is where the big slow-down is occuring.

Just for giggles, before I left work yesterday I pulled up that VB app I mentioned eariler and told it to multipy two 16000 digit random numbers. We'll see if managed to finsh (or crash) overnight.



A plain black box

RE: number limit

Alt255

Sorry. I couldn't get back to the forum sooner. I had been transferred to another department where there is no access to the web and I had to re-install my computer. I only got it up and running yesterday.

I'll take a look at my code again, maybe my code only works for 1000 x 26.  

My kid's crying, I'll get back as soon as I can and hopefully with some response.  PS--I haven't even gotten a chance to look at your's (can't wait for wife to get back from trip)  

Later - MiggyD




Who cares?? If Peter Piper packed a peck of pickled peppered peas??

RE: number limit

You're right, Alt255.

I can't understand it.  I've seen other programs with DIM X$(2000) and never thought the 27th digit would be a "out of string space" matter.

Sorry, I can't explain why QB is doing what it's doing.  If I come across any answers, I'll post a response to you.  I guess that you're code would be the one to use at work, and mine would be the one to use for a quickie one (and I don't mean "in the sack" either.)

BTW did it crash??




Who cares?? If Peter Piper packed a peck of pickled peppered peas??

RE: number limit

Yes, It crashed. I would call it a "crash". I had placed a DoEvents command at the bottom of the outer loop to allow the system to take care of housekeeping and allow the app to increment a counter in a label. The counter showed that the app had finished multiplication set #6309 (the equivalent of multiplying a 16000 digit number by a 6309 digit number). The mouse was sluggish and the hard-drive light was blazing, obviously in the midst of a heavy-duty swap.

I walked away for ten minutes to see if the counter would increment but when I returned it was still locked at 6309 and the disk was still thrashing. I was able to terminate the app with ctrl+alt+del and check the resource monitor. The CPU was still at 100% usage.

It was worth a try. No harm was done and my computer had a pretty respectable workout. My only regrets are that I didn't log the completion time for each loop (it would have given me the "official time of death" and a better idea of how long it might take to calculate such a huge number) and that I used the DoEvents command (it probably doubled the cumulative calculation time).

I was thinking the multiplication section could be hastened by multiplying four digits at a time and returning the intermediate results in a long integer. But the addition section probably wouldn't like that approach. The intermediate results could become unmanageable as the calculations moved from right to left.

MiggyD, you have been very helpful in the quest to find the big number and I certainly wouldn't expect you to rack your brain over this. At the same time, if you or anybody else happen to see a way to make the logic a little more efficient, I am eager to hear your thoughts.

That's another thing I love about the Qbasic forum. The language is nearly universal. A developer using a different language can read the code, understand the logic and translate it into practically any other format.

Thanks again!



A plain black box

RE: number limit

Whao there Alt255!

If you do plan on using 4 digits in the multiplication you may have to take into account of the following POSSIBLE NUMBER(S):

5200000003
x     50002
-----------


See all those zeros??? You'll have to write more code to handle the exceptions.

What you want to happen    What computer sees    Returned
     0003                       3               3
    x   2                     x 2             x 2
    =0006                     = 6             = 6


Remember that the computer (in QB and VB) will reduce the number if possible and by this I mean removing the leading zero(s) as shown above.

This is the reason I kept to a max of 2 digits.  At least if RIGHT$(Temp2$,1)=0 (with the Carry$="0" also) then you would have "00" to put in Answer$ (Ex: Ans$ = Carry$ + Temp1$) without too much modifications to the existing code.  Otherwise, you'll have so many IF/THEN or SELECT CASEs in your code to compensate for the empty spaces that you or someone reading it may go blind.

But, I would concur with you in respect to the 4 digit calc producing results faster.  Who knows? Maybe if the multiplication is done faster, then the IF/THEN slow down(s) may be impersieveable (except to the computer that is).

BTW your program alone averaged out to .5680776+ Each additional digit in num2

use that in your big number calc and you'll find out how long it took to process 16000 x 6309

That is to say the time taken from 1000 x 1 to 1000 x 2 to 1000 x 3 ... 1000 x 50.  

Well, see you around the web.




Who cares?? If Peter Piper packed a peck of pickled peppered peas??

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close