Elliminate the e symbol from doubles
-
Blood_HaZaRd wrote:
x= 1.123456789 e09
Blood_HaZaRd wrote:
x = 1123456789
Since they are different representations of the same number, both of them are stored, in a
double, with the same bit pattern. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]it's clear that they have the same number but God its seems that the fmod doesn't make a correct modulo with double or i missed sth else with that fucntion ...
//i have x = 105145010021234567890311169400 which is also equal to 1.0514501002123e+029
double alpha = fmod (x, 97) //alpha will be equal to 16.000000000000or with calculator x modulo 97 = 92 it sounds my computer is hollowed :doh:
"The Ultimate Limit Is Only Your Imagination."
-
ok o how could u explain this : i have double x = 105145010021234567890311169400. and when i make double y = fmod(x, 97) it gives me 16 or when i calculte it with a calculator it gives me 92
"The Ultimate Limit Is Only Your Imagination."
-
ok o how could u explain this : i have double x = 105145010021234567890311169400. and when i make double y = fmod(x, 97) it gives me 16 or when i calculte it with a calculator it gives me 92
"The Ultimate Limit Is Only Your Imagination."
-
ok o how could u explain this : i have double x = 105145010021234567890311169400. and when i make double y = fmod(x, 97) it gives me 16 or when i calculte it with a calculator it gives me 92
"The Ultimate Limit Is Only Your Imagination."
You'll never get a representation of that integer into a double without loosing a chunk of accuracy. 105145010021234567890311169400 is 0xE97804B9A34AB4E which is going to take about 60 bits to hold. As a double only has 53 bits to store digits you've already rounded your number to the nearest multiple of 128 by storing it in a double. So as it's an integer, store it in an integer - the e bit is non-negotiable with a floating point number and has no bearing at all on your problem. Ash
-
You'll never get a representation of that integer into a double without loosing a chunk of accuracy. 105145010021234567890311169400 is 0xE97804B9A34AB4E which is going to take about 60 bits to hold. As a double only has 53 bits to store digits you've already rounded your number to the nearest multiple of 128 by storing it in a double. So as it's an integer, store it in an integer - the e bit is non-negotiable with a floating point number and has no bearing at all on your problem. Ash
ok so the best solution is to navigate into mthemticl splitting and mke the purpose by slices
"The Ultimate Limit Is Only Your Imagination."
-
it's clear that they have the same number but God its seems that the fmod doesn't make a correct modulo with double or i missed sth else with that fucntion ...
//i have x = 105145010021234567890311169400 which is also equal to 1.0514501002123e+029
double alpha = fmod (x, 97) //alpha will be equal to 16.000000000000or with calculator x modulo 97 = 92 it sounds my computer is hollowed :doh:
"The Ultimate Limit Is Only Your Imagination."
Blood_HaZaRd wrote:
//i have x = 105145010021234567890311169400 which is also equal to 1.0514501002123e+029
That is wrong. As I stated before, double cannot represent such big integer numbers with the required (by you) accuracy:
1.0514501002123e+029 = 105145010021230000000000000000
i.e. there's a big difference with 105145010021234567890311169400. Bottom line: you cannot use a double for the intended purpose (after all,
doublesare 64 bit numbers: they would have 'mystical powers' in order to represent an integer better than a 64 bitintitself). :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Blood_HaZaRd wrote:
//i have x = 105145010021234567890311169400 which is also equal to 1.0514501002123e+029
That is wrong. As I stated before, double cannot represent such big integer numbers with the required (by you) accuracy:
1.0514501002123e+029 = 105145010021230000000000000000
i.e. there's a big difference with 105145010021234567890311169400. Bottom line: you cannot use a double for the intended purpose (after all,
doublesare 64 bit numbers: they would have 'mystical powers' in order to represent an integer better than a 64 bitintitself). :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]May i use a 128 bit integer or double nd if yes how to do that so
"The Ultimate Limit Is Only Your Imagination."
-
May i use a 128 bit integer or double nd if yes how to do that so
"The Ultimate Limit Is Only Your Imagination."
Yes, if you have them. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
ok so the best solution is to navigate into mthemticl splitting and mke the purpose by slices
"The Ultimate Limit Is Only Your Imagination."
-
One solution is using Multiple Precision Number library like http://gmplib.org/[^]
i alredy downloaded the GMP zip files but i had problems to use it in MVS 6.0 .. i m a newbie in such manipulations (integrating foreign files inti my project) . may be when my skills will be better i 'll try it :laugh:
"The Ultimate Limit Is Only Your Imagination."
-
i alredy downloaded the GMP zip files but i had problems to use it in MVS 6.0 .. i m a newbie in such manipulations (integrating foreign files inti my project) . may be when my skills will be better i 'll try it :laugh:
"The Ultimate Limit Is Only Your Imagination."
I think you need to spend some more time reading about floating point number representations. A floating point (double) number allows you to store extremely large or extremely small values and anything in between, but at a cost of accuracy in these values. Thus they are no good for applications where numeric accuracy is important, e.g. anything to do with money. When you display such numbers on screen or printer you have various options for how you wish them to be represented on screen: in scientific 1.3456e-2, or decimal 0.013456 etc. If you want to use very large numbers with no loss of accuracy then you need to find a library or class (or write one) that can do it for you.
It's time for a new signature.