In article <················@fed1read03>,
Ari Johnson <·····@hotmail.com> wrote:
> Does CL offer a standard way to represent infinite values?
No.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Ari Johnson <·····@hotmail.com> writes:
> Does CL offer a standard way to represent infinite values?
Infinite values of what? T is often used as an indicator of infinity, at
least in my code.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Ari Johnson <·····@hotmail.com> writes:
>
>
>>Does CL offer a standard way to represent infinite values?
>
>
> Infinite values of what? T is often used as an indicator of infinity, at
> least in my code.
Infinite numerical values. IEEE floating point +inf and -inf, for example.
Ari Johnson <·····@hotmail.com> writes:
> Rahul Jain wrote:
>
>> Ari Johnson <·····@hotmail.com> writes:
>>
>>>Does CL offer a standard way to represent infinite values?
>> Infinite values of what? T is often used as an indicator of
>> infinity, at
>> least in my code.
>
> Infinite numerical values. IEEE floating point +inf and -inf, for example.
I'd hope that any implementation with :ieee-floating-point in its
features list provides some way to do IEEE floating point arithmetic,
though of course this isn't guaranteed. So there is no standard;
check your implementation's documentation.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
In article <··············@cam.ac.uk>,
Christophe Rhodes <·····@cam.ac.uk> wrote:
> Ari Johnson <·····@hotmail.com> writes:
>
> > Rahul Jain wrote:
> >
> >> Ari Johnson <·····@hotmail.com> writes:
> >>
> >>>Does CL offer a standard way to represent infinite values?
> >> Infinite values of what? T is often used as an indicator of
> >> infinity, at
> >> least in my code.
> >
> > Infinite numerical values. IEEE floating point +inf and -inf, for example.
>
> I'd hope that any implementation with :ieee-floating-point in its
> features list provides some way to do IEEE floating point arithmetic,
> though of course this isn't guaranteed. So there is no standard;
> check your implementation's documentation.
I interpreted the OP's question to be about a standard *printed*
representation of infinities, so that he could type them in response to
prompts.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> wrote:
> I interpreted the OP's question to be about a standard *printed*
> representation of infinities, so that he could type them in response to
> prompts.
1.0e99999 and 1.0L99999 should work just fine for that purpose.
Will
··········@verizon.net (William D Clinger) writes:
> Barry Margolin <······@alum.mit.edu> wrote:
>> I interpreted the OP's question to be about a standard *printed*
>> representation of infinities, so that he could type them in response to
>> prompts.
>
> 1.0e99999 and 1.0L99999 should work just fine for that purpose.
I don't think it's beyond the bounds of possibility that an
implementation provides long floats to 100000 digits of precision;
indeed, clisp seems to do that fine.
Furthermore, is it not the case that, if the IEEE rounding mode is
towards negative infinity, parsing that as a float should give you
most-positive-fooative-float? I admit to being not entirely sure
about this, given that I've hardly seen any code which uses ieee754
features in the wild.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> wrote:
> > 1.0e99999 and 1.0L99999 should work just fine for that purpose.
>
> I don't think it's beyond the bounds of possibility that an
> implementation provides long floats to 100000 digits of precision;
> indeed, clisp seems to do that fine.
Right you are. I should have qualified my sentence by adding "in
systems that use IEEE floating-point arithmetic".
> Furthermore, is it not the case that, if the IEEE rounding mode is
> towards negative infinity, parsing that as a float should give you
> most-positive-fooative-float? I admit to being not entirely sure
> about this, given that I've hardly seen any code which uses ieee754
> features in the wild.
Now *that* is a genuinely interesting question about the semantics
of Common Lisp. I think it's clear that implementations can pretty
much do whatever they want in this case, since CL doesn't mandate
IEEE arithmetic at all, but what implementations *should* do remains
an interesting moral question.
(I'm inclined to agree with you, but I'm not sure either.)
Will
··········@verizon.net (William D Clinger) writes:
> Christophe Rhodes <·····@cam.ac.uk> wrote:
>> > 1.0e99999 and 1.0L99999 should work just fine for that purpose.
>>
>> I don't think it's beyond the bounds of possibility that an
>> implementation provides long floats to 100000 digits of precision;
>> indeed, clisp seems to do that fine.
>
> Right you are. I should have qualified my sentence by adding "in
> systems that use IEEE floating-point arithmetic".
Can I request a slight extra qualification? "... in systems that use
exclusively IEEE floating-point arithmetic", I mean. There are four
floating-point types provided by the ANSI standard, of which two map
quite nicely onto IEEE single and double -- but there's significant
scope for extension by implementations in using SHORT-FLOAT and
LONG-FLOAT for interesting things.
>> Furthermore, is it not the case that, if the IEEE rounding mode is
>> towards negative infinity, parsing that as a float should give you
>> most-positive-fooative-float? I admit to being not entirely sure
>> about this, given that I've hardly seen any code which uses ieee754
>> features in the wild.
>
> Now *that* is a genuinely interesting question about the semantics
> of Common Lisp. I think it's clear that implementations can pretty
> much do whatever they want in this case, since CL doesn't mandate
> IEEE arithmetic at all, but what implementations *should* do remains
> an interesting moral question.
:-) I think it's tricky without seeing any code that wants to use this
kind of advanced feature... though of course there's a bootstrapping
problem here.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Ari Johnson <·····@hotmail.com> wrote in message news:<·················@fed1read03>...
> Infinite numerical values. IEEE floating point +inf and -inf, for example.
I also wish there were an integer infinity.
Mark McConnell wrote:
> Ari Johnson <·····@hotmail.com> wrote in message news:<·················@fed1read03>...
>
>>Infinite numerical values. IEEE floating point +inf and -inf, for example.
>
>
> I also wish there were an integer infinity.
I'd just be happy with a printed representation of the IEEE values. I
also don't see a good reason why you can't have a "rational infinity" of
1/0 for +Inf and -1/0 for -Inf.
In article <·················@fed1read03>,
Ari Johnson <·····@hotmail.com> wrote:
> Mark McConnell wrote:
> > Ari Johnson <·····@hotmail.com> wrote in message
> > news:<·················@fed1read03>...
> >
> >>Infinite numerical values. IEEE floating point +inf and -inf, for example.
> >
> >
> > I also wish there were an integer infinity.
>
> I'd just be happy with a printed representation of the IEEE values. I
> also don't see a good reason why you can't have a "rational infinity" of
> 1/0 for +Inf and -1/0 for -Inf.
Because infinities aren't rational numbers. They're acceptible in
floating point computations because these are already approximations;
infinities are an extension of that, as an approximation for something
that in algebra would be represented as a limit expression.
Rational arithmetic, on the other hand, is required to be exact. As
soon as an infinity gets into the equation, all exactness is lost
(unless you manipulate them symbolically, like Macsyma can).
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin wrote:
> In article <·················@fed1read03>,
> Ari Johnson <·····@hotmail.com> wrote:
>
>
>>Mark McConnell wrote:
>>
>>>Ari Johnson <·····@hotmail.com> wrote in message
>>>news:<·················@fed1read03>...
>>>
>>>
>>>>Infinite numerical values. IEEE floating point +inf and -inf, for example.
>>>
>>>
>>>I also wish there were an integer infinity.
>>
>>I'd just be happy with a printed representation of the IEEE values. I
>>also don't see a good reason why you can't have a "rational infinity" of
>>1/0 for +Inf and -1/0 for -Inf.
>
>
> Because infinities aren't rational numbers. They're acceptible in
> floating point computations because these are already approximations;
> infinities are an extension of that, as an approximation for something
> that in algebra would be represented as a limit expression.
>
> Rational arithmetic, on the other hand, is required to be exact. As
> soon as an infinity gets into the equation, all exactness is lost
> (unless you manipulate them symbolically, like Macsyma can).
Fair enough. So how do you represent the IEEE floating point infinite
values?
Ari Johnson <·····@hotmail.com> writes:
> Fair enough. So how do you represent the IEEE floating point infinite
> values?
In COMMON-LISP: you don't get any standard way to represent IEEE
floating point infinite value. There's no IEEE floating point to
start with in the COMMON-LISP standard.
In a given implementation that happens to use IEEE floating point to
implement COMMON-LISP floating point numbers: IT DEPENDS ON THE IMPLEMENTATION!
What implementation do you use?
In COMMON-LISP you can always create a package exporting some
arithmetic operations such as: MYFLOAT:+, MYFLOAT:-, MYFLOAT:* and
MYFLOAT:/ and some special "numbers" such as: MYFLOAT:+INFINITY and
MYFLOAT:-INFINITY such as, for example:
(defun MYFLOAT:/ (a b)
(cond
((and (numberp a) (member b '(MYFLOAT:-INFINITY MYFLOAT:+INFINITY)))
0)
((and (numberp b) (member a '(MYFLOAT:-INFINITY MYFLOAT:+INFINITY)))
a)
((and (eq a MYFLOAT:-INFINITY) (eq a MYFLOAT:-INFINITY))
1) ;; Hey! That's MY rules!
((and (eq a MYFLOAT:+INFINITY) (eq a MYFLOAT:+INFINITY))
1)
((and (eq a MYFLOAT:+INFINITY) (eq a MYFLOAT:-INFINITY))
-1)
((and (eq a MYFLOAT:-INFINITY) (eq a MYFLOAT:+INFINITY))
-1)
((= b 0) (if (< a 0) MYFLOAT:-INFINITY MYFLOAT:+INFINITY))
(t (COMMON-LISP:/ a b))))
Then you'd have a nice infinity representation:
(MYFLOAT:/ 0 1) --> MYFLOAT:+INFIINITY
But there's no question of IEEE, since a COMMON-LISP implementation
could as well run on a hardware that implements floating point numbers
with little corks floating on columns of water, for all we know.
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
Pascal Bourguignon wrote:
> Ari Johnson <·····@hotmail.com> writes:
>
>>Fair enough. So how do you represent the IEEE floating point infinite
>>values?
>
>
> In COMMON-LISP: you don't get any standard way to represent IEEE
> floating point infinite value. There's no IEEE floating point to
> start with in the COMMON-LISP standard.
>
> In a given implementation that happens to use IEEE floating point to
> implement COMMON-LISP floating point numbers: IT DEPENDS ON THE IMPLEMENTATION!
>
>
> What implementation do you use?
SBCL claims (member :ieee-floating-point *features*), so let's use it as
an example. Is there a printed representation of the IEEE infinite
values in SBCL?
Ari Johnson <·····@hotmail.com> writes:
> SBCL claims (member :ieee-floating-point *features*), so let's use it
> as an example. Is there a printed representation of the IEEE infinite
> values in SBCL?
#.SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY
[ DOUB NEGA as appropriate ]
Christophe
(Maybe it might be time to trail an extremely experimental
under-development exploratory-programming investigation of this and
similar issues, over at
<http://www.common-lisp.net/project/ieeefp-tests/>. Feedback
welcome. I also hope to speak at/to people at the Libre Software
Meeting in a week's time about this.)
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
In article <··············@cam.ac.uk>,
Christophe Rhodes <·····@cam.ac.uk> wrote:
> Ari Johnson <·····@hotmail.com> writes:
>
> > SBCL claims (member :ieee-floating-point *features*), so let's use it
> > as an example. Is there a printed representation of the IEEE infinite
> > values in SBCL?
>
> #.SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY
> [ DOUB NEGA as appropriate ]
That doesn't seem like the best printed rep to use, since it can't be
read when *READ-EVAL* is NIL.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> writes:
> In article <··············@cam.ac.uk>,
> Christophe Rhodes <·····@cam.ac.uk> wrote:
>
>> #.SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY
>> [ DOUB NEGA as appropriate ]
>
> That doesn't seem like the best printed rep to use, since it can't be
> read when *READ-EVAL* is NIL.
Best is the enemy of Good. I'll be interested in improving the
printed representation just as soon as I get the first non-theoretical
bug report about it.[*]
Christophe
[*] I hereby give myself an exemption from the 'non-theoretical'
requirement.
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Pascal Bourguignon wrote:
> But there's no question of IEEE, since a COMMON-LISP implementation
> could as well run on a hardware that implements floating point numbers
> with little corks floating on columns of water, for all we know.
You've been reading Guy Steele's "Crunchly" cartoons,
haven't you?
--
Gareth McCaughan
.sig under construc
Barry Margolin <······@alum.mit.edu> writes:
> In article <·················@fed1read03>,
> Ari Johnson <·····@hotmail.com> wrote:
>
> > Mark McConnell wrote:
> > > Ari Johnson <·····@hotmail.com> wrote in message
> > > news:<·················@fed1read03>...
> > >
> > >>Infinite numerical values. IEEE floating point +inf and -inf, for example.
> > >
> > >
> > > I also wish there were an integer infinity.
> >
> > I'd just be happy with a printed representation of the IEEE values. I
> > also don't see a good reason why you can't have a "rational infinity" of
> > 1/0 for +Inf and -1/0 for -Inf.
>
> Because infinities aren't rational numbers. They're acceptible in
> floating point computations because these are already approximations;
> infinities are an extension of that, as an approximation for something
> that in algebra would be represented as a limit expression.
>
> Rational arithmetic, on the other hand, is required to be exact. As
> soon as an infinity gets into the equation, all exactness is lost
> (unless you manipulate them symbolically, like Macsyma can).
I don't think it has anything to do with being exact or not. It is
just that what people think of as a "number" (this is a vague idea)
doesn't include "infinity". This topic came up in sci.math a few
weeks ago.
Consider rational numbers with an infinity, call it "inf". Let the
usual rules of aritmetic work for addition, subtraction,
multiplication and division of pairs of rationals. For combination of
a rational r and inf, set
(+ r inf) => inf
(- r inf) => inf
(* r inf) => inf
(/ r inf) => 0
(< r inf) => T
and so forth
then let (- inf inf), (/ inf inf), (< inf inf) be undefined and throw
some sort of math exception. After all, we already handle division by
zero. Nothing strikes me as inexact. However, the rationals with inf
(or +inf and -inf) would no longer be a "field".
Also, do you want one infinity or two (or more)? Rationals with inf
is distinct from rationals with +inf and -inf.
In complex analysis, the Reimann sphere is a useful concept. This is
where you adjoin a point at infinity to the usual set of complex
numbers and extend the topology such that neighborhoods of infinity
contain everything of sufficiently large magnitude. This shows that
having an infinity isn't completely useless. But the traditional
definition of complex numbers without the infinite point hints that it
is perhaps not as useful.
I think that the answer is somewhat part of
*) it is traditional to exclude "infinity" from the concept of
"number"
*) no integer machine representation for "infinity" (but IEEE floats
do have +inf, -inf and, i think, a combined inf)
*) did you want one infinity or two?
*) being a field seems more useful than having an infinite quantity
--
Johan KULLSTAM
Johan Kullstam wrote:
> *) it is traditional to exclude "infinity" from the concept of
> "number"
Fair enough.
> *) no integer machine representation for "infinity" (but IEEE floats
> do have +inf, -inf and, i think, a combined inf)
Just +inf and -inf, as well as a NaN (not-a-number) value.
> *) did you want one infinity or two?
Two. There are, after all, two ends of the number line. More wouldn't
necessarily be a bad idea - I'd imagine that there are times when it
would be quite useful to have many infinite values available for
comparison purposes. Aleph-n for 0 <= n in Z, and their negative
counterparts.
> *) being a field seems more useful than having an infinite quantity
You have a very good point there, regarding rationals, but with IEEE
floats there is enough loss of precision and accuracy that I think the
infinite quantity would be more useful than pretending you really have a
field.