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.<br>tanx in advance <p>miguel<br><a href=mailto:migoul@hotmail.com>migoul@hotmail.com</a><br><a href= page (not been updated recently)</a><br>
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
number limit 2
- Thread starter lived
- Start date
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 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.
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.
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.
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
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
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??
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??
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!
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!
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.
[tt]What you want to happen[tab]What computer sees[tab][red]Returned[/red]
[tab] 0003[tab][tab][tab][tab][tab] 3[tab][tab][tab][red] 3[/red]
[tab]x 2[tab][tab][tab][tab][tab] x 2[tab][tab][tab][red] x 2[/red]
[tab]=0006[tab][tab][tab][tab][tab] = 6[tab][tab][tab][red] = 6[/red][/tt]
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.
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.
[tt]What you want to happen[tab]What computer sees[tab][red]Returned[/red]
[tab] 0003[tab][tab][tab][tab][tab] 3[tab][tab][tab][red] 3[/red]
[tab]x 2[tab][tab][tab][tab][tab] x 2[tab][tab][tab][red] x 2[/red]
[tab]=0006[tab][tab][tab][tab][tab] = 6[tab][tab][tab][red] = 6[/red][/tt]
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.
- Status