function protocol

[John P. Morgan]

This entire discussion seems to ignore the fact that the numbers labeled as 
"external" are simply internally generated values to which, by virtue of 
(supposedly) meeting our precision requirement, the "external" tag was attached, 
thus freezing them. The criticism that the internally generated order tags 
cannot necessarily be recreated applies just as well to these "external" values: 
there is no guarantee that any particular implementation can recreate them. 
Order tags would be deemed "external" and hence frozen just as the actual 
floating point values themselves are deemed "external" and hence frozen. They 
are all "DEPENDENT on hardware and on implementation." Any other interpretation 
is pure fiction (until such time as we ban all floating point calculations, or 
can guarantee a particular level of precision across all possible floating point 
calculations and all possible designs - given the complexity of some of the 
calculations, is this really possible? Please tell!).

I am not, by the way, pushing for order tags. As I said before, the idea smells 
none too sweet. Rather, I am pursuing this idea because it stresses a 
potentially worriesome problem that the other options ignore. There are very 
important concepts like "number of distinct eigenvalues" and "number of distinct 
pairwise variances" which will be reported by quasifunctions. If due to our set 
external rep precision we have collapsed to fewer distinct groupings than we 
KNOW exist (this knowledge coming either from highly precise floating point 
arithmetic or analytic expressions), then we are consciously creating fairly 
blatant falsehoods. This is unacceptable. Yes, we are up front in saying all our 
statements are true up to the required precision, but this is a clear case of 
"paradigm-induced falsehood." I do not want to risk saying, within the bounds of 
an agreed upon operational paradigm, that a 3-class PBIBD has 2 variances. 
Defining ourselves to be right may be the conventional approach, but it is not 
the high road in this case unless we can find no other option. 

At the least, when a precision-related grouping problem is known, a statement 
could be placed in the design's notes that the grouping may be too crude to 
reflect reality. Even this solution should be accompanied by some sort of tag in 
the quasifunction, alerting the user to check the notes. Actually I kind of like 
this idea. Let's call it option 8.

We do have a clear interest in not letting the external rep precision be too 
large. Whatever the answer to the grouping problem, it will be driven by the 
choice of external rep precision. Please, let's freeze THAT value so we can get 
on with this. 

Two other comments interwoven below.

JP



Peter D wrote:

>
>Peter D wrote:
>> >There are no separate "identical" images. The images must be distinct
>> >by definition in any <function_on...> structure.
>
>And I suggested that as part of our protocol since we could never have
>the true images in some cases. What we have is two different
>approximations: one internal one external. The internal is DEPENDENT on
>hardware and on implementation and such it is out of the scope of the
>definition of ext-rep. The external is in our control and that is why I
>suggested to be the basis when we are collapsing images.  Then we can
>require any application to guarantee precision up to this limit. How it
>achieves that it is internal matter.
>
>On Mon, Jul 14, 2003 at 03:23:40PM -0400, John P. Morgan wrote:
>> 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).
>
>Exactly!
>
>> 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.
>
>But the information used as a base for the tagging is application
>dependent.
>
>> 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
>
>No, the ordering tags are dependent on how one particular implementation
>on one particular hardware computes and sees its own internal
>representation. Another application (and/or other hardware, numerical
>library implementation etc) may see it differently. Which one is then
>the correct tag?

Ask the same question about the "external" value. Can you guarantee precision of 
ALL calculations across ALL designs? Please explain!
 
>
>I use "implementation" from now on, but I mean hardware, platform,
>numerical libraries, application, everything.
>
>> 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.
>
>But they cannot reconstruct the tagging process of the first application
>since they would need to know what was the internal precision in the
>first case. So you would need this information too in the tags.
>

Not reconstructable is true, but completely acceptable and intended. The order 
tag is nothing but a report that these values have been determined by their 
generator to be different at an UNSPECIFIED higher precision (which may in fact 
have been an analytic calculation - not all numeric knowledge is computer 
generated). This is at heart no different from saying that the generator 
determined the grouped values to be the same at the stated level of precision. 
Any user is free to investigate this with their own implementation, and then to 
agree or disagree. Like the note suggestion of option 8, it is a warning. Not 
clean, but the alternative is to take the cowardly approach of saying only 
"these are all the same at our level of precision" and leaving out additional 
known information that they differ at a higher level (plus perhaps asserting 
without 100% knowledge that the intended level of precision has actually been 
achieved). But again see the option 8 above.


>It might even happen that another application would want to split a
>preimage since it can calculate up to higher internal precision. How we
>decide which application to believe that is how to tag the images for
>the ext-rep to be stored.
>
>...
>> 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 tagging just shifted the problem from the external precision to the
>implementation dependent internal precision. I really cannot see any
>other "solution" than to stick to the ONE precision in the ext-rep.
>
>> >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.
>> >
>> >can also let the world know explicitly what is going on.
>
>So the "preserved natural order" here should be the one which can be
>obtained from the "real" function in the ext-rep at whatever precision
>we specify. Which leads me to suggesting one more attribute to quasi
>functions which would specify the uniform precision of approximation
>values for images used in the given function.
>
>--             ,
>    Peter Dobcsanyi
>
>_______________________________________________
>Developers mailing list
>Developers at designtheory.org
>http://designtheory.org/mailman/listinfo/developers