More reasoning based on evidence...

...or the lack of it:

It is known that rounding errors raise the noise floor and blur details in
sounds (pretty STRONG point, if you want to listen to music).

It is known that professional DSP hardware and software immediately get the
signal into a word size significantly larger than the input/output word
size, operate in that domain throughout, and only at the end convert back to
the input/output word size. This is the practice recommended by Microsoft's
DirectX SDK, by the Sound Forge plugin SDK, by Adrian Freed, and by other
experts (pretty STRONG point, if you ever pay any attention to people with
lots of experience in the domain).

To my knowledge, our information about performance degradation in Csound
compiled all double is purely inferential and anecdotal. Such hits as are
reported seem relatively small. It is purely conjectural (i.e. a WEAK point)
at this time that there would be a significant performance degradation.

As a composer, I too work in the way described below, running files over and
over and over and over... to tweak them, and some of them run hours for mere
minutes of music. I want it to go fast too, but the people who end up
listening to music don't give a damn how long it took me to make. So, I end
up taking as much time as it takes... until I just can't improve the sound
any more.

I used to sometimes run files for literally DAYS. Now it never seems to be
more than a few hours. And as time as has gone on, the computer has been
able to run more and more of my thick scores in real time.

I think we all agree that the argument is inconclusive without more
evidence, which in the nature of the case can only come from some sort of
controlled test, which in turn can only come from an all-double Csound.
Since musical quality is more important to me than speed, and I know it is
also more important to many other musicians, I move that Csound be built
(optionally) all double. That helps us sound quality freaks and hurts no
speed freaks.

At that point, we will do tests on various platforms and find out what the
performance picture actually is.

-----Original Message-----
From: Ed Hall 
To: Csound 
Date: Sunday, June 06, 1999 2:40 PM
Subject: Re: Higher numerical precission in Csound


>Much of the "work" performed by Csound consists of buffering samples
>(as tables, delays, A-rate variables, ins and outs, etc.); the 24-bit
>mantissa of a float is plenty of resolution for this purpose.  Of the
>rest, most calculations aren't precision-sensitive enough to see any
>advantage from doubles vs. floats.  A few (e.g. filter coefficients,
>long exponential curves) will gain useful accuracy with doubles.  And
>there is no doubt a need for doubles in Csound instruments, since much
>of applied mathematics is grist for the creative mill when using Csound.
>In these cases, doubles should be an option.
>
>But when the question is "whither canonical Csound," I can't see making
>such an all-encompassing change with so few proven benefits--and with a
>significant performance impact.  The case made for mandating the use of
>doubles throughout Csound just hasn't been that strong.
>
>Some respondents here claim that run time speed is only important in live
>performance.  I disagree.   I don't know what your working methods are, but
>I typically run a given proto-score and orchestra dozens of times in the
>process of writing them.  So live, real-time playback is hardly the only
>situation where running time is important.  Taking even a 10% hit in run
>time is hardly insignificant when a score is already running 5-10 times
>slower than real-time.  Perhaps for some of you the first playback is the
>last.  I'm just not that good, and there must be at least a few other
>Csounders who are similarly ungifted and impatient.
>
>As for the claim that doubles are as fast, or faster, than floats: show
>us the numbers--for Csound, compiled with a modern compiler.  Use the
>Xanadu benchmark, or similar.
>
> -Ed
>
>
>