[PD] double precision + benchmarking

[=?X-UNKNOWN?Q?g=FCnter_geiger?=]

On Tue, 2 Apr 2002, Sukandar Kartadinata wrote:

> >  > 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?

Yes, right, originally I wanted to stay close to the original,
but it prooved to be to much hassle to do so, at the end
the iPaq has other limitations too, not only floating point but
screen size, fonts etc. ...

> 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.

Well, I just replaced the time stuff int the scheduler loop and
sys_getrelatime()  to int.
So I left the clock_ functions the way they are, at least something
I have tio think about yet.

> 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

If I understood you right, your problem isn't floating point in general
but double precision ? The scheduler loop for the arm processor eats up
40 % of the CPU when using a double counter ...

>
> 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....:))

the float and t_float issues definitely need cleanup. but thats not all
there is t_sample (which is the sample type, defaults to float).
There is t_float, which is used for floating point messages more or less,
and there is t_floatarg, which is the type of floating point numbers
passed internally for pd functions.

What can be seen by this setup is that, once cleaned up, it should
theoretically be easy toswitch from float to double precision within
computations. (Well not for the "magic" oscillators implementation).

Finally, a timer type would help my efforts of beeing able to choose
between types for the timer..

Greetings,


Guenter