[racket] LC53

On Wed, Nov 21, 2012 at 09:36:14AM +0000, Norman Gray wrote:
> 
> 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

There are quite a few algorithms that need you to calculate a sum of 
products.  Using double-precision for the accumulator will avoid the 
accumulation of roundoff errors.  You end up with a precise 
single-precision result.

-- hendrik