(07-27-2022, 03:31 PM)SierraKen Wrote: Pete, yeah it's not exactly a scientific calculator and I believe QB64 rounds it off if you go too far in the decimal range. Thanks for showing me but I'm just going to leave it like it is. I don't know enough math to make such an algorithm and I don't think .000000000000001 will make much difference with anything, unless like I said, you are a scientist or mathematician. LOL
Oh come on! I want a calculator that can give me the correct re-PETE-nd for 1/97. So I want to see a readout of 96 digits...
.010309278350515463917525773195876288659793814432989690721649484536082474226804123711340206185567...
Kidding aside, I hear ya. Now I can easily get the above answer with my string math routine, but I have yet to work out a suitable method to track division with repeating so dividing several times and then multiplying back the reverse the same number of times would always arrive at the original number. So even looking at a simple 1 / 3 = . 3... then * 3 should = 1 but without a way to tag the quotient as a repeating decimal, the routine returns .9... instead of one. So if I set to display 60 decimal places, I would get:
.999999999999999999999999999999999999999999999999999999999999
Now if I had tagged the .3 repeating decimal and multiplied it by 3, I'd be tempted to round up the readout to "1" and clear the tag. If the calculation was 2 / 3, however, I'm confronted with .6... and if I tag it and multiple it back by 3 and use the same round up method, I'd get 1.8 rounded up to 1.9, fail! It should be 2. So simple rounding doesn't cut it.
Anyway, blah, blah, blah aside... Please take a look at the other part of my post, which stated:
"Try putting in .01 or .301 and see what you get." As is press the buttons to input .01 or .301 and the readout fails to register that input correctly.
I think while I was writing this post Kernelpanic touched on the same bug.
Pete