Re: Possible improvements to the LNUM patch?

[David Kastrup <dak@...>]

Asko Kauppi <askok@dnainternet.net> writes:

> David Kastrup kirjoitti 15.4.2008 kello 23:13:
>> 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.
>
> While this may be true as to C++, I beg to disagree on its
> applicability to Lua, or the LNUM patch.
>
> LNUM patch having a complex number mode, I kind of take that as
> criticism for even bringing it in (maybe I'm just jumping for no
> reason here?).

When I explain why automatic conversion lattices for user-defined types
are a bad idea as compared to built-in types, you take that as criticism
against a built-in complex type?

Huh?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum