[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: generic * and 0
From: |
Mikael Djurfeldt |
Subject: |
Re: generic * and 0 |
Date: |
Thu, 7 Dec 2006 16:28:28 +0100 |
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.
- Re: generic * and 0, (continued)
- Re: generic * and 0, Mikael Djurfeldt, 2006/12/01
- Re: generic * and 0, Kevin Ryde, 2006/12/01
- Re: generic * and 0, Kevin Ryde, 2006/12/03
- Re: generic * and 0, Mikael Djurfeldt, 2006/12/04
- Re: generic * and 0, Kevin Ryde, 2006/12/04
- Re: generic * and 0, SZAVAI Gyula, 2006/12/05
- Re: generic * and 0, Mikael Djurfeldt, 2006/12/05
- Re: generic * and 0, Ludovic Courtès, 2006/12/05
- Re: generic * and 0, Mikael Djurfeldt, 2006/12/05
- Re: generic * and 0, Marius Vollmer, 2006/12/06
- Re: generic * and 0,
Mikael Djurfeldt <=