[dsdl-discuss] Re: Numeric precision

From: Martin Bryan <mtbryan@sgml.u-net.com>
Date: Mon Feb 10 2003 - 15:58:58 UTC

As nobody has responded to my susggestion regarding numeric precision that:

> What we end up with is a set of nested subsets of values:
> Number
> Complex number
> Real number
> Rational number
> Integer
>
> for which the following qualification properties:
> Min. precision/Max. precision
> (where precision is expressed in number of bytes of data
> required to hold minumum/maximum permitted value)
> Signed/Unsigned
> (whether or not the first bit of the first byte identifies its sign)
> Accurate/Approximate
> (whether or not a larger number of bytes should be used
> when calculating values, or whether rounding should be used
> to keep values within the precision bounds)

I thought I would try to be slightly more contorversial. It seems to be that
what we end up with is a single element with four facets, which can be
defined using old-fashioned DTDs as follows:

<!ELEMENT Number (#PCDATA)>
<!ATTLIST Number
       Type (Complex|Real|Rational|Integer) Integer
       Precision (16bit|32bit|64bit|unlimited) 32bit
       Signed (yes|no) yes
       Accurate (yes|no) no >

To allow users to map to their existing precision levels to just one element
wecould extend the precision options to include multiple variants of a name,
e.g.

(short|16bit|32bit|long|double|64bit|unlimited)

To allow users to map their existing types to just one element we could
extend the type opitions to include multiple variants of names, e.g.

(Complex|Real|Floating|Rational|Decimal|Fraction|Integer)

ISO 11404 also identifies a "scaled type", but I am not sure where this
would fit into a numeric hierarchy.

Do you feel that a single, faceted, base datatype for numeric data is a good
or a bad idea?

Martin Bryan

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)
Received on Mon Feb 10 18:01:10 2003

This archive was generated by hypermail 2.1.8 : Fri Dec 03 2004 - 14:00:27 UTC