[PD] double precision + benchmarking

Sukandar Kartadinata sk at glui.de
Tue Apr 2 04:00:38 CEST 2002


>  > oh, and the 32bit integer version of phasor~ sounds quite alright.
>>  Thanks for the suggestion. (Couldn't find it in CSound though)
>
>Where do you have it from ?

oh, just did some quick (dirty) coding myself
not much to do for a phasor than some simple accumulating
and only slightly more difficult for the other oscillators
(and a good excercise in dsp, after all that system design in the past years)


>Regarding the timer and stuff, I have a fixed point pd version for the
>iPaq, which is  halfway done, I would be happy if we could
>team up.

I'd be happy to exchange ideas where possible !
However, I think our general goals are slightly different as I try to 
stay as close to the original distribution as possible, while I 
assume that you have spawned off quite far with your pure integer 
implementation, no?
So I guess we couldn't even exchange oscillators.
(could send you the code though if you're interested)

But for the timers I'd be curious how you handled this. Do you reduce 
the timing precision with a single 32bit int ? Or use two of them ? 
But then this would require much more changes to the code (operator 
overloading would come handy here...). Maybe not a problem for you if 
you're rewriting most of the code anyway.
Anyway I decided to stick with double for now as it's working OK and 
there are more important issues to solve. Maybe I'll try something 
with a forced fixed point representation (like the original phasor~ 
code), so I can keep double for the calling files, and restrict the 
code changes (some simplified double arithmetic) to m_sched.c and 
s_unix.c

Q: would it be possible to define timing variables/functions with 
something like t_systime instead of double ? That would make certain 
things easier...
(also, I'm kinda confused about the mixed use of float and t_float - 
is there a scheme behind this ? And while I'm at it: why is printing 
and error reporting encapsulated in s_print.c but still many fprintf 
commands etc. in other files ? (if this just needs some spring 
cleaning I'd volunteer....:))

best,
Sukandar
-- 

__--__--__-___-_--_-_-___-_-_--___-_-___
sukandar kartadinata
   the glui performance hardware
     http://www.glui.de/proj/gluiph.html
_--__---_--_--___---_-_-_--_-__-



More information about the Pd-list mailing list