Archived

This topic is now archived and is closed to further replies.

Mulligan

really small numbers

Recommended Posts

Long is the biggest / smallest you can go. Its 64bits if i''m not mistaken



"With my feet upon the ground I lose myself between the sounds and open wide to suck it in, I feel it move across my skin. I''m reaching up and reaching out. I''m reaching for the random or what ever will bewilder me, what ever will bewilder me. And following our will and wind we may just go where no one''s been. We''ll ride the spiral to the end and may just go where no one''s been." - Maynard James Keenan
[TheBlackJester ]
[Wildfire Studios ]

Share this post


Link to post
Share on other sites
quote:
Original post by Mulligan
er, you can't do that.


According to the standard you can. But then again, MSVC isn't totally compliant, if that's what you're basing your assumptions on.

[edited by - zealouselixir on August 30, 2002 12:45:35 AM]

Share this post


Link to post
Share on other sites
I think that float should be able to handle it, but if float doesn''t work try double . Thats in c++. In VB, I''m not sure, I believe the types are something like single and double .

Share this post


Link to post
Share on other sites
Floating point numbers only have precision loss on VERY little numbers - your one isn't very little

66.7f is as good as 0.00000000006670f
that's why it's called floating point...
even that number is nice for a float and won't have badder precision than the above:
0.000000000000000000000000000000000000006670f

Don't use "long double"! They are 80-bit numbers and the FPU can't handle loading them from memory in a calculation, so the compiler must add a load instruction before every one. "double" should be enough for everything, and even float is good enough for most things. "float" is also much faster.


[edited by - noVum on August 31, 2002 1:01:44 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by TheBlackJester
Long is the biggest / smallest you can go. Its 64bits if i''m not mistaken


Uh, no. In Win32, a long is equivalent to a 32-bit integer. Doubles are 64-bits, and long doubles are 80-bits, according to the standard.

Later,
ZE.


//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links

Share this post


Link to post
Share on other sites
long is not a floating point number it''s a 32-bit integer
if you meant long double then it''s a 80-bit floating point number
double is 64-bit and float is 32-bit

Share this post


Link to post
Share on other sites
So, then is it possible to create a 64 bit integer in ansi compliant code? if so, what is the keyword? (I use __int64, as a vc user)

Share this post


Link to post
Share on other sites
quote:
Original post by noVum
Don''t use "long double"! They are 80-bit numbers and the FPU can''t handle loading them from memory in a calculation, so the compiler must add a load instruction before every one. "double" should be enough for everything, and even float is good enough for most things. "float" is also much faster.



How bad is it really? I have to do lots of calculations dealing with astronomicaly large and small numbers. Is the performance hit severe?

Share this post


Link to post
Share on other sites
quote:
Original post by noVum
Since when are floating point numbers signed or unsigned??? They are ALWAYS signed!!!


In the Standard, yes. There are compiler-specific types that allow for unsigned floating point numbers, though.

Share this post


Link to post
Share on other sites
Mulligan please believe me... double will suit your needs in 99,9% of all cases. If you get precision errors you can change it afterwards, but I really don't believe it.
64 bit is even used for science calculations, because most processors doesn't have 80 bit support.

@ZealousElixir:
That doesn't make sence, in x86 there are NO unsigned floating point numbers. Perhaps on other platforms but I hardly believe it. The FPU internally always use 80 bit "tempreal" floating point numbers, they are only converted if you store or load them from memory. And there is always one bit reserved for the sign.


[edited by - noVum on August 31, 2002 1:34:55 AM]

Share this post


Link to post
Share on other sites
Here is on problem I'm having. The weight of the Sun in metric tons is 1989000000000000000000000000. How can I store a number that big? It wont fit into anything.
I get this error:
D:\Apps\OpenGL\Cosmic\Star.cpp(32) : error C2177: constant too big

[edited by - Mulligan on August 31, 2002 2:04:01 AM]

Share this post


Link to post
Share on other sites
Sure it will, but you have to add .0f
1989000000000000000000000000.0f will work...
Without that the compiler thinks it''s an integer and it''s to long.

Share this post


Link to post
Share on other sites
You might also want to rethink your units. Are you ever going to need precision to a single metric ton? Since you are dealing with cosmic bodies, I''m guessing no.



The hackers must have gotten into the system through the hyperlink!!

Invader''s Realm

Share this post


Link to post
Share on other sites
Mulligan:

Maybe it would help if I explained what floating point numbers are.

floats and doubles are both floating point data types.

An integer type, essentially, can store a fixed number of digits. That''s not how floating point numbers work.

Are you familiar with scientific notation? That''s how floating point numbers work. They wtore a mantissa> and an exponent (and a sign). Whereas an integer would store the following:

0000000000000064

A floating-point number would store this:

+ 6.4000000000e00001

In the floating-point example, the first part is the sign, the second is the mantissa, and the third is the exponent. (Note the "E" reads "times ten to the").

Now, for small numbers like 64, it doesn''t matter; integers are fine. But for really tiny numbers and really huge numbers, floating point variables work whereas integers don''t.

A double, in MSVC++, can hold a number as high as 1.7e308. Now, for some perspective: there are only approximately 1e79 atoms in the universe. I think a double can hold big enough numbers!! (Chances are floats are good enough for most things too; their max is 3.4E38).

Now, as you may have realized by now, although it can store both huge and tiny numbers, a double can''t hold all 300+ digits of a number. It stores numbers with a certain precision. This is fine. If you''re storing the mass of the Sun, you don''t need to know it to the milligram. To give you some perspective on how much precision is really needed, I once read that NASA used only the first ten digits of PI to go to the moon. Floats hold seven digits and doubles hold 15. I''m sure at least the double is enough.

But let''s say that even this isn''t good enough for you. Let''s say that you need to store a really massive number with precision to the ten-thousandths place. What do you do? Use an arbitrary-precision number class. It''s computationally slow, and I''m sure you don''t need it for your purposes, but when ridiculous precision is needed, this is what people do. Note that people rarely do it, and that doubles are used for almost all scientific computing.

Share this post


Link to post
Share on other sites
The way the floating point problem was explained to me (in a DSP class):
You have an elevator that can run over 20 or 30 floors (your mantissa). The elevator can start all the way in the basement or all the way at the top of the building (the exponent). So if you have a 1000-floor building, it can be anywhere along there, but it can still only run over 20 or 30 floors.

This doesn''t map 1:1 because the exponent means there''s a logarithmic relationship between the exponent and the range of the mantissa, but the problem can be stated that if you need more range than the number of floors you can travel, or if you need to get in between floors, you have a range or precision problem.

Share this post


Link to post
Share on other sites