.NET Forum / Languages / VB.NET / May 2006
int64 or double
|
|
Thread rating:  |
cj - 12 May 2006 22:02 GMT VB2003. I need a large positive integer. Which is larger int64 or double?
I see int64 also apparently is known as long and will hold -9,223,372,036,854,775,808 through 9,223,372,036,854,775,807.
But I'm not good with the E+??? notation so when I'm told double holds -1.79769313486231570E+308 through -4.94065645841246544E-324 for negative values; 4.94065645841246544E-324 through 1.79769313486231570E+308 for positive values.
What does that mean? is -1.79769313486231570E+308 = -1.79769313486231570 X whatever 1 with 308 zeros behind it is?
Plus double doesn't seem to hold 1, 2, 3, 4, 5 etc cause it gives two ranges.
Sorry, I always felt math was for the computer to figure out not me.
tommaso.gastaldi@uniroma1.it - 12 May 2006 22:44 GMT Double.MaxValue should be large enough.
the +308 means how many times you have to shift the decimal period to the right (like if you multiply times 10 raised to 308). Try writing this: MsgBox(1E1)
in your compiler and see what happens ;-)
-t
Charles Appel - 12 May 2006 22:52 GMT > VB2003. I need a large positive integer. Which is larger int64 or > double? Double is larger - but it lacks the precision of integer variables. Integers are exact. Floating point numbers are only close approximations. So, do you need an exact representation or will an approximation do?
> I see int64 also apparently is known as long and will > hold -9,223,372,036,854,775,808 through 9,223,372,036,854,775,807. Is this large enough? If it is, use it. If not take a look at the Decimal type as well as Double.
> But I'm not good with the E+??? notation so when I'm told double holds > -1.79769313486231570E+308 through [quoted text clipped - 8 lines] > > Sorry, I always felt math was for the computer to figure out not me. How will you know if the computer is giving you the right answer?
 Signature Charles Appel http://charlesappel.home.mindspring.com/ Home of Chuck's Poker Libraries for Delphi, Chuck's Video Poker and Chuck's Toys
Gerald Hernandez - 12 May 2006 23:22 GMT > > VB2003. I need a large positive integer. Which is larger int64 or > > double? [quoted text clipped - 24 lines] > > How will you know if the computer is giving you the right answer? In addition to Charles' comments... Note that while a Double can have in excessive 300 digits of "precision", only the first 16 or so digits are "accurate". This can lead to a very long discussion, but while you might be able to get a very long number, it is really only an approximation, of which the first 16 digits or so are accurate. Note how they described the limits: 1.79769313486231570E+308 for positive values They use that notation for a reason. Only the digits listed could be considered close to accurate, the other 291 digits it can "display" are only an approximation.
You started by saying that you need a very large positive Integer. Well, if that is what you need, then you should stick with Integers. Going back and forth can cause you to lose accuracy.
Gerald
Stephany Young - 13 May 2006 03:33 GMT Just how 'large' an integer do you actually need?
To put the upper limit for an Int64 (Long) into perspective, it is approximately 184 million times the approximate human population of the earth.
It also equates to the number of miles in aproxiamately 1.571 million light years.
If you consider to represent days, it also equates to aproxiamately 1.262 million times the number of days since the big bang.
> VB2003. I need a large positive integer. Which is larger int64 or > double? [quoted text clipped - 14 lines] > > Sorry, I always felt math was for the computer to figure out not me. cj - 13 May 2006 04:11 GMT Thanks for putting it into perspective. The answer is I don't really know how big a number I will need. This is a counter that counts up but I really don't know how fast as it will be based on usage. Being careful makes me try for a type that'll hold a number it'll never hit or perhaps I can reset it to 0 at some value but I'm not sure yet. Frankly I'll have to do some thinking on that. double, decimal are I'm sure large enough I wouldn't have to worry about reseting it. Frankly a integer might be ok but I'd probably have to put in a reset just in case.
anyway thinking about all this makes me wonder about how they all fit and which ones I'll probably use in the future. mostly I use decimal and integer now.
> Just how 'large' an integer do you actually need? > [quoted text clipped - 26 lines] >> >> Sorry, I always felt math was for the computer to figure out not me. Stephany Young - 13 May 2006 04:49 GMT OK. The use you have described puts it into perspective straight away.
If an Int32 counter is incremented once per second, 24/7 forever then it will blow out early in the 69th year
If an Int64 counter is incremented once per second, 24/7 forever then it will blow out early in the 292,271,024th millenium
If an Int32 counter is incremented once per millisecond, 24/7 forever then it will blow out early in the 5th year
If an Int64 counter is incremented once per millisecond, 24/7 forever then it will blow out early in the 4,872 millenium
If a Decimal (with 0 decimal places) counter is used then the blow out point will be considerably longer.
If you expect the counter to be incremented no more frequently than once per millisecond and don't expect it to keep counting for more than 4 years without being reset then an Int32 (Integer) will suffice.
> Thanks for putting it into perspective. The answer is I don't really know > how big a number I will need. This is a counter that counts up but I [quoted text clipped - 39 lines] >>> >>> Sorry, I always felt math was for the computer to figure out not me. Cor Ligthert [MVP] - 13 May 2006 09:50 GMT Stephany,
Nice explanations brings it back to its perspective.
Cor
> OK. The use you have described puts it into perspective straight away. > [quoted text clipped - 60 lines] >>>> >>>> Sorry, I always felt math was for the computer to figure out not me. cj - 13 May 2006 15:00 GMT As Cor mentioned you did a nice job on putting it in perspective. Int32 will do.
> OK. The use you have described puts it into perspective straight away. > [quoted text clipped - 60 lines] >>>> >>>> Sorry, I always felt math was for the computer to figure out not me. Göran Andersson - 13 May 2006 08:29 GMT If you use it for a counter, you should definitely use an integer data type, not a floating point type.
When you reach the limit of an integer, you get an overflow, but when you reach the limit of a floating point number, it just stops counting, as an increase of one has become too small to make a difference.
Also, an integer can count longer than a floating point number of the same size.
The number of bits that a double and an int64 occupies are the same. In the int64, 63 bits are used for the number, and one bit for the sign. In a double, 52 bits are used for the number, 11 bits for the exponent, and one bit for the sign. That means that an int64 can hold a number that is 2048 times larger than the number that a double accurately can handle. For the use as a counter, the 11 bits used for exponent are wasted.
> Thanks for putting it into perspective. The answer is I don't really > know how big a number I will need. This is a counter that counts up but [quoted text clipped - 40 lines] >>> >>> Sorry, I always felt math was for the computer to figure out not me. cj - 13 May 2006 03:44 GMT While I'm on the subject why would anyone use a floating point number (double or single) if they're inaccurate? Why not use decimal? Other than the decimal takes 16 bytes vs the doubles 8.
Also I'm still not sure why double and single list the values they accept in two ranges one for each side of 0. Do they not accept values around 0? I'm sure they do but the documentation doesn't make sense to me.
ie: -1.79769313486231570E+308 through
> -4.94065645841246544E-324 for negative values; 4.94065645841246544E-324 > through 1.79769313486231570E+308 for positive values
> VB2003. I need a large positive integer. Which is larger int64 or double? > [quoted text clipped - 13 lines] > > Sorry, I always felt math was for the computer to figure out not me. Stephany Young - 13 May 2006 04:34 GMT The important thing is, for each range, to look at the signs of the exponents.
The sign of the exponent indicates the direction in which to move the decimal point.
+ means move the decimal to the right
- means move the decimal point to the left
To simplfy it for demonstration purposes let's take a floating point type that allows the ranges:
-1.79E+3 to -4.94E-3 and 4.94E-3 to 1.79E+3
-1.79E+3 equates to -1790 -4.94E-3 equates to -0.00494 4.94E-3 equates to 0.00494 1.79E+3 equates to 1790
Remembering that not every number can be represented exactly in floating point, you can see that we have ranges of:
-1790 through -0.00494 negative values and 0.00494 through 1790 negative values
1790 is the upper limit, -1790 is the lower limit and the closest representations of 0 that we can achieve are 0.00494 and -0.00494.
Now, extrapolate that example up to the Double type and you can see that the ranges are:
-1.79769313486231570E+308 through -4.94065645841246544E-324 for negative values and 4.94065645841246544E-324 through 1.79769313486231570E+308 for positive values
This can be rewritten as:
-179769313486231570[...300 zeroes...]00000000 through -0.000000[...310 zeroes...]000494065645841246544 for negative values and 0.000000[...310 zeroes...]000494065645841246544 through 179769313486231570[...300 zeroes...]00000000 for positive values
This shows that 0 cannot be represented exactly as a Double and the closest representations of 0 that can be achieved are actually:
-0.000000[...310 zeroes...]000494065645841246544 and 0.000000[...310 zeroes...]000494065645841246544
Now, when it comes to dealing with the Decimal type, it holds a signed 128-bit (16-byte) value representing a 96-bit (12-byte) integer number scaled by a variable power of 10.
The scaling factor specifies the number of digits to the right of the decimal point and ranges from 0 through 28.
With a scale of 0 (no decimal places), the largest possible value is +/-79,228,162,514,264,337,593,543,950,335 (+/-7.9228162514264337593543950335E+28).
With 28 decimal places, the largest value is +/-7.9228162514264337593543950335, and the smallest nonzero value is +/-0.0000000000000000000000000001 (+/-1E-28).
As you can see, for each decimal place that you have, you lose one integral place and vice-versa.
With no decimal places you can have the equivalent of a 29 digit number with a range of +79,228,162,514,264,337,593,543,950,335 to -79,228,162,514,264,337,593,543,950,335.
This is 10 digits wider than an Int64 (Long) and the maximum value is approximately 8.5 bollions times larger.
> While I'm on the subject why would anyone use a floating point number > (double or single) if they're inaccurate? Why not use decimal? Other [quoted text clipped - 26 lines] >> >> Sorry, I always felt math was for the computer to figure out not me. cj - 13 May 2006 15:14 GMT Whow! You do a great job of explaining this. I understand now. Just the last question. Why would anyone want to use a imprecise number (floating point)? Well especially when you can do it right.
> The important thing is, for each range, to look at the signs of the > exponents. [quoted text clipped - 111 lines] >>> >>> Sorry, I always felt math was for the computer to figure out not me. Charles Appel - 13 May 2006 15:28 GMT > Whow! You do a great job of explaining this. I understand now. Just the > last question. Why would anyone want to use a imprecise number (floating > point)? Well especially when you can do it right. Doubles take up less space than Decimals and are generally accurate enough within their limitations. I'd have to test this, but my guess is they are also faster than Decimals. How much accuracy you need depends on the specific problem. The Lockheed SR-71 was designed in the 1950s using slide rules. AFAIK, it is still the fastest jet aircraft in the world.
 Signature Charles Appel http://charlesappel.home.mindspring.com/ Home of Chuck's Poker Libraries for Delphi, Chuck's Video Poker and Chuck's Toys
Gerald Hernandez - 13 May 2006 18:18 GMT Excellent explanation!
To address the question of why one would use a Floating Point value... It depends a great deal upon what you need. Take geometric operations for example. If you are using PI and other multiplications / divisions, etc. where you really need floating point values, Doubles make sense. However, programmers need to consider the accuracy and write their code in such a way that the final result will be "accurate enough". This sometimes means doing some interesting things, one of which is ensuring that you perform your calculations by grouping variables of similiar magnitude to minimize rounding errors.
Additionally, the implementation of a Double is currently significantly faster than Decimal due to very complex implementation details. I suspect that at some point in the future, a Decimal datatype will be implemented natively in hardware. At that point, a version of Decimal might unseat Double for many applications.
An interesting bit of trivia... While most CAD applications use the Double datatype for storing coordinates, some of the fastest and best ones out there actually use Integers for storage units. Interim math is performed using Doubles when needed, but underneath the hood they are natively stored as long Integers. While at first this may seem contrary to good sense due to rounding errors, in implementation it gives some significant advantages. First, when Doubles are not required, Integer operations are much faster. But when it comes to rounding errors and such, when you base your system on Integers you can almost exactly know and/or control the accuracy tolerance.
Gerald
> The important thing is, for each range, to look at the signs of the > exponents. [quoted text clipped - 111 lines] > >> > >> Sorry, I always felt math was for the computer to figure out not me.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|