lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

David Kastrup kirjoitti 15.4.2008 kello 23:13:
Ralph Hempel <> 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

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?). Anyways, I don't see the act to ruin anything, in the context of Lua.