I get all of your points and I can see how using all floats with -double wouldn't work. Not much for these specific functions, which can be rewritten, but for the fact that there can be other code with int arithmetic and/or comparisons (I'm thinking of %, in particular) that may not work anymore.
Perhaps the problem isn't even there because it was just my mistake assuming that I could define a signal without explicitly making it float with a point (.) and expecting that it wouldn't overflow; the behaviour is documented. Though my feeling is that many users might have this assumption too, and that they do not always consciously work with fixed-point arithmetic, but I can be wrong. Is there any particular reason for not having division work like the other operators? Dr Dario Sanfilippo http://dariosanfilippo.com On Mon, 30 Oct 2023 at 08:53, Stéphane Letz <l...@grame.fr> wrote: > > > > Le 30 oct. 2023 à 02:39, Oleg Nesterov <o...@redhat.com> a écrit : > > > > On 10/30, Dario Sanfilippo wrote: > >> > >>>> In > >>>> that case; functions such as ba.time would also get an improvement. > >>> > >>> Why do you think so?? > >>> > >>> perhaps you meant that ba.time can overflow? Yes it can, but I don't > >>> think this should depend on -double. > > > > So what exactly did you mean? > > > >> From what I understand, a double can represent correctly a larger range > of > >> ints than an int32_t can, so if Faust assumed all signals to be float > when > >> using -double, we would avoid the issues above. > > > > but we will have other issues, > > > >> Other than it shouldn't be determined by the -double flag, do we agree > that > >> dealing with ints using double would be better than using int32_t? > > > > Sorry, no, I think this is a horrible idea :/ > > > > faust has types. Very limited set. You suggest to remove kInt. This looks > > strange to me, to say at least. > > > > Oleg. > > > > I agree with Oleg here: > > - Integers in Faust are 32-bits integer with all their « properties », > which are currently used in the library no.noise generator using the > wrapping behaviour (maybe not the best idea we had, but well…) > > - math operations on integers stay in the Integer domain in general. The / > (division) only promotes both arguments as float as does a float division. > > - some other primitive do « type promotion ». This has been better > documented here : https://faustdoc.grame.fr/manual/syntax, with something > like « automatically promoted to int » at several places > > - we can not afford to change the behaviour of integers in -double mode as > Dario suggested, since it would instantly break existing code in a « blind > » manner. > > - do we need an *explicit new option* to set the integer size (like > -int32, -in64 or better possibly -int N, with N = 32, 64, 128 one day ?), > so as a *user choice* ? But that 1) would break no.noise implementation, so > we would need to write alterable version… 2) this could blindly break > existing code…. > > Comments ? > > Stéphane > > >
_______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
