Overview Examples Screenshots Comparisons Applications Download Documentation Tutorials Bazaar Status & Roadmap FAQ Authors & License Forums Funding Ultimate++
Search on this site
Search in forums

Home » Community » Coffee corner » FP humor
FP humor Thu, 05 August 2021 14:47
 mirek Messages: 13975Registered: November 2005 Ultimate Member
CONSOLE_APP_MAIN
{
x = 1;
for(int i = 0; i < 10000; i++)
x *= 0.6;
DDUMP(Sprintf("%.16g", x));
}

Sprintf("%.16g", x) = 4.940656458412465e-324

....and I was thinking that the lowest possible double is 1e-308...

Re: FP humor [message #57417 is a reply to message #57415] Thu, 05 August 2021 15:41
 dolik.rce Messages: 1789Registered: August 2008 Location: Czech Republic Ultimate Contributor
Hi Mirek,

mirek wrote on Thu, 05 August 2021 14:47
....and I was thinking that the lowest possible double is 1e-308...

You made me do some research and learn something new again

To save others the trouble: 1e-308 is smallest normalized value, denormalized values can be around 4.94066e-324. And (not surprisingly) the C++ standard thought about it: https://en.cppreference.com/w/cpp/types/numeric_limits/denor m_min

Best regards,
Honza
Re: FP humor [message #57418 is a reply to message #57417] Thu, 05 August 2021 15:45
 mirek Messages: 13975Registered: November 2005 Ultimate Member
dolik.rce wrote on Thu, 05 August 2021 15:41
Hi Mirek,

mirek wrote on Thu, 05 August 2021 14:47
....and I was thinking that the lowest possible double is 1e-308...

You made me do some research and learn something new again

To save others the trouble: 1e-308 is smallest normalized value, denormalized values can be around 4.94066e-324. And (not surprisingly) the C++ standard thought about it: https://en.cppreference.com/w/cpp/types/numeric_limits/denor m_min

Best regards,
Honza

Exactly.

But another interesting issue but perhaps not so suprising fact is that if you multiply variable by 0.6 many many times, it eventually reaches the minimal representable value and then stays at it because of rounding rules...
Re: FP humor [message #57453 is a reply to message #57418] Thu, 19 August 2021 17:39
 mirek Messages: 13975Registered: November 2005 Ultimate Member
BTW, these are while working on new double<->String conversion routines.

Things are really complicated if you want to do it with absolute possible precision and fast.

E.g. for introduction:

https://www.ryanjuckett.com/printing-floating-point-numbers/

Now I have a nice algorithm tested with 300 billions of samples without an issue. However, I would possibly need help with following problem:

The heart of algorithm is FP with ~60 bit variable mantissa multiplication with 128 bits mantissa constants (this is basically to compute correct pow10), resulting in 128FP number. To prove that there are no input values that would lead to error (which would be less than 2^-70 anyway), I would need to prove that for no variable mantissa bitpattern and no constant, lower 64 bits are never in middle range (half +/- 4), except when they need to be (which is a bit hard to define.. but it is when mantissa has lower bits zero).

Anybody interested in helping with this?

[Updated on: Thu, 19 August 2021 17:41]

Report message to a moderator

 Previous Topic: The serial number is getting smaller. Next Topic: Things are tricky with double<->text conversions
Goto Forum:

Current Time: Mon Apr 22 08:00:05 CEST 2024

Total time taken to generate the page: 0.03150 seconds