What data type can accurately store the largest numerical value?

[UncleRonin]

I want to work with numbers of 30+ digits using only addition and multiplication. What data type can accurately perform these calculations? I know Decimal can handle up to 29 digits with accuracy but I've heard that Single and Double can store much greater values except that they lose some accuracy... will the values calculated be accurate, though, if only addition and multiplication and positive numbers are used? *scratch* I'm not clued up on the data types so help would be lank appreciated...

 

[JuggaloBrotha]

this is what my intro to vb class told me:
Data Types:
Boolean
Byte (0 to 255)
Char
Date
String
Decimal
Object
Short (-32,768 to 32,767)
Integer (-2,147,483,648 to 2,147,483,647)
Long (larger whole numbers)
Single (floating point accuracy to 6 digits)
Double (floating point accuracy to 14 points)

so my guess is that for 30character number you'll want to use the Double type

 

[UncleRonin]

*nod* okay... but how accurate is it though? so if I multiply 19999999999999999999999999999999999999999999 by itself then the result will be exact? that's the thing I'm trying to find out and since I have no idea what 'floating point accuracy to 14 points' means *shrug* I'm at a loss! *falls over*

 

[JuggaloBrotha]

i'd be lying if i said i knew the answer, i tend use the Integer and Decimal types the most, so i dont know how accurate the single & double are

 

[UncleRonin]

Well that makes to of us! I think 'floating point accuracy to 14 points' means that the first 14/15 digits of the number are exact but from then on the digits may be incorrect depending on the operation *scratch* If there was some documentation on how exactly the types Single and Double it would be possible to figure it out... that's IF there is documentation... *sigh* bleh!

 

[jimmajsterski]

Years back, mainframes sometimes would give different results, because of improving hardware architecture (like larger registers). Software developers and programmers were informed by hardware designers about new specs.
You may need to ask Intel or AMD or whoever made your CPU chip. There may be differences between vendors.

 

[UncleRonin]

*gag* That is absolutely terrible! Especially since the program I'm writing is gonna be used on multiple PC's... *scratch* I guess I'll have to find a mathematical method to overcome the accuracy issue. Shot for the help though!

 

[DavidT_macktool]

No matter how large or small the size of the number, real and float can only represent 7 and 15 digits of precision respectively. Most of the time that works we'll. After all, few things are measured with 15 digits of precision. Using a value of Pi of 3.141592653589793 works well for computing the diameter of a circle with fabulous precision.

When you don't want to use approximate numeric data types, SQL Server has an exact numeric data type called numeric. It's also called decimal and the two names can be used interchangeably. For those of you who've programmed on mainframes, numeric is like Packed Decimal.
By using a numeric (38, 37) it's possible to store 37 digits to the right of the decimal.

Here is some light reading on floating point math.
http://www.petebecker.com/js200006.html

 

[jmcilhinney]

I don't know what cave you've been living in but there's several million dollars worth of work gone into developing the MSDN library, so I'd call that documentation. As for the numerical types, each has a MaxValue property that will tell you exactly how large that type can be. As for floating point arithmetic, the issues associated with it have been around for I-don't-know-how-long and will be documented all over the place. Floating-point precision means significant digits in mathematical terms. If you want calculations on decimal numbers with no round-off errors then you need to use Decimal. The largest possible Decimal, as reported by the MaxValue property, is 79228162514264337593543950335.

Edit: Removed "Decimal is fixed-point so you can have numbers like 79228162514264337593543950334.9999999999."

 

[UncleRonin]

@DavidT macktool: Thanks for the info... clears up a lot of stuff

@jmcilhinney: The MSDN library isn't THAT good, it gives the basic descriptions of EVERYTHING but nothing indepth unless you sift through mounds of stuff which isn't always related (in my experience). Bleh... *wanders back to cave*

 

[jmcilhinney]

In my opinion the MSDN library IS that good if used properly. I would esitimate that I've learned about 80 - 90% of what I know from the MSDN library, and then most of that from the class overview and member listing topics. Most people give no thought to using namespaces as a way of narrowing down their searches. How many people ask "How do I write to a text file?". Look in the System.IO namespace and see what classes are available. Don't know there's a System.IO namespace? I'd say why not? Everyone should have a general idea of what namespaces are available and where to look for a definitive list. Once you know that a SteamWriter is for writing to text files you read the class overview and then the member listing. Bang! You can write to a text file. Basically, people have to take responsibility and make an effort and not expect the knowledge to come to them. End rant here.

 

[DavidT_macktool]

When did the attitude of the forum switch from 'helpful' to 'belittling'? People should feel free to ask any questions and get answers and information without being talked down to. That was a great question to start a thread with, and was asked in the true spirit that the forum is based on - sharing knowledge. There can be no reason to start a reply with 'I don't know what cave you've been living in'. If that remark was directed to me, I'v been in a large cave with lots of 'friendly' programmers.

I apologize for the forum, UncleRonin.

 

[jmcilhinney]

When did the attitude of the forum switch from 'helpful' to 'belittling'? People should feel free to ask any questions and get answers and information without being talked down to. That was a great question to start a thread with, and was asked in the true spirit that the forum is based on - sharing knowledge. There can be no reason to start a reply with 'I don't know what cave you've been living in'. If that remark was directed to me, I'v been in a large cave with lots of 'friendly' programmers.

I apologize for the forum, UncleRonin.

I have no issue with the original question. The "cave" comment was in direct response to this:

If there was some documentation on how exactly the types Single and Double it would be possible to figure it out... that's IF there is documentation... *sigh* bleh!

This and other forums are here so people can get help and share knowledge, but to claim that you can't find the information yourself because there is no documentation is quite ludicrous. Here's a quote from the MSDN topic for the Double Data Type:

Double Data Type (Visual Basic)

Holds signed IEEE 64-bit (8-byte) double-precision floating-point numbers ranging in value from -1.79769313486231570E+308 through -4.94065645841246544E-324 for negative values and from 4.94065645841246544E-324 through 1.79769313486231570E+308 for positive values. Double-precision numbers store an approximation of a real number.
var ExpCollDivStr=ExpCollDivStr; ExpCollDivStr = ExpCollDivStr + "ctl00_LibFrame_MainContent_ctl010ae597d,"; var ExpCollImgStr = ExpCollImgStr; ExpCollImgStr = ExpCollImgStr + "ctl00_LibFrame_MainContent_ctl01img,"; Remarks
The Double data type provides the greatest and smallest possible magnitudes for a number.
The default value of Double is 0.
var ExpCollDivStr=ExpCollDivStr; ExpCollDivStr = ExpCollDivStr + "ctl00_LibFrame_MainContent_ctl0278fd598,"; var ExpCollImgStr = ExpCollImgStr; ExpCollImgStr = ExpCollImgStr + "ctl00_LibFrame_MainContent_ctl02img,"; Programming Tips

• Precision. When you work with floating-point numbers, keep in mind that they do not always have a precise representation in memory. This could lead to unexpected results from certain operations, such as value comparison and the Mod operator. For more information, see Troubleshooting Data Types.
• Trailing Zeros. The floating-point data types do not have any internal representation of trailing 0 characters. For example, they do not distinguish between 4.2000 and 4.2. Consequently, trailing 0 characters do not appear when you display or print floating-point values.
• Type Characters. Appending the literal type character R to a literal forces it to the Double data type. Appending the identifier type character # to any identifier forces it to Double.
• Framework Type. The corresponding type in the .NET Framework is the System.Double structure.

That topic also has links to similar topics for the Single and Decimal types. There are also topics for the Double structure, Single structure, Decimal structure, etc., plus the member listing for each. Ask the question if you want to by all means, but don't claim that you have to because Microsoft hasn't provided sufficient documentation. Like I said, I've learned the majority of what I know from that very source, so I know just how useful it is.

 

[jmcilhinney]

Let me add something further. The "cave" quip was intended to be tongue-in-cheek. It was not meant to be abusive but I can see how it could have been construed that way. I apologise for any misunderstanding. You'll notice that I did go on to answer the question immediately afterwards, if in a slightly brusque manner. That said, I still maintain that MSDN is the best documtentation you find in the software development industry and every .NET developer should make it their first port of call when they need information. It takes a little perseverence and trial and error to get the most out of it, but that's not a reason to avoid it. It's a reason to use it more so that you get up to speed with it ASAP.

 

[UncleRonin]

*moves rock to secure cave entrance and leaves* twas brusque indeed I did actually look in the MSDN about data types, specifically Double, Single and Decimal... that's where I heard of Decimal for the first time (My VB.NET is self-taught) the main reason I started this thread was because of the whole accuracy issue... which, you must admit, the MSDN isn't totally clear about (to those like myself at least). I use it for help often, I'd be lying if I said I didn't! It makes life ALOT easier, we all know. But there are a lot of times when it doesn't clear up things and you have to fend for yourself (which sucks, because then people start saying that you live in a cave!). Now that all is has been settled and the cave is secure let us sally forth into the world of programming, with the MSDN on one hip and this forum on the other...