[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