On Sun, 29 Oct 2023 at 19:25, Stéphane Letz <l...@grame.fr> wrote: > 1) https://faustdoc.grame.fr/manual/syntax/#numbers is quite clear AFAICS: > > ====== > Numbers > > Faust considers two types of numbers: integers and floats. Integers are > implemented as signed 32-bits integers, and floats are implemented either > with a simple, double, or extended precision depending of the compiler > options. Floats are available in decimal or scientific notation. > > Like any other Faust expression, numbers are signal processors. For > example the number 0.95 is a signal processor of type 𝕊0→𝕊1 that > transforms an empty tuple of signals () into a 1-tuple of signals (y) such > that ∀t∈ℕ,y(t)=0.95. > > Operations on integer numbers follow the standard C semantic for +, -, * > operations and can possibly overflow if the result cannot be represented as > a 32-bits integer. The / operation is treated separately and cast both of > its arguments to floats before doing the division, and thus the result > takes the float type. > ====== > > Should be add something more ? >
Perhaps we can include that "^" (pow()) can also be both int or float depending on the operands. > > 2) In a more long term : do we really need 64 bits integer ? Or forcing > compilation as real ( -single/double/quad) when needed is enough ? > >From a quick search, I read that doubles can represent ints correctly up to 2^53; an easy fix that I could think of is perhaps to do everything in double when using -double, and keeping ints when using single-precision. In that case; functions such as ba.time would also get an improvement. Dario > 3) We have to fix Dario just reported issue : > https://github.com/grame-cncm/faust/issues/962 > > Stéphane > > > Le 29 oct. 2023 à 19:09, Dario Sanfilippo <sanfilippo.da...@gmail.com> > a écrit : > > > > Hi, Oleg. > > > > On Sun, 29 Oct 2023 at 17:02, Oleg Nesterov <o...@redhat.com> wrote: > > On 10/29, Dario Sanfilippo wrote: > > > > > > internal int representation is always 32-bit, and Stéphane explained > that > > > it can't be changed easily. > > > > Yes, and this is a bit unfortunate > > > > > Since Faust is a high-level language for DSP, wouldn't it make sense to > > > treat all signals as float unless there's an explicit cast to int? > > > > I disagree. If nothing else this would be incompatible change. > > For example, even ba.time should be changed somehow to avoid > > the performance regression. > > > > Yes, that also doesn't sound right. > > > > > > I'd like to have another option which controls the "int" type, > > just like -single/double/quad do, but this is not simple. > > > > Until then, I suggest that we document these differences and behaviours > of ints and float signals well in the documentation. What I will personally > also do from now on when contributing, is to stress the use of float > signals by always using the point (.) in any operation, even those that are > always float regardless of the operands; for example: > > > > process = int / 2.0; > > > > Ciao, > > Dario > > > > > > Oleg. > > > > _______________________________________________ > > 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
