[PD-dev] [float infinity] and [float -infinity]

Mathieu Bouchard matju at artengine.ca
Mon Jan 30 05:15:08 CET 2006


On Sun, 29 Jan 2006, Hans-Christoph Steiner wrote:

> [1 0(---[/], [-1 0(---[/], [0 0(---[/], and [2 666(---[pow] don't work
> because they output "inf" and "-inf", and you can't do operations on
> them, like comparing them with [moses].

The first three currently give "0", a special case hardcoded into [/]. 
IEEE-compliance would mean that they would give +infinity, -infinity and 
NaN, respectively. The fourth one currently gives infinity and is 
IEEE-compliant.

In the IEEE float system, infinities are comparable. Of all comparable
numbers, +infinity is the greatest, and -infinity is the least. Infinities 
are [moses]-safe.

NaN is the only non-comparable number. Any comparison with it yields 0. It
isn't even equal to itself. You can use NaN with [moses] but it breaks the
usual expectations about how [moses] works.

> And I do not think that all math objects should support these.  [float
> infinity] would output the float value of FLT_MAX, and then the math
> objects would use that value.

If you don't want infinities to be supported, even though they _are_ 
comparable, please don't call FLT_MAX "infinity", just call it "max".

> IEEE-compliance sounds good.  Feel like submitting some patches?

My pinky toe tells me that if Miller has decided to put extra code in 
order to break IEEE-compliance, that it will be extra hard to make him 
remove it. I don't think that you'd be in favour of IEEE-compliance 
either, considering what you have said in the last two mails.

 _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada




More information about the Pd-dev mailing list