Re: Possible improvements to the LNUM patch?

[David Kastrup <dak@...>]

Ralph Hempel <rhempel@hempeldesigngroup.com> writes:

> Aladdin Lampé wrote:
>
>> Indeed, the calculations (Lua scripts) are provided by the users of
>> my application, and I don't feel like explaining in the
>> documentation that it is forbidden to test whether 1 <
>> decNumber.tonumber("1.5") and that what they should write instead
>> is: decNumber.tonumber("1") < decNumber.tonumber("1.5")...
>
> Users of my original integrated float/integer complained about the
> same thing.

Take a look at the C++ automatic type conversion rules.  All of them.
They were clearly designed "cleverly" so that a user-defined "complex"
data type in C++ would have similar conversion semantics than the
built-in complex type in Fortran.

A whole bunch of complexity just so that one "non-native" feature would
look like native elsewhere.

Unfortunately, what happens when you have

a) a complex data type that loses precision as compared to double or
integer data types
b) a Gaussian complex data type
c) arbitrary precision integral and fractional data types
d) modular arithmetic data types

The problem is that what C++ does with automatic conversions is based on
assumptions about arithmetic data types and precision loss that are
simply invalid for a number of applications.

The complexity buys you one thing, and ruins a dozen other ones.

It is not worth it.  Let the users whine about explicit conversions.
Better than the alternatives.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum