Re: [Faudiostream-users] Int signals compiling with -double
On 10/30, Dario Sanfilippo wrote: > > Is there any particular reason for not having division work like the other > operators? Well, I too think that faust lacks the "idiv" operator, int(/) doesn't generate the "good" code. But as you understand it is too late to change the current semantics of "/", process = 1/2; must output 0.5, not 0. Oleg. ___ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
Re: [Faudiostream-users] Int signals compiling with -double
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 wrote: > > > > Le 30 oct. 2023 à 02:39, Oleg Nesterov 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
Re: [Faudiostream-users] Int signals compiling with -double
> Le 30 oct. 2023 à 02:39, Oleg Nesterov 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
Re: [Faudiostream-users] Int signals compiling with -double
Dario, I don't understand you, so let me ask... On 10/30, Dario Sanfilippo wrote: > > Perhaps we can include that "^" (pow()) can also be both int or float > depending on the operands. but it already depends on the type of operands ? > perhaps to do everything in > double when using -double, and keeping ints when using single-precision. Please no ;) but I guess this is hardly possible so I'm calm. > 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. And why is "^" your only concern? Say, I = 2147483647; process = I, I+1, I*2; compiles to output0[i0] = FAUSTFLOAT(2147483647); output1[i0] = FAUSTFLOAT(-2147483648); output2[i0] = FAUSTFLOAT(-2); Oleg. ___ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
Re: [Faudiostream-users] Int signals compiling with -double
On Sun, 29 Oct 2023 at 19:25, Stéphane Letz 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 > a écrit : > > > > Hi, Oleg. > > > > On Sun, 29 Oct 2023 at 17:02, Oleg Nesterov 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
Re: [Faudiostream-users] Int signals compiling with -double
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 ? 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 ? 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 a > écrit : > > Hi, Oleg. > > On Sun, 29 Oct 2023 at 17:02, Oleg Nesterov 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
Re: [Faudiostream-users] Int signals compiling with -double
Hi, Oleg. On Sun, 29 Oct 2023 at 17:02, Oleg Nesterov 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
Re: [Faudiostream-users] Int signals compiling with -double
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. I'd like to have another option which controls the "int" type, just like -single/double/quad do, but this is not simple. Oleg. ___ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
[Faudiostream-users] Int signals compiling with -double
Hi, list.
There's a problem when using ints in double-precision; particularly, the
internal int representation is always 32-bit, and Stéphane explained that
it can't be changed easily.
So when compiling with -double,
process = _ * 2^32;
resolves to
virtual void compute(int count, FAUSTFLOAT** RESTRICT inputs, FAUSTFLOAT**
RESTRICT outputs) {
FAUSTFLOAT* input0 = inputs[0];
FAUSTFLOAT* output0 = outputs[0];
for (int i0 = 0; i0 < count; i0 = i0 + 1) {
output0[i0] = FAUSTFLOAT(0.0);
}
}
because the right operand overflows to 0, whereas
process = _ * 2.0^32;
gives the expected result
virtual void compute(int count, FAUSTFLOAT** RESTRICT inputs, FAUSTFLOAT**
RESTRICT outputs) {
FAUSTFLOAT* input0 = inputs[0];
FAUSTFLOAT* output0 = outputs[0];
for (int i0 = 0; i0 < count; i0 = i0 + 1) {
output0[i0] = FAUSTFLOAT(4294967296.0 * double(input0[i0]));
}
}
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?
Ciao,
Dr Dario Sanfilippo
http://dariosanfilippo.com
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
