Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Float Command's problem?

Author
Message
Jachan19
15
Years of Service
User Offline
Joined: 1st May 2011
Location:
Posted: 4th May 2013 07:31
Hi... I am not very sure if I should post it here or to report Darkbasic this "bug" to "Bugs Report" there... but I just encountered this "bug" about Float command, with decimal.
When I make number through string (as Float, not "as STRING") (in this case, 999.9), after compiled, it suddenly said this "999.900024414" instead... I tested all numbers and only two out of ten are perfectly correct...
Here the whole ten (zero is "tenth" if you wondered) results are; i am removing all numbers before decimal, to save my type to fill in since they all are just same as if it's unaffected.

.0 = .0 (in fact, it's removed however... but still correct as you can tell that)
.1 = .099975586
.2 = .200012207
.3 = .299987793
.4 = .400024414
.5 = .5 (another correct one as the second one)
.6 = .599975586
.7 = .700012207
.8 = .799987793
.9 = .900024414

If you look it closer between .0 to .5 and .6 to .9, others than the first digit in decimal, they both are repeated...

Is it really a bug? I did looked anywhere but honestly, it seem like it's only direct-return by itself... just no formula or no math affect that float-string, just completely original result
In other word...



That's it. Really!

Is it really a bug of Float or is there anything can I do about those error numbers that should not be appeared?

Thank you in advance.
Phaelax
DBPro Master
23
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 4th May 2013 07:58
It's a floating point precision issue in the architecture of the CPU. There's really not much DB can do about it.

"You're all wrong. You're all idiots." ~Fluffy Rabbit
Jachan19
15
Years of Service
User Offline
Joined: 1st May 2011
Location:
Posted: 4th May 2013 08:02
Ah okay then... I guess I have to make it be "9,999" instead 999.9, to avoid it properly in this case?
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 4th May 2013 19:58
Floats can only reliably store up to 6 significant figures so just make sure that when you output it you round it correctly.

"str$" takes a second parameter with the number of decimal places to round it to, so this:



Will correctly display "999.9"

All floating point based computation suffers from this, it's just a matter of applying the correct rounding when displaying it to the user.

In decimal, the fraction 1/7 repeats forever: 0. 142857 142857...

In binary, the same thing happens for 1/10: 0.0 0011 0011 0011...

So you can't represent "0.1" in binary in a finite number of digits.

[b]
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 5th May 2013 22:59
I was noticing this a few weeks ago, except rounding errors were becoming really bad.

For Example, 2.0 was being represented as 1.99999998 and then I was INT() converting it to an integer and it was coming out as a value of 1 instead of 2.

These numbers aren't the actual numbers I was using but you get the general idea. The problem can really get out of hand if you let it.

Phaelax
DBPro Master
23
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 5th May 2013 23:23
I think int will truncate, not round. That's why you get 1.

"You're all wrong. You're all idiots." ~Fluffy Rabbit
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 6th May 2013 00:30
Yeah.

Le Verdier
14
Years of Service
User Offline
Joined: 10th Jan 2012
Location: In the mosh-pit
Posted: 6th May 2013 00:37 Edited at: 6th May 2013 00:38

Login to post a reply

Server time is: 2026-07-06 18:37:46
Your offset time is: 2026-07-06 18:37:46