function protocol

[John P. Morgan]

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

The "true" images may well be distinct, but the approximated images not. 
The approximated images, which are what we would store and communicate, would 
conform to our precision requirement (say 8 decimal places). If the true images 
differ beyond that precision (in the 10th place, say) then we SHOULD see 
separate identical images if we are not to lose all of the information in the 
greater precision. We CAN see separate identical images if we tag them as such - 
they are then identical in (8-place percision) numeric value, but different by 
their tags, which would order them according to the underlying "true" image. If 
this idea is incorporated into the external rep, then all precision-conforming 
images will be so tagged at the time they are written into our format. 
Thereafter the ordering tags are present and are independent of any application, 
just as the 8-place precision images are themselves independent of any platform. 
The ordering tags warn users that, though identical at 8 places, the values 
differ at >8 places. Any user for whom greater precision was important could 
then use their own application to recreate the "true" values if they were so 
inclined. Of course there is always a limit to precision (which is why I am 
putting quotes on "true"), but we will be best served if the precision 
convention for the external rep is not so large (8 or even less), so that 
greater "true" precision is quite feasible. 

Effectively this suggestion is that image become a (value,ordertag) pair, in 
which case the pairs are never identical but the values can be. Now the problems 
and constraints described below no longer hold.

>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
>

Option 6 is now properly stated

     6 for all "quasi" functions order by <image>=<value,ordertag>
     
This is plenty of extra trouble. On the other hand, collapsing of image values 
at our required level of precision, without saying when values known to be 
different have been collapsed, is not at all attractive. Both alternatives have 
their uniquely unpleasant odors. Option 7 provides an "in between" route, 
avoiding the extra work of ordertags while warning the user that something is 
rotten in Denmark. Maybe its odor is not so strong? In my mind, three options 
are now open: 6, 1+7, 5+7.

JP