ark@alice.UUCP (Andrew Koenig) (06/06/89)
Adding one pointer to another makes no sense because pointers represent a location rather than a displacement. As an analogy, consider a map. Locations are places, such as New York, Boston, etc. A displacement is the distance and direction one must travel to get from one location to another. One can express a displacement as the difference between two locations. So, for example, (Boston-New York) represents the distance and direction one must travel to get from New York to Boston. It makes sense to add two displacements. For example, (New York-Washington) + (Boston-New York) is pretty clearly equal to (Boston-Washington). It also makes sense to add a displacement and a location. For example, New York + (Boston-New York) is just Boston, and Washington + (Boston-New York) is where you'd be if you left Washington thinking you were in New York and headed for Boston -- someplace in the Atlantic south of Long Island. Where? I don't know, but if you were to add (New York-Washington) to that place it would put you in Boston. On the other hand, it does not make geometric sense to add two locations. What, for example, is New York + Boston? One could concoct a meaning that would be useful in some cases -- for example, although I don't know what New York+Boston is, I do know what (New York+Boston)/2 is -- it's the place half way between New York and Boston, somehwere around New Haven. However, I can express (New York+Boston)/2 as New York+(Boston-New York)/2 and thereby avoid worrying about what (New York+Boston) might mean. In fact, I can easily express the mean of any number of locations L1, L2, ... Ln. First I choose an arbitrary location. For convenience I'll pick L1. Then I convert each location to a displacement, so L1, ... Ln become L1-L1, L2-L1, ... Ln-L1. I average the displacements and then add back L1. So the average of L1, ... Ln is L1 + (L1-L1 + L2-L1 + ... + Ln-L1) / n The application of all this to C pointers is left as an exercise for the reader. -- --Andrew Koenig ark@europa.att.com
bengsig@oracle.nl (Bjorn Engsig) (06/07/89)
In article <9440@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >Adding one pointer to another makes no sense because pointers Oh nooooo! Not again :-( :-( -- Bjorn Engsig, ORACLE Europe \ / "Hofstadter's Law: It always takes Path: mcvax!orcenl!bengsig X longer than you expect, even if you Domain: bengsig@oracle.nl / \ take into account Hofstadter's Law"
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/08/89)
In article <9440@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >(New York-Washington) + (Boston-New York) is pretty >clearly equal to (Boston-Washington). If the distances are measured in a projection plane, then that's exact; by most measures of difference on the surface of the globe it's only approximate. (This doesn't affect the validity of your main point.) >On the other hand, it does not make geometric sense to add >two locations. What, for example, is New York + Boston? >One could concoct a meaning that would be useful in some cases -- >for example, although I don't know what New York+Boston is, >I do know what (New York+Boston)/2 is ... This touches on a topic near to my heart, i.e. the epistemological foundation for the use of tensors and similar mathematical constructs in formulating "universal laws" in theoretical physics. There are (in general multi-component) quantities sometimes called "holors" for which several laws of arithmetic are well defined, including (componentwise) addition and subtraction. However, not every mathematical expression involving (components of) holors representing (aspects of) physical objects itself constitutes (...) a holor representing (...) a physical object. Finding operations that satisfy this constraint is the main business of tensor analysis. To be more specific, it is often possible to construct a genuine "tensor" (i.e. a holor with absolute physical significance) out of non-tensor holors through certain specific arithmetic operations, although most such expressions would not be tensorial. For example, half the difference between the value of the fundamental displacement field and its transpose is a tensor (i.e. physically significant), even though the field itself embodies some degree of non-physical (i.e. conventionally-assigned) properties. This characteristic is similar to ARK's example of the average of several locations having meaning even though arbitrary sums of locations do not. The relevance to C standardization is that, even though one might be able to produce meaningful results by certain constrained combinations of arithmetic operations on pointers, the structure of the "phrase structure grammar" method of description is such that we cannot allow "meaningless" intermediate results on the way to producing a final meaningful value. If the necessity for broadening the class of allowed (meaningful) expressions to include (p+q)/2 is felt strongly enough, the only way it can be achieved is to radically alter the method currently used to specify the C grammar (along with constraints and semantics for arithmetic operations). A vague statement such as "Any meaningful operation is allowed" is useless until a tight specification of what is meant by "meaningful". We certainly couldn't countenance officially blessing genuinely meaningless operations without constraints, for a variety of fairly obvious reasons. I for one don't see that the need to average pointers is great enough to justify a complete reorganization of the specification for arithmetic operators.
roelof@idca.tds.PHILIPS.nl (R. Vuurboom) (06/08/89)
In article <10375@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > >This touches on a topic near to my heart, i.e. the epistemological >foundation for the use of tensors and similar mathematical constructs >in formulating "universal laws" in theoretical physics. There are > >I for one don't see that the need to average pointers is great >enough to justify a complete reorganization of the specification for >arithmetic operators. Not even if it strengthens the epistemological foundation of tensor theory? ;-) -- Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof