Lua is faster than Fortran???

[sturlamolden]

On 4 Jul, 16:47, "bart.c" <ba... at freeuk.com> wrote:

> I suspect also the Lua JIT compiler optimises some of the dynamicism out of
> the language (where it can see, for example, that something is always going
> to be a number, and Lua only has one numeric type with a fixed range), so
> that must be a big help.

Python could do the same, replace int and float with a "long double".
It is 80 bit and has a 64 bit mantissa. So it can in theory do the job
of all floating point types and integers up to 64 bit (signed and
unsigned). A long double can 'duck type' all the floating point and
integer types we use. There is really no need for more than one number
type. For an interpreted language, it's just a speed killer. Other
number types belong in e.g. the ctypes, array, struct and NumPy
modules. Speed wise a long double (80 bit) is the native floating
point type on x86 FPUs. There is no penalty memory-wise either,
wrapping an int as PyObject takes more space. For a dynamic language
it can be quite clever to just have one 'native' number type,
observing that the mantissa of a floating point number is an unsigned
integer. That takes a lot of the dynamicity out of the equation. Maybe
you like to have integers and floating point types in the 'language'.
But that does not mean it should be two types in the
'implementation' (i.e. internally in the VM). The implementation could
duck type both with a suffciently long floating point type, and the
user would not notice in the syntax.

MATLAB does the same as Lua. Native number types are always double,
you have to explicitly create the other. Previously they did not even
exist. Scientists have been doing numerical maths with MATLAB for
decades. MATLAB never prevented me from working with integers
mathematically, even if I only worked with double. If I did not know,
I would not have noticed.

a = 1;          % a is a double
a = 1 + 1;      % a is a double and exactly 2
a = int32(1);

Sturla