Hi,
I've found out that making a float grow and grow and grow it eventually reaches a value that is displayed in number boxes as "+Inf".
Then if I multiply that number by 0 I get a value that is displayed in a number box as "NaN".
Is this expected behaviour? If so i guess infinities and NaN have been recently introduced, haven't they?
However there seem to be some inconsistency: 5/4 returns 0 (as I was used to), not +inf. Also, I'm not sure +inf is the value you expect when adding something to the greatest representable value... or is it?
Also I cannot seem to find a way to write inf's or NaN as a literal (in a message box), and I cannot find an [isNaN] or similar object... that's why I wonder if this is a feature or a bug.
Also, sliders seem not to like them.
If you feed a NaN (or maybe +Inf, I'm not sure) to a slider, it makes the cursor disappear (which is probably OK for NaN), but then you suddenly get weird behaviour of the window: a scrollbar with a very small cursor appears as if the patch window had become suddenly huge and it may scroll away so you cannot see the patch content any more and you may not be able to scroll it.
It seems like it is actually trying to draw the slider's cursor far away, which doesn't happen with huge but finite numbers....
I'm trying to build a simple test patch, but I'm having difficulties. I can reproduce it with a patch that is pretty simple but doesn't quite isolate the "issue" (or non-issue) in a decent way. I'll post it if I cannot end up with anything better
Cheers m.
Here's a test patch.
Inf and NaN seem to be treated almost correctly (except NaN is displayed as "-nan"), but not all mathematical operation that should generate them actually do (indeed it seems you can only get Inf by overflow)
On 08/16/2010 07:59 PM, Matteo Sisti Sette wrote:
Hi,
I've found out that making a float grow and grow and grow it eventually reaches a value that is displayed in number boxes as "+Inf".
Then if I multiply that number by 0 I get a value that is displayed in a number box as "NaN".
Is this expected behaviour? If so i guess infinities and NaN have been recently introduced, haven't they?
However there seem to be some inconsistency: 5/4 returns 0 (as I was used to), not +inf. Also, I'm not sure +inf is the value you expect when adding something to the greatest representable value... or is it?
Also I cannot seem to find a way to write inf's or NaN as a literal (in a message box), and I cannot find an [isNaN] or similar object... that's why I wonder if this is a feature or a bug.
Also, sliders seem not to like them.
If you feed a NaN (or maybe +Inf, I'm not sure) to a slider, it makes the cursor disappear (which is probably OK for NaN), but then you suddenly get weird behaviour of the window: a scrollbar with a very small cursor appears as if the patch window had become suddenly huge and it may scroll away so you cannot see the patch content any more and you may not be able to scroll it.
It seems like it is actually trying to draw the slider's cursor far away, which doesn't happen with huge but finite numbers....
I'm trying to build a simple test patch, but I'm having difficulties. I can reproduce it with a patch that is pretty simple but doesn't quite isolate the "issue" (or non-issue) in a decent way. I'll post it if I cannot end up with anything better
Cheers m.
On 16/08/10 18:59, Matteo Sisti Sette wrote:
Is this expected behaviour?
Yes. IEEE floating point (used by most common CPUs, though GPUs might not support all features) is a bit warty.
If so i guess infinities and NaN have been recently introduced, haven't they?
No. But Pd tries to guard against them.
However there seem to be some inconsistency: 5/4 returns 0 (as I was used to), not +inf. Also, I'm not sure +inf is the value you expect when adding something to the greatest representable value... or is it?
Pd [/] guards against division by 0 by outputting 0 instead of +infinity, -infinity or NotANumber (depending on the sign of the left argument).
The reason why NaN and (to a lesser extent?) infinities are discouraged by non-scientific software is that it pollutes everything: any arithmetic operation you try to do with NaN gives you a NaN (or worse, an unexpected result: comparisons always give False so the three-way partition >x ==x <x doesn't hold). For scientific software NaN can be useful, to indicate that the algorithms aren't good enough or that the input was bad.
Also I cannot seem to find a way to write inf's or NaN as a literal (in a message box), and I cannot find an [isNaN] or similar object... that's why I wonder if this is a feature or a bug.
[expr isnan($f1)], perhaps? It creates, but I didn't manage to create a NaN to test yet (expr guards against division by zero too).
Also, sliders seem not to like them.
If you feed a NaN (or maybe +Inf, I'm not sure) to a slider, it makes
NaN compares 'False' for everything, my guess is that it checks for out of bounds (x > top || bottom > x) which gives false for NaN, so it assumes it's in the right range and passes a NaN to the graphics engine, which then goes beserk - more robust would be !(x < top && bottom < x) which should work even for NaN....
Claude
On Mon, 16 Aug 2010 19:44:52 +0100 Claude Heiland-Allen claudiusmaximus@goto10.org wrote:
Pd [/] guards against division by 0 by outputting 0 instead of +infinity, -infinity or NotANumber (depending on the sign of the left argument).
The reason why NaN and (to a lesser extent?) infinities are discouraged by non-scientific software is that it pollutes everything:
Yep, there's a few synthesis techniques like 1/1+cos(x^n) pulses and some DSF that rely on getting a 0 instead of an inf (otherwise you'd have to code ugly special cases around them and it would be quite unweildy to do in Pd).
Not sure to what extent it's still true but NaN used to royally screw up some versions of Jack and ALSA, requiring a complete restart of the audio stack.
a.
On Mon, 16 Aug 2010, Andy Farnell wrote:
Yep, there's a few synthesis techniques like 1/1+cos(x^n)
eee, do you mean 1/(1+cos(pow(x,n))), or do you mean 1/(1+pow(cos(x),n)) ?
and then, why would it want a zero there ?
Not sure to what extent it's still true but NaN used to royally screw up some versions of Jack and ALSA, requiring a complete restart of the audio stack.
I'm speculating that if they run an unprotected equivalent of [lop~] or [hip~] in their own code at any point, it sets the feedback variable to something that will never fade out, and then everything gets clipped to +1 or -1. (do they have recursive filters in there ?)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 08/16/2010 08:44 PM, Claude Heiland-Allen wrote:
If so i guess infinities and NaN have been recently introduced, haven't they?
No. But Pd tries to guard against them.
Ok, that's why I had never seen them.
Pd [/] guards against division by 0 by outputting 0 instead of +infinity, The reason why NaN and (to a lesser extent?) infinities are discouraged by non-scientific software is [...]
Yeah I understand and even like that.
But then I think it should either fully support them or fully "guard against" them and never ever let them surface, no?
On Mon, 16 Aug 2010, Matteo Sisti Sette wrote:
However there seem to be some inconsistency: 5/4 returns 0 (as I was used to), not +inf.
5/4 is not a division by 0, it's a division by 4.
and then, if it were a division by 0... that should give NaN. It can't be NaN because, among other things, you can't even know which sign of the infinity it should give, let alone whether "infinity" is a proper way to describe what's happening.
If you accept limits (as in "the limit of 1/x as x goes towards 0") as a suitable mathematical device in this context, then it gives +Inf when x decreases towards 0, but it gives -Inf when x increases towards 0. In such cases, the limit is usually said to "not exist".
If you copy the sign of the zero to decide whether the result is +Inf or -Inf, then you violate the rule that the sign of the zero shouldn't matter...
Also, I'm not sure +inf is the value you expect when adding something to the greatest representable value... or is it?
Infinity in the float format is a misnomer. It should really be called TooBig or something like that. In an Extended Reals context, this means that each infinity is used to approximate all values (of the same sign) that are too big, but in a plain Reals context, infinities don't really exist, so each "infinity" is just the set of all finite numbers that are two big (for each sign).
you know what I mean ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 08/16/2010 09:20 PM, Mathieu Bouchard wrote:
On Mon, 16 Aug 2010, Matteo Sisti Sette wrote:
However there seem to be some inconsistency: 5/4 returns 0 (as I was used to), not +inf.
5/4 is not a division by 0, it's a division by 4.
Sorry I meant 5/0
and then, if it were a division by 0... that should give NaN. It can't be NaN [guess you mean can't be infinity] because, among other things, you can't even know which sign of the infinity it should give,
If you accept limits (as in "the limit of 1/x as x goes towards 0") as a suitable mathematical device in this context, then it gives +Inf when x decreases towards 0, but it gives -Inf when x increases towards 0. In such cases, the limit is usually said to "not exist".
I think in this cases the limit is said to be "infinity" (without sign), meaning that being y=f(x), for every M>0 (no matter how big) you can always find a T>0 such that for all x:|x|<T you have |f(x)|>M. I think that is said to be an infinite limit (rather than non existing limit), and that applies to both real and complex numbers.
I think there exists a "compactification" of real numbers that takes this "limit" as one more number which is Infinity (without sign), thus making R compact (visually represented by mapping real numbers to the points of a circumference rather than a straight line). I don't know if this applies to complex numbers also.
In ActionScript actually (which is not a great example language but it is the one with which I could check right now), 5/0 gives Infinity, and -5/0 gives -Infinity.
Don't most programming languages behave like this? I always though NaN was only the result of 0/0 (and Inf-Inf, and other operations where any ""limit"" would be nonexistent), but I didn't consider the problem you mention about the sign
If you copy the sign of the zero to decide whether the result is +Inf or -Inf, then you violate the rule that the sign of the zero shouldn't matter...
That's right. Indeed, how can one postulate that 0==-0 is true and at the same time maintain that inf!=-inf???
In ActionScript:
0 == -0 -> true 1/0 == 1/-0 -> false
On Mon, 16 Aug 2010, Matteo Sisti Sette wrote:
I think in this cases the limit is said to be "infinity" (without sign), meaning that being y=f(x),
Not all number systems have a single infinity. standard floats have a split infinity. In math, the usual Extended Reals have a split infinity, but there's another kind of Extended Reals that have a unified infinity. The usual Extended Complexes have a unified infinity, but it's possible to imagine variations that have a continuum of different infinities making a "circle" "around" the complex plane...
for every M>0 (no matter how big) you can always find a T>0 such that for all x:|x|<T you have |f(x)|>M.
float math doesn't have a thing that we could call an "always-positive context" that would cause 1/|x| or 1/x² to be considered as +Inf at x=0, because at the point where the division happens, the computer has forgotten any trace of the preceding stuff that could allow it to compute a limit...
I think that is said to be an infinite limit (rather than non existing limit),
only in a number system that has a unified (signless) infinity. you can't suppose that here.
I think there exists a "compactification" of real numbers that takes this "limit" as one more number which is Infinity (without sign), thus making R compact (visually represented by mapping real numbers to the points of a circumference rather than a straight line).
Yes, that's what I mean by unified infinity instead of split infinity. This makes tan(x) a continuous function, for example.
I don't know if this applies to complex numbers also.
For complex numbers, the usual "compactification is onto a sphere, projecting from a point on the top of the sphere, where the sphere is on top of the origin of the plane.
In ActionScript actually (which is not a great example language but it is the one with which I could check right now), 5/0 gives Infinity, and -5/0 gives -Infinity.
Actually, I just checked it out, and the C language does it the same. Also, 5/-0 gives -Infinity, just to mess with our sense that +0 and -0 are supposed to be the same...
But 0/0 is NaN.
Don't most programming languages behave like this? I always though NaN was only the result of 0/0 (and Inf-Inf, and other operations where any ""limit"" would be nonexistent), but I didn't consider the problem you mention about the sign
It's a common source of disagreement. Eventually, any system of rules for handling infinity will "fail" at one point. The lesson is to avoid using infinity as much as possible... that's why modern calculus uses workaround definitions of the form "for each epsilon>0..." "there exists a delta such that..." and "there exists a N beyond which..." to carefully avoid saying anything like "infinity" ever. It's a TRAP !
0 == -0 -> true 1/0 == 1/-0 -> false
yeah. that's an IEEE standard, it seems. LOL
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Tue, 17 Aug 2010, Matteo Sisti Sette wrote:
On 08/17/2010 12:45 AM, Mathieu Bouchard wrote:
It's a common source of disagreement. Eventually, any system of rules for handling infinity will "fail" at one point.
Any? Or only those that try to _split_ the infinity into a positive and a negative one?
In the end, straight lines are good at being what straight lines are, and circles are good at being what circles are, and topologically, they aren't quite the same, and you can't have the characteristics of both systems at once, as it would be contradictory... that's just the topology part. After that there are the algebraïc matters...
for more reading : http://en.wikipedia.org/wiki/Extended_reals
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Andy Farnell -
Claude Heiland-Allen -
Mathieu Bouchard -
Matteo Sisti Sette