Re: >>: Exceptions vs NaN/NaI
Dima,
Yes, accessing arithmetic standards through programming
languages is indeed a question. For example, rounding mode
changes have been available since the original 754 was
implemented, but accessing them through programming languages
has been problematic. I know, in Fortran, it can be done
in a standardized way only since the Fortran 2003 standard
was approved. Also, 754 specifies accuracy of decimal / binary
conversions, but I know of compilers for which printed output
far from adheres to that standard. (The particular one
I am thinking of at the moment may be obsolete, though.)
That said, one can expect
most underlying arithmetic operations, say if you write "z = x+y"
in a programming language, to adhere to the 754 standard. For
example, try accessing the machine constants through intrinsic
functions in Matlab; you'll see they are the 754 constants.
I'm envisioning 1788 as an arithmetic standard, originally implemented
in software as classes, modules, or the like, and (possibly)
eventually in hardware.
Yes, I can see that conformance of your library can be a
legitimate concern.
Best regards,
Baker
On 04/20/2012 10:15 AM, Dmitry Nadezhin wrote:
----- Пересланное сообщение -----
От: dmitry.nadezhin@xxxxxxxxxx
Кому: rbk@xxxxxxxxxxxxx
Отправленные: Пятница, 20 Апрель 2012 г 18:41:09 GMT +04:00 Абу-Даби, Маскат
Тема: Re: Exceptions vs NaN/NaI
Suppose that somebody writes an implementation of intervals in
his favorite language. Signatures of operations in language
may differ a little from abstract signatures of corresponding
P1788 operation. It is not 100% clear to me how to make conclusion
if language implementation conforms to the P1788 standard.
Of course, I concerned mostly about my interval library in Java.
I think about how much chages will be necessary to make it conformant.
The library implements infsup_F datatype, where F=ExtendedRational .
ExtendedRational consists of -oo, +oo, and of fractions p/q with
restrictions q != 0, abs(p)< N, abs(q)< N for some huge N. This type dosn't contain
special value NaN. Numeric functions in my library throw Java ArithmeticException when
arguments are out of domain. They never return NaN.
Now ExtendedRational is total-ordered type (it implements Java interface Comparable).
I don't like an idea to add NaN to ExtendedRational, because it will loose total order.
And now I try to understand if I will be forced to add NaN.
Shortly speeking, NaN is not necessary for implementations that throw language exceptions instead of return NaN.
-Dima
----- Исходное сообщение -----
От: rbk@xxxxxxxxxxxxx
Кому: dmitry.nadezhin@xxxxxxxxxx
Копия: eliasen@xxxxxxxxxxxxxx, stds-1788@xxxxxxxxxxxxxxxxx
Отправленные: Пятница, 20 Апрель 2012 г 17:20:41 GMT +04:00 Абу-Даби, Маскат
Тема: Re: Exceptions vs NaN/NaI
Dima,
How do you envision enabling (3) through defining data types
and operations (my perceived scope of P-1788)? Note that,
if our standards document is silent on this point, that
does not preclude languages from throwing such an
exception (in a non-standard way, or in a standard-way,
if specified in the language).
Baker
On 04/18/2012 06:17 AM, Dmitry Nadezhin wrote:
It's a good point about trowing an exception.
Some constructors and numeric functions are undefined at Level 1 for some argument values.
Level 2 constructors/functions shall signal failure for such argument values.
There are a few common ways to signal a failure in programming anguages:
1) Set a global/thread-local flag like "errno";
2) Return specifal value like NaI or NaN;
3) Throw a language exception (like in C++ or in Java).
As far as I understand, the draft of the standard recommends(requires) (2).
I don't like (1) too.
However, shouldn't the P1788 be flexible enough to allow
both level 2 operations that signal by (2)
and level 2 operations that signal by (3) ?
-Dima
--
---------------------------------------------------------------
Ralph 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
---------------------------------------------------------------