is there any other way of storing a numeric value that has decimal places but have more than 29 digits?

Do you actually have numbers that will accurately contain more than 29 decimal places? My thought would be no, and the decimal type has the most precise precision of any .NET type that I know of, so you may be stuck with that.

You must be working on some math or science application for anything to need to display or even be able to handle that type of precision. You may want to read over the following similar discussion:

...also, from the previous link, read the following closely:

"The decimal type has a larger precision than any of the built-in binary floating point types in .NET, although it has a smaller range of potential exponents. Also, many operations which yield surprising results in binary floating point
due to inexact representations of the original operands go away in decimal floating point, precisely because many operands are specifically represented in source code as decimals. However, that doesn't mean that all operations suddenly become accurate: a third
still isn't exactly representable, for instance. The potential problems are just the same as they are with binary floating point. However, most of the time the decimal type is chosen for quantities like money, where operations will be simple and keep things
accurate. (For instance, adding a tax which is specified as a percentage will keep the numbers accurate, assuming they're in a sensible range to start with.) Just be aware of which operations are likely to cause inaccuracy, and which aren't.
As a very broad rule of thumb, if you end up seeing a very long string representation (ie most of the 28/29 digits are non-zero) then chances are you've got some inaccuracy along the way: most of the uses of the decimal type won't end up using very
many significant figures when the numbers are exact. If you find yourself using inaccurate numbers, you should make sure that you expected it, and consider why you're using the decimal type in the first place. (In some situations it'll make sense
despite the performance hit; in many it won't.)"

## ias0nas

Member

31 Points

309 Posts

## 40 decimal places

Apr 23, 2010 04:40 AM|ias0nas|LINK

Hello,

Sorry if this is in the wrong place.

Is there a way in VB .NET to have a decimal variable with 40 decimal places?

Thank you

## rtpHarry

All-Star

39506 Points

8949 Posts

## Re: 40 decimal places

Apr 23, 2010 08:26 AM|rtpHarry|LINK

It looks like the decimal type is limited to 29 digits:

## ias0nas

Member

31 Points

309 Posts

## Re: 40 decimal places

Apr 26, 2010 12:24 PM|ias0nas|LINK

Thanks rtpHarry,

That's what I'm asking, is there any other way of storing a numeric value that has decimal places but have more than 29 digits?

Thanks

## atconway

Star

12060 Points

2742 Posts

## Re: 40 decimal places

Apr 28, 2010 03:17 PM|atconway|LINK

Do you actually have numbers that will

contain more than 29 decimal places? My thought would be no, and the decimal type has the most precise precision of any .NET type that I know of, so you may be stuck with that.accuratelyhttp://msdn.microsoft.com/en-us/library/hfa3fa08.aspx

You must be working on some math or science application for anything to need to display or even be able to handle that type of precision. You may want to read over the following similar discussion:

http://stackoverflow.com/questions/1132765/adjusting-decimal-precision-net

...also, from the previous link, read the following closely:

"The decimal type has a larger precision than any of the built-in binary floating point types in .NET, although it has a smaller range of potential exponents. Also, many operations which yield surprising results in binary floating point due to inexact representations of the original operands go away in decimal floating point, precisely because many operands are specifically represented in source code as decimals. However, that doesn't mean that all operations suddenly become accurate: a third still isn't exactly representable, for instance. The potential problems are just the same as they are with binary floating point. However, most of the time the decimal type is chosen for quantities like money, where operations will be simple and keep things accurate. (For instance, adding a tax which is specified as a percentage will keep the numbers accurate, assuming they're in a sensible range to start with.) Just be aware of which operations are likely to cause inaccuracy, and which aren't.As a very broad rule of thumb, if you end up seeing a very long string representation (ie most of the 28/29 digits are non-zero) then chances are you've got some inaccuracy along the way: most of the uses of the decimal type won't end up using very many significant figures when the numbers are exact. If you find yourself using inaccurate numbers, you should make sure that you expected it, and consider why you're using the decimal type in the first place.(In some situations it'll make sense despite the performance hit; in many it won't.)"