Re: New Public Review Issue

From: Asmus Freytag (
Date: Tue Aug 02 2005 - 23:45:38 CDT

  • Next message: Dominikus Scherkl: "RE: New Public Review Issue"

    At 08:21 PM 8/2/2005, David Starner wrote:
    >On 8/2/05, Jukka K. Korpela <> wrote:
    > > On Thu, 28 Jul 2005, Rick McGowan wrote:
    > >
    > > > 74 Change to Default Localization for NaN in CLDR
    > > >
    > > > There has been a request to change the default localization for a NaN
    > from
    > > > the character U+FFFD REPLACEMENT CHARACTER to another representation. The
    > > > NaN floating-point value means "Not a Number", and represents an
    > undefined
    > > > result of a mathematical operation.
    > >
    > > Maybe we can discuss this issue on this list preliminary, to avoid missing
    > > something obvious. I think the key question whether the value of NaN is a
    > > single character, as currently defined in the prose of the LDML
    > > specification:
    >The thing I personally pegged on is the use of U+FFFD. It's not an
    >error to print out a NaN, especially not at the character set level;
    >it seems like something, almost anything, that was actually text would
    >be better than U+FFFD.

    The requirement to have a single character represent NaN seems bogus to me.
    Currency symbols spring to mind. Many currencies have prospered using
    multi-character designators. In fact, the recent European move to a single
    character symbol was more of a public relations stunt than a technical

    I don't see that NaN is in need of similar marketing. ;-)

    Note that there is also not a requirement to have a single character that
    generically designates 'number'. The # is American in usage, the No sign
    implies ordinal, rather than cardinal number; in any event much more
    strongly than the # does.

    Some concepts cannot be expressed in a language neutral way, unless you use
    pictorial symbols. In other semantic areas we have held off from coding
    language neutral pictorial symbols. Me feedback is that we should not
    invent one here, merely for the sake of satisfying an internal requirement
    of a (admittedly valuable) database. Fix the database design.


    This archive was generated by hypermail 2.1.5 : Tue Aug 02 2005 - 23:46:44 CDT