[Bug 3250] definition of precisionDecimal

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3250





------- Comment #5 from davep@iit.edu  2007-04-03 19:06 -------
(In reply to comment #2)

> The other part of the problem, I think, is that defining the infinite value
> space doesn't aid our understanding of the semantics of the data type all that
> much. We need to understand something of the mechanisms used to restrict the
> value space, and of the operations that are applicable to the data type.

Well, specifying operations isn't something we pretend to do; we don't even say
you must have an addition on decimal, for example.  We leave that to users who
have their own semantics tied to the name of the datatype.  Mostly, we only
care about an order.

More to the point, however:  the precisionDecimal datatype captures aspect of
both "fixed precision" and "floating-point precision":  If you lock the
fraction-digit count to one value, you have a traditional fixed-point datatype;
putting a max on the total-digit count makes it finite.  If you put a max on
the total-digit count, you get a floating-point datatype; a max and min (not
the same) on fraction-digit count makes it finite.  (Locking the total-digit
count to a single value would produce the "normalized numbers for that max--754
terminology--but we haven't see any value in doing so.)  Were we working with
radix-2 digit counts, we could get the value spaces of float and double by
using appropriate limits (the only thing missing would be the rounding of
lexical representations to the nearest value in the value space).

Received on Tuesday, 3 April 2007 19:06:35 UTC