stephane ducasse <ducasse at iam.unibe.ch> wrote:
	Certain methods often accept aPoint or a number but sign was not
	defined on Point reducing the polymorphism between number and points.

    sign
	"Answer a new point representing the sign of the point. 
	Answer 1 if the receiver is greater than 0, -1 if less than 0, else 0."

	^ self class x:  x sign y: y sign

I note that the comment disagrees with the code:
it does NOT answer 1, -1, or 0, ever.  

It is not clear to me what "the sign of the point" could actually mean.
The most natural interpretation, to me, would be the method currently
known as #normalized.

    sign
	"Answer a new point representing the same direction as this
         point, considered as a 2-vector, but with standard magnitude.
         Ensure that (pt theta) = (pt sign theta)."
	|r|
	r := self r.
	^r = 0 ifTrue: [self shallowCopy] ifFalse: [self / r]

It appears that Point>>abs regards a Point simply as a pair of numbers
without geometric significance, so I suppose having Point>>sign act
the same way is consistent: pt sign * pt abs = pt.

But it's regrettable that Point arithmetic is so ad hack.

Suggestion 1.  Change the comment in Ducasse's method to

    sign
	"Answer a new point whose coordinates are the signs of my coordinates.
	 Ensure that (pt sign * pt abs) = pt."

	^self class x: x sign y: y sign

Suggestion 2.  Fix #normalized; (0 at 0) normalized gets a division by zero.
At a minimum, make it explicit in the comment that it's not meant to "work".

    normalized
	"Answer a new point with the same direction (theta) as the
         receiver, but with unit magnitude (r).  NOT DEFINED for 0 at 0.
	 pt normalized theta = pt theta
	 pt normalized r = 1
	 pt normalized * pt r = pt
	 Code optimized for speed -- ar 8/26/2001"
	|r|
	r := ((x*x) + (y*y)) sqrt.
	^(x/r) @ (y/r)