Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Motion P1788/M0006.04_Level_2_Multi-format NO



Frédéric et al,

Yes, I also like the idea of identifying [-oo,-oo] and [+oo, +oo]
with the empty set.  In practice, that is what they are, if
the underlying model is the reals, something that we decided.
(If we had decided that the underlying model was the extended
reals, they would effectively be the empty set in union
and intersection operations.)  This seems to be logically clean.

Of course, we may leave open more than one representation of
the empty set, if particular implementations might want
to preserve the information about how the empty set was
generated.

Regarding other issues of expediency and efficiency with this
stand, I'll leave it to others to comment.

Baker

Frédéric Goualard wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/7/09 8:46 AM, "Vincent Lefevre" <vincent@xxxxxxxxxx> wrote:
On 2009-09-07 09:46:46 +0200, Frédéric Goualard wrote:
My vote is NO because the associated position paper definitely
assumes---even if peripherally---the implicit (e.g., [-oo, -oo] and
[+oo, +oo] have no meaning, which should make them NaIs, whatever
that object is) or explicit existence of NaIs, a concept I am not in
favour of.
This is not what the paper says. "No meaning" currently implies
undefined behavior, not the existence of some form of NaI.
Having to deal with such meaningless representations could
imply performance penalties.

Indeed. Anyway, I wonder how such an undefined behavior would be handled
practically by programming languages that lack exception facilities.
External flags (such as the infamous C errno) do not seem that good an
option. Should we really put this burden on implementors (the Standard
being language agnostic) while identifying [-oo,-oo] and [+oo, +oo] to
the empty set appears to have so few drawbacks (correct me on that one:
I have seen many discussions in the Motion 7 thread on that topic and
may have overlooked some definitive argument against it)?


F.
- --
Frédéric Goualard                                 LINA - UMR CNRS 6241
Tel.: +33 2 51 12 58 38    Univ. of Nantes - Ecole des Mines de Nantes
Fax.: +33 2 51 12 58 12            2, rue de la Houssinière - BP 92208
http://goualard.frederic.free.fr/               F-44322 NANTES CEDEX 3

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKpRcPEJvxJgN8HkgRAnTWAJ47Ukt0FiDuC5ym4VRYQi2YPiNQNQCdGPyh
BjoV6rSQDQFcJClVLzORcYg=
=pA3C
-----END PGP SIGNATURE-----



--

---------------------------------------------------------------
R. Baker Kearfott,    rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------