A couple of things:

1. I'm pretty sure any error in cos at pi and 2pi will be smaller in double
precision than float's epsilon, so I don't think that there's any need to
set -1.0 and 1.0 explicitly after all except to be extra safe. However, at
pi/2 and 3pi/2 the error is still larger than the minimum normal number, so
it is worth setting the zero crossings to 0.0.

2. For garray_dofo() there isn't a great way of using explicit 0.0 at zero
crossings without incurring an extra check, like don't add to the sum if
absolute value is less than e.g. 1.0e-10. For this, probably just using
M_PI and incrementing integer phase like for the cosine table is enough.

MB


On Wed, Jun 5, 2024 at 2:20 PM Alexandre Torres Porres <[email protected]>
wrote:

> Em qua., 5 de jun. de 2024 às 14:31, Matt Barber <[email protected]>
> escreveu:
>
>> While we're at it, I think it would be worth tuning garray_dofo() to use
>> the same so that sinesum and cosinesum have the same level of accuracy,
>> guarantees of symmetry, etc.
>>
>> MB
>>
>
> Good catch! In fact, I think this is a great opportunity to also fix this
> bug https://github.com/pure-data/pure-data/issues/371 which is totally
> related. I just reopened https://github.com/pure-data/pure-data/issues/105
> as well as I'm still considering the table could/should be still "perfectly
> symmetric" considering 0 crossings and the start/end points.
>
>
>
>>
>> On Wed, Jun 5, 2024 at 12:52 PM Alexandre Torres Porres <[email protected]>
>> wrote:
>>
>>> For the record and sake of comparison, Cyclone uses a 16384 points
>>> table, and linear interpolation, calculated with double precision. We did
>>> this because MAX documents it uses such a table, and we made it (well, Matt
>>> did) simetric.
>>>
>>> I see Pd is doing kind of the same, huh? linear interpolation on a table
>>> calculated with double precision.
>>>
>>> I see SuperCollider mentions it uses 8192 points and linear
>>> interpolation on its oscillator.
>>>
>>> I guess MAX is exaggerating its table size a bit :) but I wonder why Pd
>>> is still about to use a relatively smaller table size. I'm curious to know
>>> how much an increase in table size actually offers a better resolution and
>>> how much it ruins performance. For instance, I'm using the same as Cyclone
>>> in ELSE oscillators, could I just reduce it at least to 8192 points or even
>>> less and down to Pd's 2048 size worry free?
>>>
>>> Thanks
>>>
>>>
>>>
>>> Em qua., 5 de jun. de 2024 às 13:28, Alexandre Torres Porres <
>>> [email protected]> escreveu:
>>>
>>>> Nice one Matt!
>>>>
>>>> Em qua., 5 de jun. de 2024 às 08:13, Christof Ressi <
>>>> [email protected]> escreveu:
>>>>
>>>>> @Miller: what do you think? IMO we should make the cos table as good
>>>>>> as we can, so we won't have any regrets :)
>>>>>>
>>>>> +1000!!!
>>>>
>>>
_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev

Reply via email to