Incongruent hash

David N. Smith dnsmith at watson.ibm.com
Wed Feb 11 18:37:46 UTC 1998


Andreas:

How about consideingr Point to be a Smalltalk-ism and not related to a 2D
Vector, mainly because of the tradition of its definition. It really just
defines an x coordinate and a y coordinate, to which have been added
various methods which don't quite fit.

Then, maybe, there should be a Vector hierarchy which defines 2D and 3D
vectors and the mathematical operations on them. If 2D vectors supply
Point-compatible protocol for obtaining the x and y coordinates, then they
can be used in place of points in many situations and we can migrate to
them across time.

One thing that has always bugged me is the notation x at y. X is not AT y.
We'd need another notation for forming vectors and the only thing that
comes to mind offhand is -> which is as bad, but at least it looks like a
vector, sort of. Binary creation methods:

   2 -> 3
   2 -> 3 -> 4

Dave



At 10:33 -0500 2/11/98, Andreas Raab wrote:
>I actually didn't want to get into this discussion but I can't resist any
>longer...
>
>> But a point IS a location.
>
>No. What we usually call a "point" is actually an element of a
>2-dimensional vector space (i.e. a 2-dimensional vector). A vector space,
>however, is defined as an algebraic structure V(+,*,K) with K(+,*)
>being a field (for those who don't know: a field is another algebraic
>structure) and a couple of associated operations. In particular, the
>operation "*" needs to be defined  for all elements in K and V with a
>number of conditions such as associativity etc.
>
>_That_ is a point. The above definition means in particular that you can
>build vector spaces (i.e. _points_) over arbitrary algebraic structures
>not just numbers (during my math lectures we often used polynomal or
>function spaces).
>
>This opens two interesting questions: First, how closely should class
>Point resemble math definitions? I personally think that it should be as
>close as possible. The only well-known interpretation of a point is
>the mathematic one. To give an example it took me a couple of hours to
>find out that "0 at 0 + 1" yields "1 at 1" in VW. This operation is just not
>defined in mathematics - why should I assume that PPD (or whoever) thinks
>that they have to re-define mathematics in their own way? In my
>understanding, the addition of a point and an integer should result in an
>error. If I really need such an operation (although I don't see any
>reason for this), I can easily add the method Point>>sumToAllElements:
>or whatever I need there.
>
>I'm now getting back to the actual question of this thread. Can we compare
>two points? Yes we can, but there are several interpretations none of
>which has any natural math background. One can compare points such as it
>is done at the moment, although there is no much use for it besides _very_
>few graphics operation. I, for instance, don't see a big deal in rewriting
>Rectangle>>containsPoint: not to use "<" or ">". Then, there is the notion
>of length which could also be used for points. One could define "a < b"
>holds if "a length < b length". Although there isn't much practical use
>for it it _can_ be defined as such and that's the whole point I'm trying
>to make.
>
>Coming back to class Point, my feeling is that the relations "<" and ">"
>shouldn't be defined and that other operations such as "+" or "-" should
>be defined as maths does it. Only math gives you an intuitive meaning of
>the above operations and if these operations are not uniquely defined in
>maths they should not be defined in the class library. If, however, we
>need such methods (because of its signatures) then we should clearly
>state what happens (now tell me where I do find that "0 at 0 + 1 = 1 at 1" in
>VW).
>
>Andreas
>--
>Linear algebra is your friend - Trigonometry is your enemy.
>+===== Andreas Raab ============= (raab at isg.cs.uni-magdeburg.de) =====+
>I Department of Simulation and Graphics      Phone: +49 391 671 8065  I
>I University of Magdeburg, Germany           Fax:   +49 391 671 1164  I
>+=============< http://isgwww.cs.uni-magdeburg.de/~raab >=============+


_______________________________
David N. Smith
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author
and not of his employer.





More information about the Squeak-dev mailing list