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