Subject: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 4, Issue 61
From: rd_AT_alphalink.com.au
Date: Tue Jan 27 2004 - 17:18:58 EET
> > 440.0 is still an exact integer
> Hunh? What Scheme is this? The Scheme spec says
> "It [a numerical constant] is inexact if it contains a decimal point..."
Yes, my mistake, I meant to say that 440.0 is still an integer.
Welcome to MzScheme version 205.8, Copyright (c) 1995-2003 PLT
> (integer? 440.0)
#t
> It also says "inexactness is a contagious property of a number".
Welcome to MzScheme version 205.8, Copyright (c) 1995-2003 PLT
> (exact? (* 0 440.0))
#t
This is explicitly mentioned in R5RS, and exact zeroes turn up all the
time in controller input streams, from midi controllers for example.
> In any case, type checks are trivial.
Well yes, it is the the type check that determines the OSC encoding, but
without explicit type tagging there is no way of knowing if 1.0 should be
encoded as a single or double precision value? Or in fact if it is a
'proper' integer that has been contaminated somewhere along its
journey?
My actual argument regards all this is that OSC is a good thing to have
in user space, and that in user space 440 should be a valid frequency
input, and 1.0 a valid index input. I think it is an amazing contribution of
SuperCollider that composers find the language and the environment
approachable. The 'scsynth' OSC implementation is part of this
contribution, we should live up to it's example.
Regards,
Rohan
An aside: I bought up scheme as a counterexample to Lua to show that
just because a language has a lot of numerical types does not help with
getting OSC encoding `correct'.
(integer? 1.0) => #t
(integer? 1) => #t
(exact? 1.0) => #f
(exact? 1) => #t
(= 1 1.0) => #t
(eq? 1 1) => #t
(eq? 1.0 1.0) => #f
(eq? 1 1.0) => #f
These questions are interesting, and of course not peculiar to lisps, but
implementors should bend over backwards trying to make sure that
composers don't *need* to ponder the mysteries of inexact integers to
tune an instrument.
This archive was generated by hypermail 2b28 : Tue Jan 27 2004 - 17:24:51 EET