Re: Motion P1788/M0006.04_Level_2_Multi-format NO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Vincent,
Vincent Lefevre wrote:
> On 2009-09-08 11:13:05 +0200, Frédéric Goualard wrote:
>> John Pryce wrote:
>>> Ah yes. I share your concerns. But I don't see that voting no on
>>> motion 6 avoids the difficulties.
>>>
>>> - There are bound to be interval constructors, for instance in a C++
>>> "double" version, we surely can't avoid one that looks like
>>> interval(double x, double y)
>>>
>>> - Then you can't avoid the fact that possible calls are
>>> interval(Inf, Inf)
>>> interval(NaN,3)
>>> interval(4,3)
>>>
>>> The system has to respond to these invalid calls in SOME way.
>>> Frédéric: what would YOU have it do?
>> State that any invalid form is mapped to the empty set, which Motion 6
>> seems to forbid (at least for interval(inf, inf)). No exceptional
>> behavior, no NaI.
>
> I don't see why Motion 6 would forbid it. Motion 6 introduces here
> a Level-1 *notation*. This does not imply anything for interval
> constructors (that would be defined at Level 2 essentially): even
> though [+oo,+oo] is an invalid notation, one could decide that for
> an interval constructor, interval(+inf,+inf) is the empty set.
Motion 6.04 states on Page 5:
"[...] we treat [−oo,−oo] and [+oo,+oo] as having no meaning (rather
than being empty)."
I understand that we could state at some other level that all
"non-intervals" are mapped to the empty set. But then, I would like to
see a provision to that effect already in this motion instead of
scattered allusions to some NaI quantity, which in the current version
of the motion, seem the most natural object to which map intervals
notations without meaning to.
> In any case, NaN does not exist at Level 1. So, interval constructors
> may need to be "different" from the notation.
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/
iD8DBQFKp7RaEJvxJgN8HkgRAgRCAJ9u/dWlMFHTETW01H9V77sG1gep/QCg4566
WL0Fk3wz4tVx/o+azW4Pw24=
=OTUa
-----END PGP SIGNATURE-----