W3C home > Mailing lists > Public > public-qt-comments@w3.org > March 2004

RE: ORA-FO-180-B: fn:abs undocumented exception is possible

From: Ashok Malhotra <ashokma@microsoft.com>
Date: Sun, 28 Mar 2004 15:15:42 -0800
Message-ID: <EDB607C8AC991F40BE646533A1A673E801A586A4@RED-MSG-42.redmond.corp.microsoft.com>
To: "Jim Melton" <jim.melton@acm.org>
Cc: "Stephen Buxton" <Stephen.Buxton@oracle.com>, <public-qt-comments@w3.org>

Thanks, Jim.  You're correct! I think we should add an error condition
and also some explanation.

All the best, Ashok

-----Original Message-----
From: Jim Melton [mailto:jim.melton@acm.org] 
Sent: Saturday, March 27, 2004 1:36 PM
To: Ashok Malhotra
Cc: Stephen Buxton; public-qt-comments@w3.org
Subject: RE: ORA-FO-180-B: fn:abs undocumented exception is possible

Ashok,

At 01:03 PM 3/27/2004 Saturday, Ashok Malhotra wrote:

>Steve:
>In this and a related comment on the unary minus operator
>http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0721.htm
l
>you say that the magnitude of the largest negative value is less than
>the magnitude of the largest positive value.  I don't understand this.
>I thought all the these operations did was flip the sign bit but
perhaps
>some representations work differently.  Could you please elaborate.

This has been a perennial thorn in the side of SQL standardizers.

If you have a binary representation for some data type (e.g.,
"integer"), 
and that representation has a specific, fixed number of bits (e.g., 32),

then the range of values available for sites of that type is -(2^32) .. 
+(2^32)-1.

Consider a 16-bit integer (just to make the numbers more manageable).
The 
range of values is -32,678 .. +32767 (if the integer is signed, of
course; 
if it is unsigned, then the range is 0 .. 65,535).

Therefore, for *fixed-length binary representations*, under
2s-complement 
arithmetic/notation, the magnitude of the largest positive value is less

than the absolute magnitude of the smallest negative value.  (Actually, 
your quote suggests that the Oracle comment said that the magnitude of 
negative values is smaller than the magnitude of positive values; if
that's 
what we said, then it was a typographical error.)

On the other hand, if a decimal notation is used, the magnitudes of the 
largest positive value and the smallest negative value are identical
(for 
example, a 5-digit decimal type would support values ranging from
-99,999 
.. +99,999).  The same is true of binary 1s-complement
arithmetic/notation, 
where the range of a 16-bit type is -32,767 .. +32,767 (but the cost
here 
is that you get 2 zeros: +0 and -0).  I know of no current commercial 
hardware that uses 1s-complement notation for binary representations.  I

know of only a few hardware decimal representation implementations, but 
they are commerically important ones.

Hope this helps,
    Jim



>All the best, Ashok
>-----Original Message-----
>From: public-qt-comments-request@w3.org
>[mailto:public-qt-comments-request@w3.org] On Behalf Of Stephen Buxton
>Sent: Monday, February 16, 2004 6:42 AM
>To: public-qt-comments@w3.org
>Subject: ORA-FO-180-B: fn:abs undocumented exception is possible
>
>
>SECTION 6.4.1: fn:abs
>
>This function may raise an overflow error if the absolute value
>exceeds the capacity of the return type.
>
>
>- Steve B.

========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
Oracle Corporation        Oracle Email: jim dot melton at oracle dot com
1930 Viscounti Drive      Standards email: jim dot melton at acm dot org
Sandy, UT 84093-1063              Personal email: jim at melton dot name
USA                                                Fax : +1.801.942.3345
========================================================================
=  Facts are facts.  However, any opinions expressed are the opinions  =
=  only of myself and may or may not reflect the opinions of anybody   =
=  else with whom I may or may not have discussed the issues at hand.  =
========================================================================
Received on Sunday, 28 March 2004 18:15:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:56 UTC