You might notice, I am doing some math these days ;). I just had another idea for a handy thing when doing math: a method of getting the smallest and largest possible numbers. Basically, the Pd version of a #define INFINITY 1e37 (or whatever it is).
I think it would be handy to have as part of [float], like this:
[float infinity] and [float -infinity] (FLT_MAX and FLT_MIN) or maybe: [float max] and [float min] (FLT_MAX and FLT_MIN)
Other float.h defines would also be handy to have access to:
http://www.gnu.org/software/libc/manual/html_node/Floating-Point- Parameters.html
Something like this:
[float max_exp] (FLT_MAX_EXP) [float min_exp] (FLT_MIN_EXP)
And perhaps [int] could also have the relevant versions of the same too. I guess that would just be:
[int infinity] and [int -infinity] or maybe: [int max] and [int min]
I don't think I'll have time to code this any time soon, but I can put it into feature requests...
.hc
________________________________________________________________________ ____
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
On Sat, 28 Jan 2006, Hans-Christoph Steiner wrote:
I just had another idea for a handy thing when doing math: a method of getting the smallest and largest possible numbers. Basically, the Pd version of a #define INFINITY 1e37 (or whatever it is).
Wow, I didn't recall infinity being so small!
The largest possible finite values are FLT_MAX and FLT_MIN, which are +/- 2^128*(1-2^23).
Infinity values could be computed using [1 0( -> [/] and [-1 0( -> [/]. NaN (Not a Number) could be computed using [0 0( -> [/]. That is, if Pd were IEEE-compliant...
However you can still compute +infinity using [2 666( -> [pow].
[expr] is not IEEE-compliant either, but according to it, log(0) is -infinity and log(-1) is NaN, whereas according to Miller's [log], log(0) is -1000.
I think it would be handy to have as part of [float], like this: [float infinity] and [float -infinity]
But those would be mere shortcuts for what you can already do with two boxes.
(FLT_MAX and FLT_MIN) or maybe: [float max] and [float min] (FLT_MAX and FLT_MIN)
Please distinguish large finite values and infinite values.
[float max_exp] (FLT_MAX_EXP) [float min_exp] (FLT_MIN_EXP)
what is nice about those things is that they would increase portability between the current 32-bit float pd and a future 64-bit float pd.
However I don't like the fact that you can't use them everywhere.
If in [+ max_exp], max_exp is a float, then what does [symbol max_exp] do? How can those things work uniformly without having to add special code everywhere?
And perhaps [int] could also have the relevant versions of the same too.
It's not documented that [int]'s type is C's "int". Reading the helpfile, it could as well be implemented using C's truncf(). There is a difference: [2 666( -> [pow] -> [int] yields a negative number.
[int infinity] and [int -infinity] or maybe: [int max] and [int min]
machine integer types don't have infinities, but they do have extrema. The C type used by [int] is int, which goes from -2^31 to 2^31-1.
if [int] were using truncf(), [int]'s limits would be the same as [float]'s limits.
There's also a t_int type defined in m_pd.h but [int] doesn't use it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 29, 2006, at 3:57 AM, Mathieu Bouchard wrote:
On Sat, 28 Jan 2006, Hans-Christoph Steiner wrote:
I just had another idea for a handy thing when doing math: a method of getting the smallest and largest possible numbers. Basically, the Pd version of a #define INFINITY 1e37 (or whatever it is).
Wow, I didn't recall infinity being so small!
The largest possible finite values are FLT_MAX and FLT_MIN, which are +/- 2^128*(1-2^23).
Infinity values could be computed using [1 0( -> [/] and [-1 0( -> [/]. NaN (Not a Number) could be computed using [0 0( -> [/]. That is, if Pd were IEEE-compliant...
However you can still compute +infinity using [2 666( -> [pow].
[expr] is not IEEE-compliant either, but according to it, log(0) is -infinity and log(-1) is NaN, whereas according to Miller's [log], log(0) is -1000.
I think it would be handy to have as part of [float], like this: [float infinity] and [float -infinity]
But those would be mere shortcuts for what you can already do with two boxes.
(FLT_MAX and FLT_MIN) or maybe: [float max] and [float min] (FLT_MAX and FLT_MIN)
Please distinguish large finite values and infinite values.
[float max_exp] (FLT_MAX_EXP) [float min_exp] (FLT_MIN_EXP)
what is nice about those things is that they would increase portability between the current 32-bit float pd and a future 64-bit float pd.
However I don't like the fact that you can't use them everywhere.
If in [+ max_exp], max_exp is a float, then what does [symbol max_exp] do? How can those things work uniformly without having to add special code everywhere?
And perhaps [int] could also have the relevant versions of the same too.
It's not documented that [int]'s type is C's "int". Reading the helpfile, it could as well be implemented using C's truncf(). There is a difference: [2 666( -> [pow] -> [int] yields a negative number.
[int infinity] and [int -infinity] or maybe: [int max] and [int min]
machine integer types don't have infinities, but they do have extrema. The C type used by [int] is int, which goes from -2^31 to 2^31-1.
if [int] were using truncf(), [int]'s limits would be the same as [float]'s limits.
There's also a t_int type defined in m_pd.h but [int] doesn't use it.
[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]. I think that supporting them in [float] makes sense since they are numbers more than objects. [float infinity] should output a float that can be used in comparisons.
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.
IEEE-compliance sounds good. Feel like submitting some patches?
.hc
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
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
On Jan 29, 2006, at 11:15 PM, Mathieu Bouchard wrote:
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.
Apparently Pd is not alone in its lack of IEEE 754 compliance, python uses the OS-specific values, which are not always the same:
http://www.python.org/peps/pep-0754.html
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".
Why? I think this would be confused with [max] and [min]. I think that we can make things close to IEEE style with much less work by doing [float infinity], etc.. Plus IEEE names are "PosInf", "NegInf", and "NaN", so [float infinity] and [float -infinity] and [float not_a_number] are obviously different.
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.
I am just discussing the options. I said I supported it, and that's what I mean. I don't need an interpreter on the list :-P. But it doesn't mean that I support it without discussion.
.hc ________________________________________________________________________ ____
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
On Tue, 31 Jan 2006, Hans-Christoph Steiner wrote:
Apparently Pd is not alone in its lack of IEEE 754 compliance, python uses the OS-specific values, which are not always the same: http://www.python.org/peps/pep-0754.html
BTW GridFlow isn't IEEE-compliant either. It was designed for use with integer numbers, and the integer format doesn't have infinities nor NaN, so, with integers, division by 0 gives an ordinary integer. The floats of GridFlow follow what the ints do rather than IEEE.
Why? I think this would be confused with [max] and [min]. I think that we can make things close to IEEE style with much less work by doing [float infinity], etc.. Plus IEEE names are "PosInf", "NegInf", and "NaN", so [float infinity] and [float -infinity] and [float not_a_number] are obviously different.
Many languages support IEEE except for the naming of the values. That is, the relationships between the different floats are compatible with IEEE, but it's just that the names of the three special values aren't the same as in IEEE or aren't available (so they have to be generated by 1/0 -1/0 0/0 instead).
I am just discussing the options. I said I supported it, and that's what I mean. I don't need an interpreter on the list :-P.
Well, now I'm really confused.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sat, 28 Jan 2006 12:51:53 -0500 Hans-Christoph Steiner hans@eds.org wrote:
You might notice, I am doing some math these days ;). I just had another idea for a handy thing when doing math: a method of getting the smallest and largest possible numbers. Basically, the Pd version of a #define INFINITY 1e37 (or whatever it is).
I think it would be handy to have as part of [float], like this:
[float infinity] and [float -infinity] (FLT_MAX and FLT_MIN) or maybe: [float max] and [float min] (FLT_MAX and FLT_MIN)
Other float.h defines would also be handy to have access to:
http://www.gnu.org/software/libc/manual/html_node/Floating-Point- Parameters.html
Something like this:
[float max_exp] (FLT_MAX_EXP) [float min_exp] (FLT_MIN_EXP)
And perhaps [int] could also have the relevant versions of the same too. I guess that would just be:
[int infinity] and [int -infinity] or maybe: [int max] and [int min]
I don't think I'll have time to code this any time soon, but I can put it into feature requests...
Please do. I would also find this really useful. I recently wrote an external to help remove infs and NaNs from data I was sending to a database, and needed to write a another silly extern to to generate the values to test it! Something like that should definitely be possible with 'builtins'.
Jamie
-
Hans-Christoph Steiner -
Jamie Bullock -
Mathieu Bouchard