Hi,
I would like to ask if there is a convention for representing infinity.
I do _not_ want to do arithmetic with infinity, and I know that the CL
standard does not deal with this issue. I just need something for
boundaries of integrals, cutoff points for truncated distributions, etc.
The functions of course test for infinity, eg
(defun truncated-normal-moment (n mu sigma lower upper)
(cond
(and (eq lower :minusinfinity) (eq upper :infinity)) ...
Currently I am using :minusinfinity and :infinity. But I thought it
would be good to adhere to some convention if there is already one.
Thanks,
Tamas
Tamas K Papp <······@gmail.com> writes:
> Hi,
>
> I would like to ask if there is a convention for representing infinity.
> I do _not_ want to do arithmetic with infinity, and I know that the CL
> standard does not deal with this issue. I just need something for
> boundaries of integrals, cutoff points for truncated distributions, etc.
> The functions of course test for infinity, eg
>
> (defun truncated-normal-moment (n mu sigma lower upper)
> (cond
> (and (eq lower :minusinfinity) (eq upper :infinity)) ...
>
> Currently I am using :minusinfinity and :infinity. But I thought it
> would be good to adhere to some convention if there is already one.
There's no convention.
On a specific implementation, (apropos "INFINITY") may give you some
constants mapping IEEE754 infinities.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
--=-=-=
Content-Transfer-Encoding: quoted-printable
Tamas K Papp <······@gmail.com> writes:
> I would like to ask if there is a convention for representing infinity.=
=20=20
snip
> Currently I am using :minusinfinity and :infinity. But I thought it=20
> would be good to adhere to some convention if there is already one.
For what it's worth, Maxima [1] uses the symbols 'inf and
'minf. Although the code seems to predate even packages (ie everything's
like 'maxima::inf), so I'm not sure one can regard this as best
practice.
Rupert
[1] http://maxima.sourceforge.net/
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iJwEAQECAAYFAkj7N1gACgkQRtd/pJbYVobQxAP8DFzJ96SS+ZZNBE/A2ozEt/ji
mkMnERGUW5Rkn4DRsc5+/wg2mqCUpjiBQgr4kHuuoO2FL9mLRcn3hakv2jfAm+iZ
ZyilnEex1JO2/Fm6wqYC1UDGiiJRVGOtcKOJeseLYakC4m+/PlEkX5p1SdogqoON
vUD56tF00HPK7n8tX1Q=
=c4Bz
-----END PGP SIGNATURE-----
--=-=-=--
On Sun, 19 Oct 2008 14:34:16 +0100, Rupert Swarbrick wrote:
> Tamas K Papp <······@gmail.com> writes:
>
>> I would like to ask if there is a convention for representing infinity.
>
> snip
>
>> Currently I am using :minusinfinity and :infinity. But I thought it
>> would be good to adhere to some convention if there is already one.
>
> For what it's worth, Maxima [1] uses the symbols 'inf and 'minf.
> Although the code seems to predate even packages (ie everything's like
> 'maxima::inf), so I'm not sure one can regard this as best practice.
Well, at least they are compact. :inf and :minf would be good, I will
think about it. If there is no best practice, I think it would be good
to establish one :-)
Tamas
On 2008-10-19 09:56:33 -0400, Tamas K Papp <······@gmail.com> said:
> Well, at least they are compact. :inf and :minf would be good, I will
> think about it. If there is no best practice, I think it would be good
> to establish one :-)
lispworks:
CL-USER 100 > (let ((pos-inf (* 1000 most-positive-double-float))
(neg-inf (* 1000 most-negative-double-float)))
(format t "double-float positive infinity is printed as:~%~a
double-float negative infinity is printed as:~%~a
their sum (not a number) is printed as: ~%~a"
pos-inf neg-inf (+ pos-inf neg-inf)))
double-float positive infinity is printed as:
+1D++0 #| +1D++0 is double-float plus-infinity |#
double-float negative infinity is printed as:
-1D++0 #| -1D++0 is double-float minus-infinity |#
their sum (not a number) is printed as:
1D+-0 #| 1D+-0 is double-float not-a-number |#
NIL
(note that the block comments are printed by lispworks, they are not mine)
sbcl:
CL-USER> (let ((pos-inf (* 1000 most-positive-double-float))
(neg-inf (* 1000 most-negative-double-float)))
(format t "double-float positive infinity is printed as ~a
double-float negative infinity is printed as ~a
their sum (not a number) is printed as ~a" pos-inf neg-inf (+ pos-inf
neg-inf)))
double-float positive infinity is printed as
#.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY
double-float negative infinity is printed as
#.SB-EXT:DOUBLE-FLOAT-NEGATIVE-INFINITY
their sum (not a number) is printed as #<DOUBLE-FLOAT quiet NaN>
NIL
openmcl and ecl just report a floating point overflow.
On Sun, 19 Oct 2008 11:15:48 -0400, Raffael Cavallaro wrote:
> On 2008-10-19 09:56:33 -0400, Tamas K Papp <······@gmail.com> said:
>
>> Well, at least they are compact. :inf and :minf would be good, I will
>> think about it. If there is no best practice, I think it would be good
>> to establish one :-)
>
> lispworks:
>
> CL-USER 100 > (let ((pos-inf (* 1000 most-positive-double-float))
> (neg-inf (* 1000 most-negative-double-float)))
> (format t "double-float positive infinity is printed
> as:~%~a
> double-float negative infinity is printed as:~%~a their sum (not a
> number) is printed as: ~%~a"
> pos-inf neg-inf (+ pos-inf neg-inf)))
>
> double-float positive infinity is printed as: +1D++0 #| +1D++0 is
> double-float plus-infinity |# double-float negative infinity is printed
> as: -1D++0 #| -1D++0 is double-float minus-infinity |# their sum (not a
> number) is printed as: 1D+-0 #| 1D+-0 is double-float not-a-number |#
> NIL
>
> (note that the block comments are printed by lispworks, they are not
> mine)
>
> sbcl:
>
> CL-USER> (let ((pos-inf (* 1000 most-positive-double-float))
> (neg-inf (* 1000 most-negative-double-float)))
> (format t "double-float positive infinity is printed as ~a
> double-float negative infinity is printed as ~a their sum (not a number)
> is printed as ~a" pos-inf neg-inf (+ pos-inf neg-inf)))
> double-float positive infinity is printed as
> #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY double-float negative infinity
> is printed as #.SB-EXT:DOUBLE-FLOAT-NEGATIVE-INFINITY their sum (not a
> number) is printed as #<DOUBLE-FLOAT quiet NaN> NIL
>
> openmcl and ecl just report a floating point overflow.
Thanks Raffaael, but I am looking for something portable. And maybe I
prefer using symbols because that precludes the possibility of
accidentally performing arithmetic on infinities, even if the
implementation allows that. I hated this in R, when I would make a
mistake (eg 1/0) somewhere but R would cheerfully proceed and I would end
up with nonsensical results.
Tamas
On 2008-10-19 11:47:35 -0400, Tamas K Papp <······@gmail.com> said:
> Thanks Raffaael, but I am looking for something portable.
My point was that there is no current convention for such quantities
and that there is nothing portable possible since the spec specifies
that "An error of type floating-point-overflow or
floating-point-underflow should be signaled if a floating-point
computation causes exponent overflow or underflow, respectively."
This means at the very least that implementations are free to signal (I
think should signal) a floating point overflow rather than :+inf or
somesuch just as both openmcl/clozure cl and ecl do now.
There is nothing in the standard about infinities, just the constants
that represent the most positive and most negative numbers "closest in
value to, but not equal to, positive/negative infinity that an
implementation can represent" (i.e., most-positive-single-float,
most-negative-double-float, etc.)
Tamas K Papp <······@gmail.com> writes:
> On Sun, 19 Oct 2008 14:34:16 +0100, Rupert Swarbrick wrote:
>
>> Tamas K Papp <······@gmail.com> writes:
>>
>>> I would like to ask if there is a convention for representing infinity.
>>
>> snip
>>
>>> Currently I am using :minusinfinity and :infinity. But I thought it
>>> would be good to adhere to some convention if there is already one.
>>
>> For what it's worth, Maxima [1] uses the symbols 'inf and 'minf.
>> Although the code seems to predate even packages (ie everything's like
>> 'maxima::inf), so I'm not sure one can regard this as best practice.
>
> Well, at least they are compact. :inf and :minf would be good, I will
> think about it. If there is no best practice, I think it would be good
> to establish one :-)
I don't think that :minf is the best choice, simply because when a
person reads it they immediately think "minimum F" and not "minus
infinity." Something like :-inf could cover for that, though.
From: David Golden
Subject: Re: convention for infinity
Date:
Message-ID: <gdfn25$d3l$1@aioe.org>
Tamas K Papp wrote:
> Well, at least they are compact. :inf and :minf would be good, I will
> think about it. If there is no best practice, I think it would be
> good to establish one :-)
>
> Tamas
IEEE floating-point "infinities" are probably what you [Tamas] in
particular care about, but I doubt maxima's ones are intended to be
them:
I'd tend to use an unqualified "infinity" in a symbolic math package for
the +/- infinities on the affinely
http://en.wikipedia.org/wiki/Extended_real_number_line
I imagine that those, and not the floating point "infinities" are what
the maxima :inf and minf are supposed to correspond to. It would make
sense given maxima is a symbolic maths package.
( Beyond that, consider aleph numbers...
http://en.wikipedia.org/wiki/Aleph_number )
So, sure, it would be nice for IEEE-floating-point-using implementations
standardise on printable/readable representations for
the IEEE floating point "infinities" and so forth, but don't confuse
them with real infinities, seeing as lisp is used for implementing
symbolic maths packages so much. Yes, the IEEE floats are supposed to
_approximate_ the affinely extended real numbers, but they are _not_ the
same.
Just sayin'.
As to printable/readable reps, I find SBCL's ones in particular a tad
verbose even by common lisp standards - kinda spoils tabular printouts,
would be nice if they were of roughly the same order of printed length
as typical floating point values. Lispworks' solution that Raffael
shows is interesting then, except for the block comments...
Maybe something like -1D#INFN# , 1D#INFP# , 1D#NANS# , 1D#NANQ#
would be nice...