I agree that, given a modern x86 computer, it is possible to just ignore
integer arithmetic altogether and use floats. There may be some numerical
programs that can be written to run faster using integer arithmetic than
floats, but this would be rare. There may also be some numerical programs that
need the higher precision of integer arithmetic than floats (on a 64-bit x86,
single-precision is 64-bit and double-precision is 128-bit, as compared to the
floats which provide only a 72-bit mantissa for an 80-bit float), but this
would also be rare.
The Lua language does only support floats, and does not have an integer data
type. I have written software for generating CNC gcode, and may write a
general-purpose CAM program later on. For something like that, it is a good
idea to use floats only. Most machinists are not programmers and they largely
seem baffled as to why programming languages distinguish between integers and
floats --- the scientific calculator that they use everyday when writing gcode
manually doesn't make any such distinction. It seems to make about as much
sense as having separate data types for even numbers and odd numbers --- they
are all just numbers, after all, so why complicate the subject with arbitrary
distinctions? :-)
I'm mostly thinking in terms of 16-bit processors that don't have a numerical
coprocessor when I say that mixed-precision integer arithmetic is important. In
the old days, that meant desktop computers --- now it only means
micro-controllers. Scheme will never be used on micro-controllers, and lack of
support for integer arithmetic is only one of the many reasons why --- but I
think that Scheme is a good language for desktop computers.
Message: 2
Date: Wed, 21 Nov 2012 09:36:14 +0000
From: Norman Gray <nor...@astro.gla.ac.uk>
To: Hendrik Boom <hend...@topoi.pooq.com>
Cc: users@racket-lang.org
Subject: Re: [racket] LC53
Message-ID: <37e7d524-8e22-4f35-8d05-8c2a993b5...@astro.gla.ac.uk>
Content-Type: text/plain; charset=windows-1252
Hendrik (and Hugh), hello.
OK -- I'll bite, if only to see where this argument heads to.
On 2012 Nov 20, at 13:56, Hendrik Boom <hend...@topoi.pooq.com> wrote:
> On Tue, Nov 20, 2012 at 11:02:06AM +0000, Norman Gray wrote:
>>
>> I think list members might experience a certain amount of surprise at your
>> conclusions...
>>
>> On 2012 Nov 20, at 02:34, Hugh Aguilar wrote:
>>
>>> For a numerical program it is necessary to have mixed-precision arithmetic.
>>> [...] Scheme, Python, Ruby, C/C++, Fortran, Java, etc., don't have this
>>
>> ...that Fortran is unsuitable for numerical programming,
>
> Starting with Fortran, high-level languages have forgotten that the
> product of two numbers should be accurately available as a
> number with twice the precision.
>
> NOw if the numbers were approximate to start with, this is no big deal,
> but if they were exact (as integers usually are), it can be crucial for
> some numerical algorithms. It mystifies me why this situation has
> persisted for over half a century.
I think that 'should', 'can be' and 'mystifies' are the key words or phrases
here.
I suspect that, for most people, 'numerical programming' means the
stock-in-trade of scientific programming -- namely the calculations of
numerical values for equations of all types, including integration,
differentiation, interpolation, and so on and so (very much) forth. That is,
we're talking about floats, in all but a few cases; integer-only algorithms are
a very specialised category of 'numerical programming'
Floats, as you note, are approximate from the outset (especially if what they
represent is measured data; apart from ordinal data, data is approximate).
Having any non-trivial float calculation double in precision at each operation
would be? not terribly sensible. Thus, contra your 'should', it is possibly
not unreasonable to have such a facility available in a language, or in a
dialect of a language, but it is of use to such a small fraction of a
language's users (thinking of Python, C, Fortran, for example), that the extra
specification and implementation effort may have a negative utility.
So Fortran hasn't 'forgotten' that arbitrarily extended precision 'should' be
available, certainly not for floats, and rarely even for integers. And I'm
sure that approximately zero people here have difficulty (Hugh) 'grasping' the
concept of mixed-precision arithmetic. This was never particularly sensible in
(the main dialect of) a general purpose language, and there is no mystery here
at all.
Best wishes (in slight puzzlement),
Norman
--
Norman Gray : http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK
____________________
Racket Users list:
http://lists.racket-lang.org/users
