I’m looking for a better solution to a sticky question. I had a fairly short “clever” solution until I realized it wasn’t correct in some cases i.e. it was wrong.
I’m creating a function to return the type code of the variable necessary to contain the precision of variables of the two input type codes passed to the routine. I’m using the chart to the right as the order of precision for the types. This is not what IDL uses for it’s promotion; the integer types don’t promote to a floating point type unless one of the types is already a floating point type.
For example, if the inputs are byte (type 1) and integer<br />(type 2), then an integer can hold them both:
IDL> print, mg_convert_type(1, 2) 2
But if the inputs are a double (type 5) and a complex (type 6), it takes a double complex (type 9) to hold them both:
IDL> print, mg_convert_type(5, 6) 9
In particular, the conversions between the signed and unsigned integer types caused my previous solution problems i.e. long and ulong64 produce float, but long and ulong produce long64.
Any clever solutions? Currently, I’m using a 16 by 16 lookup table with the precomputed answers.