Re: generic * and 0

[Mikael Djurfeldt]

2006/12/6, Marius Vollmer <address@hidden>:
> Kevin Ryde <address@hidden> writes:
>
> > The only case I can think of where a common zero may not be good is
> > with matrices, where "(* 0 matrix) => matrix" could preserve the
> > dimensions of the input matrix in the output matrix.
>
> I would have to dig for the specifics (having forgotton most of my
> math by now), but 'scaling' matrices and 'multiplying' them are
> actually two different operations.

They certainly are different operations:
(C complex space, M space of matrices)

1. Scaling: C x M --> M
2. Matrix multiplikation: M x M --> M

> They are unfortunately notated the same.

That they are notated similarly on paper does not necessarily imply
that they should be notated the same way in computer code.

> (* scalar matrix) is scaling, and (* matrix matrix) is
> multiplying.  A special case of this is the more familiar vector
> scaling versus the vector dot product, I think.

It's actually a third operation:

3. Dot product: V x V --> C
(V space of vectors)

> Thus, it makes sense to me to let the 'unknown' object in a call to an
> arithmetic operation decide how to interpret it, and not doing any
> shortcuts.
>
> In general, it is not guaranteed that (* 0 something) is even
> well-defined, it might be an error.

Yes.

And I think you raise another important point: that one might want to
use the same generic function to represent different operators.

It is probably Right to make it possible for the primitive generic to
dispatch on all arguments (that is skipping the 0 and 1 trick which we
have inherited from the original SCM code).

However, doing this kind of "improvements" in an incremental manner,
given the current structure of the Guile evaluator, makes the thing
dog slow.  Also, if hanging methods on * implies performance penalty
for ordinary arithmetic, it leads to strange practise in structuring
code.

So I would vote "no" for just "fixing" this, and "yes" for a total
restructuring of invocation of primitive procedures so that they would
be true generic functions.