No, unfortunately using decimal instead of double is no option.
First, neither is a double represented as a fraction, nor is a decimal "precise". In fact, both types are floating point types, meaning they both have three components: a sign, a mantissa (i.e. the digits) and an exponent (a scale factor, i.e. the position of the point) and work basically the same way.
There are two major differences between decimal and double:
- Decimal has a base of 10, while Double has a base of 2. Humans are used to base 10, so we can directly work with decimals, while we always have to convert doubles to base 10 in order to use them (e.g. on ToString() or Parse()), which unfortunately doesn't work well with number-parts smaller than 1 (i.e. it's not possible to represent "decimal 0.1" (meaning 1/10) in a finite binary number and thus as double). Hence we get conversion errors with double which we do not get with decimal.
Note that this not a fundamental type problem: Were humans used to base 30 instead, then they would have the same problem with decimal as we have now with double (i.e. it's not possible to represent "tri-decimal 0.1" (meaning 1/30) in a finite decimal number and thus as decimal).
- Different ranges for mantissa end exponent. A double takes 8 bytes and has a 52-bit mantissa and an 11-bit base-2 exponent, while a decimal takes 16 bytes and has a 96-bit mantissa and a 5-bit base-10 exponent. This means that a decimal indeed can have much more precise digits, but a double can represent very much larger and smaller numbers than a decimal.
Hence, decimal is interesting in situations where you deal with discrete units (e.g. money) or when you traditionally would have used fixed-point numbers (e.g. lenght-measurement in architecture) and need to maintain exact decimal representations for addition, subtraction and multiplication.
But decimal has some important disadvantages:
- No special function support in the .Net framework (e.g. no Math.Exp for decimal) - hence we can't use it in Iridium anyway.
- It uses 16 byte instead of 8 byte, so it needs more memory, and I'd also assume it to be very much slower than double since a CPU can't deal with any base-10 representation directly.
- Its too small range makes it almost useless in science (e.g. you can't represent the planck constant or the electron mass in a decimal).
All in all, no, sorry, decimal is no option. But what we could consider to provide instead is an integer exponent power overloading, maybe that could solve your specific problem?