# What do you get when you cross a multi-precision integer with a floating-point number?

I'm working on adding multi-precision integers to the suite of numeric types in my APL interpreter, but I'm not sure what to do about the odd type-combinations that now arise. I now have the following types:

``````IMM "atomic" small integer
FIX full-width integer
FLO floating-point double
MPI multi-precision integer
``````

I have a variable which controls which larger type to use for integer overflow, either FLO or MPI. Mixed MPI/IMM/FIX operations, since they're all integers, can simply promote to the widest type and produce a result of that type. And mixed FLO/IMM/FIX operations can follow the same pattern since a double can comfortably accommodate all the values of a 32-bit integer. This covers most of the cases. But it leaves me with these type combinations which don't have an obvious (to me) rule to follow.

``````FLO {+-*/} MPI
MPI {+-*/} FLO
``````

Having written this out, I suppose there really is an obvious solution (multi-precision floating-point). But I don't want to do that right now. Is there a sensible shortcut I can take (for now)?

As a "worst case" scenario that at least delivers some kind of result, I can implement conversions between these two types. But there's potential loss of data each way.

``````FLO -> MPI loses fractional part of floating-point number
MPI -> FLO loses precision from integer
``````

Another option is to add a rational number type. This is stored as two integers, which usually will need to be multi-precision, and can represent any floating point value including the result of an operation between floating point and a multi-precision integer.

This way there is no loss of information. But there is a lot of work involved and should only be done if the user wants it.

• A rational/multi-precision type was already in the plan but I hadn't realized that it would fix this hole. I'd sooner do this than mess with the details of floating-point. Commented Apr 30, 2015 at 5:07

As a start, if we begin to consider the actual quantities involved then some subcases might be handled easily. It might also depend upon the operation we want to do.

``````MPI {+-} FLO
FLO {+-} MPI
``````

If the FLO has a zero fractional part, then it can be converted to MPI losslessly. If it does have a fraction, then we probably want to keep the fraction and we ought to convert the MPI to FLO and cope with the loss of precision somehow.

``````MPI * FLO
FLO * MPI
``````

Now here, we might want to perform a scaling operation on the MPI, so perhaps a little algebra can wiggle us out a result.

``````FLO = int + (1/frac)
R = MPI * FLO
= MPI * (int + (1/frac))
= (MPI * int) + (MPI/frac)
``````

All of this seems to lead to a user-configurable parameter that selects which type to yield.

Or if the MPI is exactly representable as a double, then it can be converted without fear. Although the result may lose precision if the values are near the representation limits.