On Mon, 21 Dec 2020 at 11:55, Stéphane Letz <l...@grame.fr> wrote:
> Very interesting discussion ! (even if I do now follow all the details for
> now):
>
> - about the « singleprecision/doubleprecision/quadprecision » recent
> addition in the language, and about the use of ma.EPSILON (that is indeed
> defined using singleprecision/doubleprecision/quadprecision model). The
> thing is that Faust wants to be a high-level specification language, where
> the user should in theory not to have to think at all on these « details ».
> But the thing is that computer numbers are not mathematical numbers, and we
> obviously hit those « real-life » number precision issues quite rapidly.
> This can also be a question in the compiler itself, when we decide to
> regroup or reorganise some computations, possibly changing the precision.
> Not an easy problem at all !
> But the addition of « singleprecision/doubleprecision/quadprecision » and
> use of ma.EPSILON or similar concepts at the required places in the
> libraries, seems at least a way to put a bit of coherency where we have
> to. So people, fell free to propose PR if ma.EPSILON has to be used at
> more places !
>
Following this idea, would it be good to have guards in tables and delays
to avoid seg_fault 11 when indexes are weird values such as NAN? INF
doesn't seem to be a problem for delay values in delay lines. For example:
import("stdfaust.lib");
process = de.fdelay(16, del, no.noise), safefdel(16, del, no.noise), del
with {
del = log(no.noise);
};
safefdel(s, d, x) = de.fdelay(s, delay, x)
with {
delay = ba.if(ma.isnan(d), _, d) ~ _;
};
channel 1, channel 2, channel 3
5.7485885944909363e-06, 5.7485885944909363e-06, -12.066556195113364
nan, -0.34484595169538912, nan
nan, -0.6951856770064615, nan
nan, -0.3250393664115292, nan
0.10676848381141596, 0.10676848381141596, -2.2370924914039843
nan, -0.48342555318187247, nan
0.2113922806105179, 0.21139228061051793, -0.71403105730027505
nan, -0.14381783171867368, nan
nan, -0.56355247609807113, nan
0.25666705810309715, 0.25666705810309715, -1.3599755277266783
I'm not suggesting to change the delay lines implementations but to add new
ones. Perhaps also adding nan-safe math could be good.
> - « As far as I'm concerned, Faust should be double precision by default.
> :-) from Dario » I know that, I guess you should even write « Faust
> should be double precision running at 96kHz by default ((-; ». Well AFAICS
> floats are sufficient for most of standard cases to stay the default, and
> Dario especially for you (…), I’m working on adding double support in the
> WebAssembly layer to be able to have a « float/double » choice at some
> point in the faust Web IDE.
>
> - I’m not moderating the mailingn-list at all ((-;
>
> Stéphane
>
I secretly love you Stéphane! Thank you so much. :-D
Ciao,
Dario
>
>
> > Le 20 déc. 2020 à 22:55, Julius Smith <julius.sm...@gmail.com> a écrit :
> >
> > Thanks for the detective work!
> >
> > I like the idea of setting the pole protection margin according to the
> working precision.
> > The boldest choice would be 1.0 - machineEpsilon.
> >
> > I think it was Stéphane who gave us ma.EPSILON to use in this kind of
> situation (it arose fairly recently for fi.tau2pole's divide-by-zero check).
> >
> > In filters.lib, I just now changed (in faustlibraries / master)
> > smax = 0.9999;
> > to
> > smax = 1.0-ma.EPSILON;
> >
> > and now it behaves more on par with the others:
> >
> > > faust2plot tfilterforms2.dsp ; tfilterforms2 -n 100000 | tail -16
> > tfilterforms2;
> > 0.00228387304 0.000913831813 0.00317438412; ...
> > 0.00228387304 0.000913831813 0.00317438412; ...
> > 0.00228387304 0.000913831813 0.00317438412; ...
> > 0.00228387304 0.000913831813 0.00317438412; ...
> > 0.00228387304 0.000913831813 0.00317438412; ...
> > 0.00228387304 0.000913831813 0.00317438412; ...
> > 0.00228387304 0.000913831813 0.00317438412; ...
> > 0.00228387304 0.000913831813 0.00317438412; ...
> > ...
> >
> > > faust2plot -double tfilterforms2.dsp ; tfilterforms2 -n 100000 | tail
> -16
> > tfilterforms2;
> > 5.1756238184097469e-12 3.7870455898468107e-12 8.7758306858103949e-12;
> ...
> > 5.1756238184097469e-12 3.7870455898468107e-12 8.7758306858103949e-12;
> ...
> > 5.1756238184097469e-12 3.7870455898468107e-12 8.7758306858103949e-12;
> ...
> > 5.1756238184097469e-12 3.7870455898468107e-12 8.7758306858103949e-12;
> ...
> > 5.1756238184097469e-12 3.7870455898468107e-12 8.7758306858103949e-12;
> ...
> > 5.1756238184097469e-12 3.7870455898468107e-12 8.7758306858103949e-12;
> ...
> > 5.1756238184097469e-12 3.7870455898468107e-12 8.7758306858103949e-12;
> ...
> > 5.1756238184097469e-12 3.7870455898468107e-12 8.7758306858103949e-12;
> ...
> > ...
> >
> > > faust2plot -quad tfilterforms2.dsp ; tfilterforms2 -n 100000 | tail -16
> > tfilterforms2;
> > 3.71743109e-15 1.88456022e-15 5.46351836e-15; ...
> > 3.71743109e-15 1.88456022e-15 5.46351836e-15; ...
> > 3.71743109e-15 1.88456022e-15 5.46351836e-15; ...
> > 3.71743109e-15 1.88456022e-15 5.46351836e-15; ...
> > 3.71743109e-15 1.88456022e-15 5.46351836e-15; ...
> > 3.71743109e-15 1.88456022e-15 5.46351836e-15; ...
> > 3.71743109e-15 1.88456022e-15 5.46351836e-15; ...
> > 3.71743109e-15 1.88456022e-15 5.46351836e-15; ...
> > ...
> >
> > The question remains as to which filter form is more accurate.
> >
> > Another thing worth mentioning, by the way, is that tf2snp can be
> modulated, even using white noise for its coefficients, without affecting
> signal energy.
> > That's the usual and original principal benefit of going to the
> normalized ladder form - "power-invariant modulatability".
> > The superior numerical robustness for closely spaced poles was observed
> later and documented in the literature by Gray and Markel, as I recall.
> >
> > - Julius
> >
> >
> > On Sun, Dec 20, 2020 at 12:07 PM Oleg Nesterov <o...@redhat.com> wrote:
> > On 12/20, Dario Sanfilippo wrote:
> > >
> > > > --- a/filters.lib
> > > > +++ b/filters.lib
> > > > @@ -1004,7 +1004,7 @@ declare tf2np copyright "Copyright (C)
> 2003-2019 by
> > > > Julius O. Smith III <jos@ccr
> > > > declare tf2np license "MIT-style STK-4.3 license";
> > > > tf2np(b0,b1,b2,a1,a2) = allpassnnlt(M,sv) : sum(i,M+1,*(tghr(i)))
> > > > with {
> > > > - smax = 0.9999; // maximum reflection-coefficient magnitude allowed
> > > > + smax = 0.999999999; // maximum reflection-coefficient magnitude
> allowed
> > > > s2 = max(-smax, min(smax,a2)); // Project both
> reflection-coefficients
> > > > s1 = max(-smax, min(smax,a1/(1+a2))); // into the defined
> > > > stability-region.
> > > > sv = (s1,s2); // vector of sin(theta) reflection coefficients
> > > >
> > > >
> > > If I'm not wrong, anything above 0.9999999 would be rounded to 1 in
> single
> > > precision, right?
> >
> > Quite possibly, I didn't even bother to check.
> >
> > In case it was not clear, I didn't try to propose a fix, I just tried to
> > identify where does the problem come from.
> >
> > > Would it be possible to choose different constants based on different
> > > options given to the compiler?
> >
> > Yes, perhaps we should use singleprecision/doubleprecision I dunno.
> (Can't
> > resist I think this feature was a mistake but this is offtopic ;)
> >
> > Even if we forget about single precision, I simply do not know how much
> > we can enlarge this limit. The 0.999999999 value I used is just the
> "random
> > number closer to 1".
> >
> > > If not, a philosophical question (not really) for these situations
> might
> > > be: should we prioritise single precision or double precision
> > > performance/stability?
> >
> > Good question! please inform me when you know the answer? ;)
> >
> > Oleg.
> >
> >
> >
> > --
> > "Anybody who knows all about nothing knows everything" -- Leonard
> Susskind
> > _______________________________________________
> > Faudiostream-users mailing list
> > Faudiostream-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
>
> _______________________________________________
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
--
Dr Dario Sanfilippo
http://dariosanfilippo.com
_______________________________________________
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
