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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
