U++ forum: Welcome to the forum

Search on this site

Search in forums

Home » Community » Coffee corner » FP humor

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

FP humor [message #57415]

Thu, 05 August 2021 14:47

mirek
Messages: 14257
Registered: 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...

Report message to a moderator

Re: FP humor [message #57417 is a reply to message #57415]

Thu, 05 August 2021 15:41

dolik.rce
Messages: 1791
Registered: 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 Smile

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

Report message to a moderator

Re: FP humor [message #57418 is a reply to message #57417]

Thu, 05 August 2021 15:45

mirek
Messages: 14257
Registered: 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...

Report message to a moderator

Re: FP humor [message #57453 is a reply to message #57418]

Thu, 19 August 2021 17:39

mirek
Messages: 14257
Registered: 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:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat May 10 21:08:24 CEST 2025

Total time taken to generate the page: 0.03128 seconds