| It is/was support for Sound Blaster direct. It need the file
blaster.c as well. I di dhave it working in 8bit mode, and slowish
speeds, but I got lost with 16bit samples -- lack of documentation,
lack ofbrain power and lack of time. It is available for anyone who
wants to take it over. Jim Stevenson always wanted it I remember.
==John ff
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa02046;
17 Feb 97 13:40 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ab24639;
17 Feb 97 13:43 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Mon, 17 Feb 1997 13:43:16 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (NAA22614);
Mon, 17 Feb 1997 13:37:28 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Mon, 17 Feb 97 13:37:00 GMT
Received: from smtp.utexas.edu [128.83.126.2] by hermes via SMTP (NAA22487);
Mon, 17 Feb 1997 13:36:37 GMT
Received: (qmail-queue invoked by uid 0); 17 Feb 1997 13:36:15 -0000
Received: from unknown (HELO mail.utexas.edu) (128.83.126.1)
by smtp.utexas.edu with SMTP; 17 Feb 1997 13:36:15 -0000
Received: from slip-102-30.ots.utexas.edu (slip-102-30.ots.utexas.edu [128.83.176.30])
by mail.utexas.edu with SMTP id HAA08543;
Mon, 17 Feb 1997 07:36:10 -0600 (CST)
Date: Mon, 17 Feb 1997 07:36:10 -0600 (CST)
Message-Id: <199702171336.HAA08543@mail.utexas.edu>
X-Sender: r.pinkston@mail.utexas.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: gb141@columbia.edu
From: Russell Pinkston
Subject: Re: Csound decimal point precision
Cc: csound@maths.ex.ac.uk
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
>Hello,
>
>I'm reposting my question again: is there a way to perform calculations
>involving more than 3 decimal places or exponential notation in an
>orchestra file?
>
>Csound seems to ignore decimal places after 3. If I define a constant
>such as 0.0000000001 it seems to think it's 0.000 . I'm trying
>to code a sones-to-dB conversion formula in an insturment. It
>involves 10^-12.
>
>Thanks.
>Gregory Boduch
>gb141@columbia.edu
>
>
> One way to do it is calculate 1/100000000000 in your orchestra.
>The precision issue is at the translation from text to float, not
>internally (I think). Very large numbers should work fine.
>
>Mike Berry
>mikeb@mills.edu
>
>
Actually, that doesn't work - at least, not on my version of csound. It
seems that the largest number of digits I can enter is 10 - i.e.,
1000000000. is OK, but not one more 0. But you can do this:
ival = 1/(1000000 * 1000000) ;10^-12
or
ival = exp(12*log(10)) ;10^-12
and Csound does actually compute and store the correct result. In any case,
you can't prove it by using the Csound print function unless you do
something like:
print ival*1000000*1000000
which does, indeed, print out "1.000" when ival is 10^-12. Saying
print ival
just prints a "0.000"
----------------------------------
Russell F. Pinkston, D.M.A.
Associate Professor of Composition
Director, Electronic Music Studios
School of Music
The University of Texas at Austin
Austin, TX 78712
[512-471-0865]
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa02063;
17 Feb 97 13:43 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ab24726;
17 Feb 97 13:47 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Mon, 17 Feb 1997 13:45:38 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (NAA22103);
Mon, 17 Feb 1997 13:33:43 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Mon, 17 Feb 97 13:33:30 GMT
Received: from pp@goggins.bath.ac.uk [138.38.32.13] by hermes
via ESMTP (NAA22064); Mon, 17 Feb 1997 13:33:29 GMT
From: jpff@maths.bath.ac.uk
Message-Id: <199702171333.NAA22064@hermes>
Received: from maths.Bath.AC.UK (actually host xenakis.maths.bath.ac.uk)
by goggins.bath.ac.uk with SMTP (PP); Mon, 17 Feb 1997 13:33:23 +0000
To: ggerrard@ozemail.com.au
Cc: csound@maths.ex.ac.uk
In-Reply-To: <199702171140.WAA04502@oznet02.ozemail.com.au> (message from Graeme Gerrard on Mon, 17 Feb 97 22:43:23 +1100)
Subject: Re: Manual....and formats
Date: Mon, 17 Feb 97 13:32:59 GMT
Source-Info: From (or Sender) name not authenticated.
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
I voted against PDF as I DID know what it was, and it is a real pain.
Symantecs changed the documentation for their MAC C compiler to it,
and now it is much harder to find things and use. Difficult to read
physically, takes too much screen space, and lots else wrong with it.
Do not assume that knowing something leads to being in favour of it.
I wish I did not know what PDF is.
==John ff
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa02424;
17 Feb 97 15:21 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ab26776;
17 Feb 97 15:24 GMT
Received: from gateway.senet.com.au by goggins.bath.ac.uk with SMTP (PP);
Mon, 17 Feb 1997 15:24:37 +0000
Received: from ds05-f7.senet.com.au (ds05-F7.senet.com.au [203.26.217.196])
by gateway.senet.com.au (8.7.3/8.6.9) with SMTP id BAA29418;
Tue, 18 Feb 1997 01:53:43 +1030
Date: 18 Feb 97 01:36:40 +1030
Subject: Re: Csound build
From: Nathan Day
To: Csound list , John Fitch ,
Michael Gogins
X-Mailer: Cyberdog/1.2
Message-Id:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Is there any point in going to double precision floats, single precision
floats have a dynamic range of over 910 dB and a signal to error ratio of a
least 138 dB below the peak signal level, the threshold of pain is 132dB
above the threshold of hearing. Though most processor now can handle these
size numbers themselves quiet well, my PowerPC processor has now problem
with them, double precision requires twice the memory as single precision
which means our caches fill up quicker causing more cache misses and
therefore slowing down of calculations. I am very interested to know if
there is any signifcant errors, or any, in the 16 most signifcant bits in
numerous single precision calculation, as in DSP, as I plan to do a thesis
on it for my Audio Engineering class, perhaps it has some effect through
filter co-effectiants.
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa02476;
17 Feb 97 15:30 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa27116;
17 Feb 97 15:33 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Mon, 17 Feb 1997 15:33:08 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (PAA07298);
Mon, 17 Feb 1997 15:24:34 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Mon, 17 Feb 97 15:24:18 GMT
Received: from root@gateway.senet.com.au [203.11.90.1] by hermes
via ESMTP (PAA07238); Mon, 17 Feb 1997 15:24:07 GMT
Received: from ds05-f7.senet.com.au (ds05-F7.senet.com.au [203.26.217.196])
by gateway.senet.com.au (8.7.3/8.6.9) with SMTP id BAA29420
for ; Tue, 18 Feb 1997 01:53:46 +1030
Date: 18 Feb 97 01:52:32 +1030
Subject: Beginner needs help
From: Nathan Day
To: CSound Mailing List
X-Mailer: Cyberdog/1.2
Message-Id:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
OK heres another beginners question, I am writing my first orc file and
this
ilen = p3 ; length
iamp = ampdb(p4) ; amplitude
ioct = octpch(p5) ; pitch class to decimal octaves
kpvari randi .05, 25, 0.666 ; low part
asour adsyn iamp/ampdb(70), cpsoct(ioct - 1 + kpvari)/219.5, 1,
"Light stab.adsyn"
a1 alpass asour, 1, .1443
a2 alpass asour, 1, .1767
kpvari randi .05, 25, 0.222 ; mid part
asour adsyn iamp/ampdb(70), cpsoct(ioct + kpvari)/219.5, 1, "Light
stab.adsyn"
a3 alpass asour, 1, .3251
a4 alpass asour, 1, .2826
kpvari randi .05, 25, 0.777 ; high part
asour adsyn iamp/ampdb(70), cpsoct(ioct +1 + kpvari)/219.5, 1,
"Light stab.adsyn"
a5 alpass asour, 1, .2837
a6 alpass asour, 1, .2049
kfpenv line 1, .3, 0
kaenv linseg 0, .020, .75, .040, 1, .11, .20, .08, 0
anoise randi iamp * kaenv, 90 + cpsoct(kfpenv * -12), 0.333
; precussive part
a7 butterlp anoise, kfpenv * 17500 + 500
out a1 + a2 + a3 + a4 + a5 + a6 + a7
causes an error message, it seems that every adsyn ugen for every note in
the score is reading the "String.adsyn" file in again, that's 3 times for
each note, causing an out of memory problem very quickly. What am I doing
wrong.
Nathan Day
nathand@senet.com.au
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa02489;
17 Feb 97 15:31 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ac27122;
17 Feb 97 15:34 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Mon, 17 Feb 1997 15:33:51 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (PAA07294);
Mon, 17 Feb 1997 15:24:33 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Mon, 17 Feb 97 15:24:18 GMT
Received: from root@gateway.senet.com.au [203.11.90.1] by hermes
via ESMTP (PAA07230); Mon, 17 Feb 1997 15:24:04 GMT
Received: from ds05-f7.senet.com.au (ds05-F7.senet.com.au [203.26.217.196])
by gateway.senet.com.au (8.7.3/8.6.9) with SMTP id BAA29418;
Tue, 18 Feb 1997 01:53:43 +1030
Date: 18 Feb 97 01:36:40 +1030
Subject: Re: Csound build
From: Nathan Day
To: Csound list , John Fitch ,
Michael Gogins
X-Mailer: Cyberdog/1.2
Message-Id:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Is there any point in going to double precision floats, single precision
floats have a dynamic range of over 910 dB and a signal to error ratio of a
least 138 dB below the peak signal level, the threshold of pain is 132dB
above the threshold of hearing. Though most processor now can handle these
size numbers themselves quiet well, my PowerPC processor has now problem
with them, double precision requires twice the memory as single precision
which means our caches fill up quicker causing more cache misses and
therefore slowing down of calculations. I am very interested to know if
there is any signifcant errors, or any, in the 16 most signifcant bits in
numerous single precision calculation, as in DSP, as I plan to do a thesis
on it for my Audio Engineering class, perhaps it has some effect through
filter co-effectiants.
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa04401;
17 Feb 97 16:48 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa28930;
17 Feb 97 16:51 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Mon, 17 Feb 1997 16:50:43 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (QAA17533);
Mon, 17 Feb 1997 16:42:55 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Mon, 17 Feb 97 16:42:40 GMT
Received: from sndart.cemi.unt.edu [129.120.63.1] by hermes
via SMTP (QAA17472); Mon, 17 Feb 1997 16:42:18 GMT
Received: by sndart.cemi.unt.edu (NX5.67e/NX3.0M) id AA12232;
Mon, 17 Feb 97 10:35:39 -0600
Message-Id: <9702171635.AA12232@sndart.cemi.unt.edu>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
Original-Received: by NeXT.Mailer (1.118.2)
PP-warning: Illegal Received field on preceding line
From: Jon Christopher Nelson
Date: Mon, 17 Feb 97 10:35:37 -0600
To: csound@maths.ex.ac.uk
Subject: large score files
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Does anyone happen to know offhand what the score file size limit
hapens to be and where this limit resides in the Csound code. I
have been able to perf 12.5 MB score files (over 400,000 lines of
code) but could not perf a 25 MB score file even though I had enough
RAM to handle it.
By the way, the large score files were generated with my GrainMaker
MAX patch---designed for granulating soundfiles. A new and
improved version of this patch will be on the net in a couple of
weeks and will also be on the forthcoming Csound CD-ROM.
regards,
Jon Nelson
Jon Christopher Nelson, Director
CEMI (Center for Experimental Music and Intermedia)
University of North Texas College of Music
P.O. Box 13887
Denton, TX 76203
USA
ph. (817) 565-4926
fax (817) 565-2002
jnelson@sndart.cemi.unt.edu
http://www.music.unt.edu/comp/jnelson.htm
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa04430;
17 Feb 97 16:55 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa29075;
17 Feb 97 16:58 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Mon, 17 Feb 1997 16:58:21 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (QAA18826);
Mon, 17 Feb 1997 16:53:04 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Mon, 17 Feb 97 16:52:48 GMT
Received: from UX3.SP.CS.CMU.EDU [128.2.198.103] by hermes via SMTP (QAA18772);
Mon, 17 Feb 1997 16:52:43 GMT
Message-Id: <199702171652.QAA18772@hermes>
Subject: Re: Csound build
To: Csound mailing list
Date: Mon, 17 Feb 1997 11:52:40 -0500 (EST)
From: Eli Brandt
In-Reply-To: from "Nathan Day" at Feb 18, 97 01:36:40 am
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 849
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Nathan Day wrote:
> Is there any point in going to double precision floats, single precision
> floats have a dynamic range of over 910 dB and a signal to error ratio of a
> least 138 dB below the peak signal level, the threshold of pain is 132dB
> above the threshold of hearing.
The size of the mantissa is the limiting factor -- remember the
pitch-stepping problem on large tables that was discussed recently.
Filters can have problems too if you're not careful.
I agree that it's not worth the memory-bandwidth hit to move to
doubles throughout. If you're having problems getting good 16-bit
output with floats, you're probably using a numerically unstable
algorithm... throwing precision at it may only postpone the problem.
Though it would be nice to be able to specify doubles for particular
purposes.
--
Eli Brandt
eli+@cs.cmu.edu
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa04672;
17 Feb 97 17:32 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa29765;
17 Feb 97 17:36 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Mon, 17 Feb 1997 17:35:13 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (RAA22602);
Mon, 17 Feb 1997 17:24:32 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Mon, 17 Feb 97 17:24:19 GMT
Received: from mule0.mindspring.com [204.180.128.166] by hermes
via ESMTP (RAA22578); Mon, 17 Feb 1997 17:24:17 GMT
Received: from gogins (ip184.an9-new-york4.ny.pub-ip.psi.net [38.26.20.184])
by mule0.mindspring.com (8.8.4/8.8.4) with ESMTP id MAA83878
for ; Mon, 17 Feb 1997 12:24:16 -0500
Message-Id: <199702171724.MAA83878@mule0.mindspring.com>
From: Michael Gogins
To: Csound list
Subject: Re: Csound build
Date: Mon, 17 Feb 1997 12:29:06 -0500
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
The point about using doubles rather than floats is not the absolute
precision of the type, but rather the roundoff errors that accumulate in
repeated multiplications and other operations. There is solid knowledge
about this kind of thing in the field of numerical analysis. However, my
comments are inspired not by this knowledge, which I have not methodically
applied to the question, but rather by experience. I coded matrix inversion
with both floats and doubles and saw not only that doubles were indeed much
more precise, which I expected, but that floats were not nearly as precise
as I expected.
In the case of Csound, the only truly relevant test of the matter is blind
audition with a really good sound system. However, in the not too distant
future I will return to my matrix inversion code and post the actual
numbers to the list.
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa04960;
17 Feb 97 18:30 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ab00498;
17 Feb 97 18:34 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Mon, 17 Feb 1997 18:34:13 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (SAA28592);
Mon, 17 Feb 1997 18:27:08 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Mon, 17 Feb 97 18:26:51 GMT
Received: from GS160.SP.CS.CMU.EDU [128.2.203.172] by hermes
via SMTP (SAA28577); Mon, 17 Feb 1997 18:26:50 GMT
Message-Id: <199702171826.SAA28577@hermes>
Subject: Re: Csound build
To: Csound mailing list
Date: Mon, 17 Feb 1997 13:26:29 -0500 (EST)
From: Eli Brandt
In-Reply-To: <199702171724.MAA83878@mule0.mindspring.com> from "Michael Gogins" at Feb 17, 97 12:29:06 pm
X-Portmanteau: pantryptaminergeticallysisterrainbowtie
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 665
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Michael Gogins wrote:
> In the case of Csound, the only truly relevant test of the matter is blind
> audition with a really good sound system. However, in the not too distant
> future I will return to my matrix inversion code and post the actual
> numbers to the list.
I agree that it would be useful to see some numbers. But remember that
matrix inversion is a notorious example of an unstable operation --
useful for demonstrating roundoff error, but there's rarely a good
reason to invert a matrix in real numerical code. If it fails with
4-byte reals and works with 8-byte, double the matrix size and it'll
fail again.
--
Eli Brandt
eli+@cs.cmu.edu
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05053;
17 Feb 97 18:51 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ab00978;
17 Feb 97 18:55 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Mon, 17 Feb 1997 18:54:58 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (SAA00367);
Mon, 17 Feb 1997 18:50:14 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Mon, 17 Feb 97 18:50:02 GMT
Received: from root@main.gv.net [205.162.164.2] by hermes via ESMTP (SAA00328);
Mon, 17 Feb 1997 18:50:00 GMT
Received: from gv.net.gv.net (ppp4.gv.net [205.162.164.53])
by main.gv.net (8.7.4/8.6.9) with ESMTP id LAA29477
for ; Mon, 17 Feb 1997 11:42:36 -0800 (PST)
Message-Id: <199702171942.LAA29477@main.gv.net>
From: Ken Locarnini
To: CSound Mailing List
Subject: CD Rom
Date: Mon, 17 Feb 1997 10:51:24 -0800
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Can anyone tell me what the content of the CSound CD rom will be? A
collection of all things CSound thus far??
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05552;
17 Feb 97 21:14 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ab01750;
17 Feb 97 21:18 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Mon, 17 Feb 1997 21:17:40 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (VAA08128);
Mon, 17 Feb 1997 21:06:02 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Mon, 17 Feb 97 21:05:52 GMT
Received: from pragmatix.bangor.ac.uk [147.143.2.14] by hermes
via ESMTP (VAA08096); Mon, 17 Feb 1997 21:05:51 GMT
Received: from thunder
by pragmatix.bangor.ac.uk (SMI-8.6/SMI-SVR4) id VAA23880;
Mon, 17 Feb 1997 21:05:55 GMT
Received: by thunder; (5.65/1.1.8.2/17Oct94-1141AM) id AA22020;
Mon, 17 Feb 1997 21:05:55 GMT
Date: Mon, 17 Feb 1997 21:05:54 +0000 (GMT)
From: Martin Dupras
X-Sender: mup015@thunder
To: Csound mailing list
Subject: Floats vs. doubles
In-Reply-To: <199702171826.SAA28577@hermes>
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
It may be naive, but why couldn't the option of using doubles internally
instead of floats not be available as a command-line option? It seems to
me that about half of the time we really really really care about
performance and speed, and about half of the time we care about really
really really precise calculations. =)
At the very least, it should be possible to implement this as a flag in
the makefile? Then, if someone really need the precision, they could
recompile the code with doubles thorughout.
Then again, if it was really that simple, it would most certainly have
been implemented already.
So, what am I missing?
- martin
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05937;
17 Feb 97 23:29 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ab02305;
17 Feb 97 23:33 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Mon, 17 Feb 1997 23:33:19 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (XAA15093);
Mon, 17 Feb 1997 23:30:17 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Mon, 17 Feb 97 23:30:06 GMT
Received: from ella.mills.edu [144.91.3.20] by hermes via ESMTP (XAA15055);
Mon, 17 Feb 1997 23:29:58 GMT
Received: from localhost by ella.mills.edu
via SMTP (940816.SGI.8.6.9/930416.SGI) for
id PAA10182; Mon, 17 Feb 1997 15:29:59 -0800
Date: Mon, 17 Feb 1997 15:29:59 -0800 (PST)
From: Mike Berry
To: csound list
Subject: float vs. double speed
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
I ran a little test to get some speed numbers. And the floats
won; about 2 - 2.5 % faster.
The test was writing 10000 buffers full of sound using an
interpolating oscillator. This is on a Mac 7500 PPC at 100Mhz without a
cache. I admit suprise because I had been told that doubles were faster,
but I guess not.
Mike Berry
mikeb@mills.edu
http://www.mills.edu/PEOPLE/gr.pages/mikeb.public.html/mikeb.homepage.html
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06035;
18 Feb 97 0:14 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa02564;
18 Feb 97 0:18 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Tue, 18 Feb 1997 00:18:22 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (AAA17038);
Tue, 18 Feb 1997 00:13:30 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Tue, 18 Feb 97 00:13:20 GMT
Received: from ulysses.Stanford.EDU [36.49.0.124] by hermes
via ESMTP (AAA17024); Tue, 18 Feb 1997 00:13:14 GMT
Received: (from tkunze@localhost)
by ulysses.stanford.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF)
id QAA23901; Mon, 17 Feb 1997 16:13:13 -0800
From: Tobias Kunze
Message-Id: <9702171613.ZM23900@ulysses.stanford.edu>
Date: Mon, 17 Feb 1997 16:13:12 -0800
In-Reply-To: Mike Berry "float vs. double speed" (Feb 17, 3:29pm)
References:
Reply-To: t@ulysses.stanford.edu
X-Url: http://www.stanford.edu/~tkunze
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Mike Berry
Subject: Re: float vs. double speed
Cc: csound@maths.ex.ac.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
| I ran a little test to get some speed numbers. And
| the floats won; about 2 - 2.5 % faster.
|
| The test was writing 10000 buffers full of sound
| using an interpolating oscillator. This is on a
| Mac 7500 PPC at 100Mhz without a cache. I admit suprise
| because I had been told that doubles were faster, but I
| guess not.
>From what I remember when i was still programming the mac (thank
goodness that's over!! :) is that the m68k procs with fpu (either
an 6888x or an internal as in the case of the 68x40 processor were
way better at doubles than floats, since that was the FPU's native
format and cache issues were not as important at the speeds the
processors ran at. But, mind you, they used 12-byte "Extended"
doubles, that you were supposed to access through SANE routines!
Apple came up with a couple of weird formats: 12-byte doubles, 48-bit (!!)
color, ...
The PPC architecture is definitively a float processor, not double.
--
______________________________________________________________________
Tobias Kunze t@kunze.stanford.edu
CCRMA, Stanford University http://www.stanford.edu/~tkunze
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06198;
18 Feb 97 1:06 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ab03071;
18 Feb 97 1:10 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Tue, 18 Feb 1997 01:09:59 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (BAA19003);
Tue, 18 Feb 1997 01:06:16 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Tue, 18 Feb 97 01:06:03 GMT
Received: from root@westnet.com [206.24.6.2] by hermes via ESMTP (BAA18991);
Tue, 18 Feb 1997 01:06:02 GMT
Received: from port2.ts2.westnet.com (port2.ts2.westnet.com [206.28.203.2])
by westnet.com (8.8.5/8.7.3) with SMTP id UAA16819
for ; Mon, 17 Feb 1997 20:06:04 -0500 (EST)
Date: Mon, 17 Feb 1997 20:06:04 -0500 (EST)
Message-Id: <199702180106.UAA16819@westnet.com>
X-Sender: lt@westnet.com (Unverified)
X-Mailer: Windows Eudora Version 1.4.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: csound@maths.ex.ac.uk
From: Larry Troxler
Subject: Possible musmon()/kperf() simplification?
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Wouldn't it simplify the logic dramatically, to do the following?
1) only perf 1 k-period each time through the main loop
2) Take the checking for real-time events out of kperf(), and change kperf
to always perform just perf 1 k-period. Poof! It just got a lot smaller.
3) Change rdscor() to conditionally return an event, only if an event is to
be started at the current value of kcounter.
4) Move the real-time checks up in to musmon().
5) Make a common protocol for *all* sources of events (csound score, score,
ASCII input, real-time MIDI, etc). As an example of such an implementation,
each event source would supply a function that returns either NULL, or an
event, if an event is to be started at the current kcounter. This would make
musmon() a lot easier to understand!
I haven't considered event-offs yet, since I don't quite understand all the
spaghetti-code in musmon(). And maybe there's some other problems I'm not
considering. And, yes, this would result in a slight performance penalty.
Any comments?
Larry
-- Larry Troxler -- lt@westnet.com -- Patterson, NY USA --
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06223;
18 Feb 97 1:12 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa03118;
18 Feb 97 1:16 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Tue, 18 Feb 1997 01:16:18 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (BAA19321);
Tue, 18 Feb 1997 01:12:24 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Tue, 18 Feb 97 01:12:11 GMT
Received: from root@lix.intercom.es [194.179.21.2] by hermes
via ESMTP (BAA19303); Tue, 18 Feb 1997 01:12:05 GMT
Received: from [195.76.154.46] (iv46_mad.intercom.es [195.76.154.46])
by lix.intercom.es (8.7.3/8.6.12) with SMTP id CAA26407
for ; Tue, 18 Feb 1997 02:11:05 +0100
Message-Id:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Feb 1997 01:12:14 +0100
To: csound@maths.ex.ac.uk
From: Javier Ruiz
Subject: Re: Soft FPU?
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
> I've been reading about, and would like to get involved with
>Csound. But, before I expend the time and energy, can someone on the
>list tell me if Csound for the Mac will run on a 030 machine with a
>software FPU. I'll be moving to a PPC in June, but would like to get
>started now if it's possible.
Hi, John. The first two versions I got of Csound was one for 68030 with FPU
and one without FPU. It worked perfectly in my old PowerMac 6100/60 in
emulation mode.
So it should work in your 68030. Have something to read handy while you
wait though.
Best.
P.S. I dont know if that version is still available but I think so. Check
MIT ftp site.
Javier Ruiz
C/Las Americas, 4, bajo.
38205 Santa Cruz de Tenerife
CANARY ISLANDS-SPAIN
phone: 34 22 25 35 14
e-mail: javiruiz@lix.intercom.es
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06229;
18 Feb 97 1:14 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa03123;
18 Feb 97 1:18 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Tue, 18 Feb 1997 01:17:07 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (BAA19310);
Tue, 18 Feb 1997 01:12:18 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Tue, 18 Feb 97 01:12:07 GMT
Received: from kwanon.research.canon.com.au [203.12.172.254] by hermes
via ESMTP (BAA19301); Tue, 18 Feb 1997 01:12:03 GMT
Received: (from smap@localhost) by kwanon.research.canon.com.au (8.7.4/8.7.3)
id MAA22249 for ;
Tue, 18 Feb 1997 12:03:23 +1100 (EST)
Received: from mama.research.canon.com.au(203.12.174.131)
by kwanon.research.canon.com.au via smap (V1.3) id sma022244;
Tue Feb 18 12:03:06 1997
Received: (from smap@localhost) by mama.research.canon.com.au (8.7.4/8.7.3)
id LAA25189 for ;
Tue, 18 Feb 1997 11:58:58 +1100 (EST)
Received: from garner.research.canon.com.au(203.12.174.23)
by mama.research.canon.com.au via smap (V1.3) id sma025163;
Tue Feb 18 11:57:58 1997
Received: (from darrin@localhost)
by garner.research.canon.com.au (8.7.3/8.7.3) id LAA25964
for csound@noether.ex.ac.uk;
Tue, 18 Feb 1997 11:57:57 +1100 (GMT+1100)
Message-Id: <199702180057.LAA25964@garner.research.canon.com.au>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3J v130.3)
Original-Received: by NeXT.Mailer (1.130.3)
PP-warning: Illegal Received field on preceding line
From: Darrin Smart
Date: Tue, 18 Feb 97 11:57:43 +1100
To: csound@maths.ex.ac.uk
Subject: Re: float vs. double speed
References: <9702171613.ZM23900@ulysses.stanford.edu>
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Surely this is just a matter of #defining a type to use in the
csound source and people can build binaries either way. It seems
quite reasonable to me that some platforms will run better with
floats, and others with doubles, so why not let it be different on
different platforms?
- Darrin
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06536;
18 Feb 97 2:25 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa03552;
18 Feb 97 2:29 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Tue, 18 Feb 1997 02:29:07 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (CAA21290);
Tue, 18 Feb 1997 02:25:28 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Tue, 18 Feb 97 02:25:18 GMT
Received: from lynx-f.cbr.dit.csiro.au [192.107.9.19] by hermes
via ESMTP (CAA21287); Tue, 18 Feb 1997 02:25:15 GMT
Received: from capella.cbr.dit.csiro.au
by lynx.cbr.dit.csiro.au (8.8.3/1.07S) id NAA28773;
Tue, 18 Feb 1997 13:24:47 +1100 (EST)
From: Stephen Barrass
Received: by capella.cbr.dit.csiro.au (8.8.3/1.09C) id NAA21988;
Tue, 18 Feb 1997 13:24:46 +1100 (EST)
Date: Tue, 18 Feb 1997 13:24:46 +1100 (EST)
Message-Id: <199702180224.NAA21988@capella.cbr.dit.csiro.au>
To: csound@maths.ex.ac.uk
Subject: Re: float vs. double speed
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
> Surely this is just a matter of #defining a type to use in the
> csound source and people can build binaries either way. It seems
> quite reasonable to me that some platforms will run better with
> floats, and others with doubles, so why not let it be different on
> different platforms?
the sun platform automatically converts floats to doubles
i guess oher platforms that are optimised for doubles would do the same
and you have the option to force single precision with a compile flag -fsingle
more generally gnu cc has a similar flag
gcc has -fshort-double,
-fshort-double
Use the same size for double as for float
stephen
stephen.barrass@cmis.csiro.au @ * ~
ftp://ftp.cbr.dit.csiro.au/staff/stephen/stephen.html whiz pop splash
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07423;
18 Feb 97 7:38 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa04710;
18 Feb 97 7:42 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Tue, 18 Feb 1997 07:42:27 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (HAA28925);
Tue, 18 Feb 1997 07:39:28 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Tue, 18 Feb 97 07:39:15 GMT
Received: from remote12.condenast.com [204.252.201.23] by hermes
via ESMTP (HAA28916); Tue, 18 Feb 1997 07:39:13 GMT
Received: (from noel@localhost) by ns25mHz.escape.com (8.7.5/8.7.3)
id CAA00568 for Csound Discussion List ;
Tue, 18 Feb 1997 02:44:05 -0500 (EST)
Message-Id: <199702180744.CAA00568@ns25mHz.escape.com>
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-Nextstep-Mailer: Mail 3.3 (Enhance 1.2)
Original-Received: by NeXT.Mailer (1.118.2)
PP-warning: Illegal Received field on preceding line
From: Noel Bush
Date: Tue, 18 Feb 97 02:44:03 -0500
To: Csound Discussion List
Subject: nice (slightly broken) new Cscore
Reply-To: Noel Bush
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
I am curious about what has happened to the Cscore in versions 3.44 and =
3.45. When I tried to compile a program that'd been working fine with =
previous versions, I got complaints about missing symbols. Sure enough, =
it looks like cscormai.c and cscorfns.c were missing a couple of items =
(dribble_printf(), err_printf(), and lcount()) that had to be grabbed =
from main.c and an earlier (v3.??) cscore.c . The newly created =
cscore.a works fine. I also had to change my program's sources to say =
"EVLIST" and "EVENT" instead of their non-capitalized predecessors.
The new and improved typedefs are really cool, as is everything about =
the newfangled cscore. It looks like someone has some happy ideas in =
the works. But I find no documentation of what's been happening with =
this in the Csound ChangeLog.
Nice stuff: whodunnit?
=3D=3D=3D=3D Noel Bush (NeXTmail, MIME A-OK!)
=3D=3D=3D=3D Brooklyn NY 11211
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6
mQB7AzLqfeYAAAEDbAvMahIJuSomidSjNvGTPaqnoyS3jtB36y8eyrLJ6L3egd6e
Zem4VY0bBf3zbkouXVzfMxJvwx9l4tsuy60yi5jfc6+8EUtoFSKHty3M9sEawjpM
rF0QPGF6fnUcvWHpggWzJn6HKid2egMjlOIlAAURtB9Ob2VsIEJ1c2ggPG5vYnVt
YWtvQGVzY2FwZS5jb20+
=3DjDQE
-----END PGP PUBLIC KEY BLOCK-----=
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07434;
18 Feb 97 7:39 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa04718;
18 Feb 97 7:43 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Tue, 18 Feb 1997 07:42:49 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (HAA28934);
Tue, 18 Feb 1997 07:39:35 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Tue, 18 Feb 97 07:39:20 GMT
Received: from remote12.condenast.com [204.252.201.23] by hermes
via ESMTP (HAA28922); Tue, 18 Feb 1997 07:39:18 GMT
Received: (from noel@localhost) by ns25mHz.escape.com (8.7.5/8.7.3)
id CAA00571 for Csound Discussion List ;
Tue, 18 Feb 1997 02:44:17 -0500 (EST)
Message-Id: <199702180744.CAA00571@ns25mHz.escape.com>
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-Nextstep-Mailer: Mail 3.3 (Enhance 1.2)
Original-Received: by NeXT.Mailer (1.118.2)
PP-warning: Illegal Received field on preceding line
From: Noel Bush
Date: Tue, 18 Feb 97 02:44:16 -0500
To: Csound Discussion List
Subject: midi support for NeXT
Reply-To: Noel Bush
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
I do not have the midi headers sought by midirecv.c, and have thus =
never been able to have a compilable Csound without excising the midi =
support. NS 3.2 only gives me:
/usr/include/mididriver --
-r--r--r-- 1 root wheel 3906 Sep 13 1991 midi_spec.h
-r--r--r-- 1 root wheel 4970 Nov 14 1991 midi_driver.h
What I seem to need are six files called:
midi_server.h
midi_reply_handler.h
midi_timer.h
midi_timer_reply_handler.h
midi_error.h
midi_timer_error.h
...presumably to be found in /usr/include/midi.
I don't have these on any of the NS CD-ROMs for 3.0, 3.1 or 3.2, nor =
can I find them at NeXTAnswers or on my friendly neighborhood Peanuts =
mirror. The CCRMA ftp server does not have MusicKit releases prior to =
4.0. Could someone NeXTmail these to me, or better yet post them on the =
bath site in the new NeXT directory?
Tanks,
=3D=3D=3D=3D Noel Bush (NeXTmail, MIME A-OK!)
=3D=3D=3D=3D Brooklyn NY 11211
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6
mQB7AzLqfeYAAAEDbAvMahIJuSomidSjNvGTPaqnoyS3jtB36y8eyrLJ6L3egd6e
Zem4VY0bBf3zbkouXVzfMxJvwx9l4tsuy60yi5jfc6+8EUtoFSKHty3M9sEawjpM
rF0QPGF6fnUcvWHpggWzJn6HKid2egMjlOIlAAURtB9Ob2VsIEJ1c2ggPG5vYnVt
YWtvQGVzY2FwZS5jb20+
=3DjDQE
-----END PGP PUBLIC KEY BLOCK-----=
Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07525;
18 Feb 97 8:20 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa04849;
18 Feb 97 8:24 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
Tue, 18 Feb 1997 08:24:15 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (IAA00409);
Tue, 18 Feb 1997 08:22:02 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
Tue, 18 Feb 97 08:21:52 GMT
Received: from filoli.com [204.162.0.10] by hermes via ESMTP (IAA00395);
Tue, 18 Feb 1997 08:21:50 GMT
Received: from sunspot.filoli.com (root@sunspot.filoli.com [204.162.1.17])
by filoli.filoli.com (8.6.10/8.6.9) with ESMTP id AAA15392;
Tue, 18 Feb 1997 00:21:21 -0800
Received: from pine.filoli.com (pine.filoli.com [204.162.1.216])
by sunspot.filoli.com (8.6.12/8.6.9) with SMTP id AAA25150;
Tue, 18 Feb 1997 00:21:20 -0800
From: Charles Baker
Message-Id: <199702180821.AAA25150@sunspot.filoli.com>
Received: by pine.filoli.com (NX5.67f2/NX3.0X) id AA08367;
Tue, 18 Feb 97 00:21:20 -0800
Date: Tue, 18 Feb 97 00:21:20 -0800
To: csound@maths.ex.ac.uk, nobumako@escape.com
Subject: midi support for NeXT
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
These files are from pre-release 4.0 music-kit. The later MusicKit
has a re-written midi driver that supports NexTStep Intel. If you
want to compile Csound for Intel, and have midi work at all, you'll
have to re-write the midi routines in csound to match the new new driver.
Or wait for my next vacation period: this is my next project (ok, pun
intended!). If you wish to have the new csound for NeXT hardware ("black"
hardware), just go get the version I compiled from the bath site.
There is also a not-so-old (3.41?) version that was compiled "fat" for
NeXT/Intel, from Stephen Beck...he used the old driver library, soo...
I bet he has a copy of that driver compiled fat also, so he might be
who you wanna talk to about this. BUT.... I doubt that the midi driver
works on IntelNeXT boxes. I would love to be told I am wrong. Did you
try out the midi stuff on IntelNeXT, Stephen? (only 2 or 3 cards
are supported, I think...). The move to the new driver (which is supposed
to work on both platforms) does not look too difficult, since we have
code for both drivers available....uh...I mean, someone does: I have the old
header files you ask about, but not the orig. driver code. I also have
the orig. midi driver libmidi.a, and can compile all the NeXT (black) hardware
versions you can stand. But if you want that: just go get it from
the bath site. If you want functional MIDI on a IntelNeXT box, then you will
just have to do the re-write of the csound NeXT midi stuff, OR wait till
someone else does it. (I'll give it a go soon...first tho, I've gotta
5 billion$ corporation breathing down my neck to deliver them their data.
For some reason, they think this insurance c**p is more important than
the csound community! Imagine!)
Well, 'nuff excuses on my part...good luck, if you wish to try it.
Oh, yeah, StephenBeck teaches (lucky sot) at LSU: I think his address
is/was sbeck@math.lsu.edu.
CharlieB
baker@charlieb.com
http://www.charlieb.com
|