I'm trying to the the mass of the black hole at the center of this galaxy, I have the mass in solar masses, but need it in kg. However when I try to convert (1Msolar = 1.989*10^30kg) idl just gives me 0.0000. I have no idea what I'm doing wrong and I tried just telling idl to print both 1.989*10^30 and 1989000000000000000000000000000 and the outputs are 0.00000 and -1 respectively. Can someone please explain why this is happening?
-
do not know IDL but here some hints: 1. it looks like `data-type` overflow what `data-type` are you using for storing the values? (type: floating/fixed/arbitrary, number of bits per mantissa/exponent or integer/decimal) 2. there may be also something wrong with your code (which you did not provided) 3. you could hit some barrier of any function you are using. – Spektre Oct 01 '16 at 07:56
2 Answers
This is a type conversion error/overflow issue. When you use large numbers you either need to explicitly define them as long
or long64
(i.e., 64-bit long integer) for integer numbers. For real numbers, you can use float
or double
and to do this, the easiest way is the following:
msun = 1.989d30
which is equivalent to 1.989 x 1030 as a double-precision floating point number. If you want single precision, then just do the following:
msun = 1.989e30
To make a 32- or 64-bit long integer, just use:
msun = 1989L * 10L^(27)
or for 64-bit
msun = 1989LL * 10LL^(27)

- 308
- 5
- 11
-
Yep, that answer looks completely correct. Just a note - *all* computer languages that are based on C/C++ datatypes will potentially have this problem, including Matlab. One difference is that many languages just default to "double" for all numbers, to avoid this issue. This is fine for doing simple computations, but can be wasteful and slow if you have huge arrays of numbers, where each double takes up 8 bytes. In short, "know your data" and use the appropriate data type. – Chris Torrence Oct 04 '16 at 14:43
-
Thank you! This was really confusing me I didn't even know that was a thing. – LexieStark Oct 07 '16 at 02:54
I agree with @honeste_vivere's answer about overflow and data types, but I would add that I often change units to avoid this. I frequently have densities that are order 1e19/m^3, so I cast density in units of 1e19/m^3 and then deal with numbers that are order 1. This prevents math errors during least squares fits and other operations that might do things like squaring my data.

- 1,416
- 1
- 19
- 34