## 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

tanx in advance

miguel

migoul@hotmail.com

QBasic page (not been updated recently)

## RE: number limit

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

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

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

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

miguel

migoul@hotmail.com

QBasic page (not been updated recently)

## RE: number limit

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

Guest(visitor)IF Carry$<>"0" then Answer$=Carry$+Answer$

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

## RE: number limit

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

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

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

CLSPRINT "numbers generated for multiplication:"

PRINT MigNum1$

'prove len

PRINTPRINT "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

PRINTINPUT "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 -1WorkLowNum = 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=81MigTemp$(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

.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

two numbers?anyA plain black box

## RE: number limit

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 generatorand ammend theinput 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

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

I joined a few weeks ago and it seems like many stars had born since.

Keep going on that way, folks!!!

## RE: number limit

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

mycase 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 reallylarge 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

increase result response time.infactPlease 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

maybepush 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

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

Guest(visitor)## RE: number limit

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

littlebit 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

ORif 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

ray

rheindl@bju.edu

## RE: number limit

froggerIIIand 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

ANYof 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

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

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

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

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 numberand 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

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

5200000003x 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

maygo 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 numbercalc and you'll find out how long it took to process 16000 x 6309That 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??