Hi Julius, There are some irresistible things like that ;-) But that's a good idea: we could have an option!
Le mar. 11 sept. 2018 à 19:25, Julius Smith <j...@ccrma.stanford.edu> a écrit : > > We should not consider local non-causal computations (i. e. @(-1)) to be > incorrect > > There could be a compiler option for choosing between "local > non-causality" and "causal non-locality". > > Sorry - I couldn't resist :-) > > - Julius > > On Tue, Sep 11, 2018 at 8:56 AM Yann Orlarey <orla...@grame.fr> wrote: > >> Hi Oleg, >> >> I find all these arguments convincing. I have also discussed this issue >> with colleagues. We should not consider local non-causal computations (i. >> e. @(-1)) to be incorrect. >> We will modify the different steps to move in this direction: >> >> type_inference : cast : normalization : intervals >> >> >> Cheers >> >> Yann >> >> >> ------------------------- >> >> Yann Orlarey >> Directeur scientifique >> www.grame.fr >> >> >> >> >> Le lun. 10 sept. 2018 à 09:53, Oleg Nesterov <o...@redhat.com> a écrit : >> >>> On 09/09, yann orlarey wrote: >>> > >>> > Hi Oleg, >>> > >>> > `process = @(2) : @(-1);` is incorrect because `@(-1)` is incorrect. >>> >>> '@(-1)' is incorrect per se, but '@(2) : @(-1)' used to work and imo it >>> was >>> useful. Say, >>> >>> tkeoN(n) = @(n) <: ^(2) - @(0+n)*@(0-n); >>> >>> > The >>> > optimisations made by the compiler should not change the correctness >>> of the >>> > compiled program. >>> >>> Well, optimisations is very important part of faust ;) >>> >>> this code >>> >>> process = @(ba.time - ba.time); >>> >>> or this >>> >>> process = @(ba.time * 0); >>> >>> is correct. Now it can't be compiled too, by the same reason. >>> >>> Again, I do not pretend I understand faust internals, but it seems that >>> we >>> can simply remove the interval checks in infereSigType(); if interval is >>> not >>> valid or lo < 0 checkDelayInterval() should notice the problem later? >>> >>> > Therefore I think the current behavior of the compiler is >>> > the right one. >>> >>> I can't argue, but to me this looks as unfortunate pessimization. >>> >>> Oleg. >>> >>> _______________________________________________ >> Faudiostream-devel mailing list >> faudiostream-de...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/faudiostream-devel >> > > > -- > > Julius O. Smith III <j...@ccrma.stanford.edu> > Professor of Music and, by courtesy, Electrical Engineering > CCRMA, Stanford University > http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/> >
_______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
