[racket] LC53

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 <norman at astro.gla.ac.uk>
To: Hendrik Boom <hendrik at topoi.pooq.com>
Cc: users at racket-lang.org
Subject: Re: [racket] LC53
Message-ID: <37E7D524-8E22-4F35-8D05-8C2A993B57F8 at 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 <hendrik at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121121/314d6814/attachment.html>