[vwnc] Question about coercion and the Magnitude hierarchy

On Dec 30, 2008, at 1:39 PM, Valloud, Andres wrote:

> Good question... the one defined for Point is not the only possible
> one... there's also the lexicographic order, which is also consistent.
> However, is it so useful to merit it being the default sort order?...


See Rectangle>>containsPoint:

I believe there are other graphics geometry operations that take  
advantage of this particular interpretation.

Doesn't necessarily answer how to judge its usefulness (I remember  
finding it as surprising as the next guy once upon a time), but  
perhaps an insight as to how it got put that way. This behavior is  
actually quite old in VisualWorks. I'm reasonably confident it dates  
back to at least ObjectWorks 4.0.

--
Travis Griggs
Objologist
"The best way to know you have a mind is to change it" -Judge Pierre  
Leval




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

It seems to me that point comparison got abused into providing shorthand
expressions for use by things like Rectangle>>containsPoint:.  With this
in mind, comparisons with numbers might have been a shorthand expression
to avoid writing 0@0 < aPoint or something of that nature.

Now I can't help but suspect the assumption that point comparison works
the current way is pervasive and permeates through code in subtle ways.
To some extent I think it would be nice if this wasn't the way it is,
and at the same time I have a feeling it will not change anytime soon
due to simple things like inertia.  Sigh...

Andres.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Travis Griggs
Sent: Tuesday, December 30, 2008 6:20 PM
To: vwnc NC
Subject: Re: [vwnc] Question about coercion and the Magnitude hierarchy


On Dec 30, 2008, at 1:39 PM, Valloud, Andres wrote:

> Good question... the one defined for Point is not the only possible
> one... there's also the lexicographic order, which is also consistent.
> However, is it so useful to merit it being the default sort order?...


See Rectangle>>containsPoint:

I believe there are other graphics geometry operations that take
advantage of this particular interpretation.

Doesn't necessarily answer how to judge its usefulness (I remember
finding it as surprising as the next guy once upon a time), but perhaps
an insight as to how it got put that way. This behavior is actually
quite old in VisualWorks. I'm reasonably confident it dates back to at
least ObjectWorks 4.0.

--
Travis Griggs
Objologist
"The best way to know you have a mind is to change it" -Judge Pierre
Leval




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

#< should not be defined on Point or on Complex.  They are not
magnitudes, even though they are subclasses of ArithmeticObject, which
is a subclass of Magnitude.  This is one of the places where multiple
inheriitance would come in handy.  Most subclasses of ArithmeticObject
are also Magnitudes, so it is convenient to make ArithmeticObject be a
subclass of Magnitude, but this should not fool anybody into thinking
that Complex is a Magnitude.  It isn't, and no amount of Smalltalk
programming will make it so.

In general, #< is only defined when the argument is the same species
as the receiver.  Dates and Characters are Magnitudes, but you
shouldn't compare them with numbers.  Scalars are the only kind of
Magnitudes for which automatic conversion makes sense.

I would like to disagree with Andres, who said that since so much code
assumes that #< is defined on Point then it is probably not possible
to fix this problem.  Here is how to fix it.

Make a refactoring that rewrites a send of #< to a Point, for example,
to convert "aPoint < anObject" to "aPoint x < anObject".
Define #< so that when you send it to a Point, it refactors the code.
This will fix non-polymorphic code, but it will not fix cases like
putting objects in a SortedCollection for display, and expecting
something reasonable to happen.  For those cases, you need a wrapper
for the Point that will let it be compared, and you have to change the
code to insert and remove wrappers when you insert and remove objects
from the SortedCollection.

I bet this can be almost entirely automated, assuming decent automated
tests.  It is not trivial, but it might make a nice MS project for
someone.  As part of a larger project, perhaps even part of a PhD.

Documentation needs to be changed to make it clear that #= must return
a boolean for any argument.  However, #< should not.  If the argument
is not comparable to the receiver, it should fail, preferably by
raising a standard exception.

-Ralph Johnson
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Valloud, Andres escreveu:
> Cesar,
>
> I do not understand what is it that you say is wrong.  How would you
> address this problem?
>
Andres,

The default response from a pristine image should be a DNU with a
comment or specific message that the user shall implement a specific
coercion for the realm is working with.

Point and Number are comparable per se so having any 'default' behaviour
that hides this will only arrive to some other developer find in the
future the code works 'funny' as the OP of this thread found for a
specific case.

--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi Ralph,

> #< should not be defined on Point or on Complex.  They are not
> magnitudes, even though they are subclasses of ArithmeticObject, which
> is a subclass of Magnitude.  This is one of the places where multiple
> inheritance would come in handy.

How about reversing the hierarchical order, where Magnitude is one of the
children of ArithmeticObject?
So, some arithmetic objects are magnitudes, and others are not.  I don't
believe it will be too disruptive.

Victor

===================================

----- Original Message -----
From: "Ralph Johnson" <[hidden email]>
To: "vwnc NC" <[hidden email]>
Sent: Wednesday, December 31, 2008 7:17 AM
Subject: Re: [vwnc] Question about coercion and the Magnitude hierarchy


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Wed, Dec 31, 2008 at 6:55 AM, Victor <[hidden email]> wrote:

> How about reversing the hierarchical order, where Magnitude is one of the
> children of ArithmeticObject?
> So, some arithmetic objects are magnitudes, and others are not.  I don't
> believe it will be too disruptive.

Then Date and Character will be arithmetic objects. It makes sense to
add an integer to a Date, but not to add two Dates, and it doesn't
make sense to add anything to a Character, even though it is legal in
C.

There is no perfect solution. Magnitude and ArithmeticObect are
independent concepts, except that a lot of classes are both.  I'm
happy leaving ArithmeticObject as a subclass of Magnitude as long as
everybody realizes it is just a hack to get around Smalltalk's lack of
multiple-inheritance, not a claim that ArithmeticObjects always are
Magnitudes.  (And I'd rather put up with this hack than complicate
Smalltalk with multiple-inheritance, but that is another topic.)

-Ralph
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Well, in that case, how about making them independent hierarchies with
delegation where's needed?
Or just a complete redesign where the responsibilities are differently
assigned?

Víctor

==================================

----- Original Message -----
From: "Ralph Johnson" <[hidden email]>
To: "vwnc NC" <[hidden email]>
Sent: Wednesday, December 31, 2008 8:33 AM
Subject: Re: [vwnc] Question about coercion and the Magnitude hierarchy


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Ralph Johnson escreveu: Ralph,

I would rather bring Traits to table than just complicate Smalltalk with
multiple inheritance...


--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I think the original issue centered around inconsistent behavior because the evaluation of methods through Magnitude did not coerce the two objects into some compatible form.  This happens automatically by primitive failure for the numeric operations;  what it seems we need is a generic structure that adds this elsewhere.

Following Victor's suggestion, perhaps this should be restructured something like this:

        Magnitude
                CoercibleValue
                        ArithmeticValue
                                Number
                                Point

Put the general coercion behavior (whatever that should look like) into the new CoercibleValue class, and convert the current numeric coercion behavior match the new model.  This should override standard magnitude behavior to make sure receiver and argument are comparison compatible.  The normal way this seems to be done is double-dispatching, so perhaps that approach should be followed.  Then, the point/number comparison problem goes away without any adverse effects on the remainder of the system - unless those parts of the system expected that weird original behavior.

You could also take the additional step that the immediate subclasses of CoercibleValue define coercion groups, and that coercion is not [directly] supported across groups.  That way you could have Date, Time, and Timestamp as another coercible group without interference from the arithmetics.

Cheers!
 
Tom Hawker
--------------------------
Senior Framework Developer
--------------------------
Home +1 (408) 274-4128
Office +1 (408) 576-6591
Mobile +1 (408) 835-3643
 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Victor
Sent: Wednesday, December 31, 2008 6:01 AM
To: Ralph Johnson; vwnc NC
Subject: Re: [vwnc] Question about coercion and the Magnitude hierarchy

Well, in that case, how about making them independent hierarchies with
delegation where's needed?
Or just a complete redesign where the responsibilities are differently
assigned?

Víctor

==================================

----- Original Message -----
From: "Ralph Johnson" <[hidden email]>
To: "vwnc NC" <[hidden email]>
Sent: Wednesday, December 31, 2008 8:33 AM
Subject: Re: [vwnc] Question about coercion and the Magnitude hierarchy


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not intended for you, please delete it immediately unread.  The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in doing so.  Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email.  Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Personally, I'd rather have (a moderate number of) "duplicate" methods
in two independent hierarchies rather than a hierarchy of things that
don't belong together.  Has this been explored?

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Ralph Johnson
Sent: Wednesday, December 31, 2008 5:33 AM
To: vwnc NC
Subject: Re: [vwnc] Question about coercion and the Magnitude hierarchy

On Wed, Dec 31, 2008 at 6:55 AM, Victor <[hidden email]> wrote:

> How about reversing the hierarchical order, where Magnitude is one of
> the children of ArithmeticObject?
> So, some arithmetic objects are magnitudes, and others are not.  I
> don't believe it will be too disruptive.

Then Date and Character will be arithmetic objects. It makes sense to
add an integer to a Date, but not to add two Dates, and it doesn't make
sense to add anything to a Character, even though it is legal in C.

There is no perfect solution. Magnitude and ArithmeticObect are
independent concepts, except that a lot of classes are both.  I'm happy
leaving ArithmeticObject as a subclass of Magnitude as long as everybody
realizes it is just a hack to get around Smalltalk's lack of
multiple-inheritance, not a claim that ArithmeticObjects always are
Magnitudes.  (And I'd rather put up with this hack than complicate
Smalltalk with multiple-inheritance, but that is another topic.)

-Ralph
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Andres

I tend to agree with you.

Furthermore, if we had Traits then you can have only one
defintion of a method but it can be used in multiple places.

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

+1

Cheers,
         Andrés

Valloud, Andres escribió: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

andres wrote:
Andres, I'm a late comer to the thread, but let me bring you a
perspective from machine vision applications in Smalltalk.

Even even if we work with pure points these two answer false:

(2 @ 2) < (2@3)
(2 @ 3) < (2 @ 2)

So does this:

0 < (0 @ 5)

Does that last case seem right? "Less then", says my math teacher, "is
defined as 'to the left on the number line".  On that definition
certainly the last case is implemented wrong.

So what does it mean to compare points? Some say it is meaningless, so
throw an exception.

But if we consider that any two points determine a line, and if less
than means "to the left of on the number line", then does it really
matter if the line vertical, horizontal, or diagonal?

On this thinking a common ordering function for points is Euclidian
distance to the origin. So if Point #< were revised to compute Euclidian
distance to the origin and compare distances, the two cases would work
just as you expected. So would the cases of sorting, min: and max:
elsewhere in the thread.   And it might not even break any legacy code.

-Alan Wostenberg
Key Technology


-----------------------------------------
Key Technology, Inc. Disclaimer Notice - The information and
attachment(s) contained in this communication are intended for the
addressee only, and may be confidential and/or legally privileged.
If you have received this communication in error, please contact
the sender immediately, and delete this communication from any
computer or network system. Any interception, review, printing,
copying, re-transmission, dissemination, or other use of, or taking
of any action upon this information by persons or entities other
than the intended recipient is strictly prohibited by law and may
subject them to criminal or civil liability. Key Technology,&nbsp;
Inc. is not liable for the improper and/or incomplete transmission
of the information contained in this communication or for any delay
in its receipt.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Ok, however note that the current implementation of point comparison is
an order relation just like comparison between numbers.  It may not be
intuitively so, but I did post a proof of that in the thread.  Hopefully
the proof is correct :).  Thus, it does make (some) sense (somehow).
Here the definition is "below and to the left, both at the same time".

Andres.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Alan Wostenberg
Sent: Monday, January 05, 2009 4:35 PM
To: andres
Cc: VWNC List
Subject: Re: [vwnc] Question about coercion and the Magnitude hierarchy

andres wrote:

> Hi list,
>            I was doing some test cases and I bumped into this
behavior: Andres, I'm a late comer to the thread, but let me bring you a
perspective from machine vision applications in Smalltalk.

Even even if we work with pure points these two answer false:

(2 @ 2) < (2@3)
(2 @ 3) < (2 @ 2)

So does this:

0 < (0 @ 5)

Does that last case seem right? "Less then", says my math teacher, "is
defined as 'to the left on the number line".  On that definition
certainly the last case is implemented wrong.

So what does it mean to compare points? Some say it is meaningless, so
throw an exception.

But if we consider that any two points determine a line, and if less
than means "to the left of on the number line", then does it really
matter if the line vertical, horizontal, or diagonal?

On this thinking a common ordering function for points is Euclidian
distance to the origin. So if Point #< were revised to compute Euclidian
distance to the origin and compare distances, the two cases would work
just as you expected. So would the cases of sorting, min: and max:
elsewhere in the thread.   And it might not even break any legacy code.

-Alan Wostenberg
Key Technology


-----------------------------------------
Key Technology, Inc. Disclaimer Notice - The information and
attachment(s) contained in this communication are intended for the
addressee only, and may be confidential and/or legally privileged.
If you have received this communication in error, please contact the
sender immediately, and delete this communication from any computer or
network system. Any interception, review, printing, copying,
re-transmission, dissemination, or other use of, or taking of any action
upon this information by persons or entities other than the intended
recipient is strictly prohibited by law and may subject them to criminal
or civil liability. Key Technology,&nbsp; Inc. is not liable for the
improper and/or incomplete transmission of the information contained in
this communication or for any delay in its receipt.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Alan Darlington escreveu:
> Another possible interpretation is "less is whichever point is closest
> to the origin (0@0)."  This would obviously require a lot more
> computation and would have to deal with the usual problems in comparing
> real numbers.  :-)
>
>     Cheers,
Alan,

Still is not enough because this vector interpretation of Point objects
bring into the discussion that is not possible to order vectors, consider:

4@0 and 0@4

which one is '"is closest to the origin"'?

--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Cesar Rabak wrote: It's also impossible to compare points unless they are in the same
space.. vectors are not in a space at all, so you really can't compare
them unless you *know* they're in the same space. This is a common
gotcha I've seen with people writing 3d code :) The Smalltalk class is
Point, not Vector, although I will say that some of the methods on Point
are indeed Vector operations. This part of the system is a wee bit hairy
to be honest... but it's a reasonable trade off IMHO.

Cheers,
Michael
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Victor escreveu:
> Clarity of intention is an important requirement in software development.
> At a certain point new vocabulary may be needed to be developed, like
> distanceFromOrigin
>
> 4@0 distanceFromOrigin = 0@4 distanceFromOrigin             "true, it's
> an absolute value"

This gets hairy because distance is a non negative quantity then you'll
have things like:

-3@-4 distanceFromOrigin = 5@0 distanceFromOrigin "true as well"

We get back to an earlier post where I pointed out that normally people
use as a Norm the Euclidean distance...


--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc