function protocol

[Peter Dobcsanyi]

On Mon, Jul 14, 2003 at 01:12:55PM -0400, John P. Morgan wrote:
> The problem with decimal numbers ...
>  
> On Mon, Jul 14, 2003 at 05:48:14PM +0100, Peter Dobcsanyi wrote:
...
> >I suggest a protocol which is solely based on the ext-rep.  That is
> >the only way to make the ext-rep both platform and application
> >independent.  I realize that this is quite a burden on the Writer
> >implementations but see no other way around it.
> >
> >In any case, we should spell out our protocol in details regarding
> >the precision of decimal numbers.
> >
> 
> raises an interesting question. We do need to fix a precision, and
> then we may be occassionally faced with seemingly identical images at
> the fixed precision.  This suggest ordering by image in our
> quasifunctions, so that separate "identical" images are explicitly
> acknowledged as different and in the correct order.

There are no separate "identical" images. The images must be distinct by
definition in any <function_on...> structure.

The information in an ext-rep doc should not depend on internals of an
application and/or the platform the application is/was running on. The
ext-rep doc can carry information only about the designs. If some of
these cannot be expressed precisely (for example in decimal format)
then yes we use an approximation, by fixing some precision.

When a Writer produces a quasi function the contraction must be based on
the decimal representation of the images since this is the only
information a consumer application's Reader can see and reliably depend
on. (Sorry JP :-), I also have to do it this way, only Leonard is lucky
... for the time being)

The consumer can be a very different application running on different
hardware platform with different binary representation. For it, the
previous application's ``separate "identical" images`` has very likely
no meaning at all.

>     6 for all "quasi" functions order by <image>

So 6) does not solve this problem. Only the protocol taking the ext-rep
as the "absolute truth" even when it is just an approximation.
It is not against 6), just a fact.

On the other hand, I'd feel uncomfortable using fundamentally different
ordering for quasi functions.

There is yet another possibility (oh my ...), and this is:

    7 explicitly stating in an attribute of the quasi function that it
      has preserved the natural (before contraction) order or not.

Maybe it is not so bad idea after all: it would take care of special
cases, in particular when ext-rep is used in queries, but when the
application is able and want to preserve the order it can do so and can
also let the world know explicitly what is going on.

--             ,
    Peter Dobcsanyi