[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Octave and GSOC'2008
From: |
John W. Eaton |
Subject: |
Re: Octave and GSOC'2008 |
Date: |
Thu, 28 Feb 2008 05:42:01 -0500 |
On 28-Feb-2008, Jaroslav Hajek wrote:
| That's exactly why I thought more about using just a special type for
| octave_value.
| For instance, a common construct is A'*B, where the value of A' is not needed
| anymore after the statement. Given that evaluating A'*B is typically
| even slightly
| faster than A*B, transposing and then multiplying is really a waste
| of time and memory.
|
| So I was thinking about
| DEFUN_DLD(times, ...
| )
|
| aA = args(0);
| if (aA.is_matrix_expr())
| {
| eA = aA.matrix_expr_value();
| switch (eA.expr_type())
| {
| case MatrixExpr::transpose:
| /* specialized code for transpose, possibly DGEMM('T'...) */
| case MatrixExpr::diag:
| /* just scale rows */
| }
| } else if (aA.is_matrix())
| {
| A = aA.matrix_value()
| ....
|
|
| Once matrix_value() gets called, the lazy expression is evaluated and
| substituted by the real thing. The problem is that matrix_value() now
| affects the object for which it is called - I can imagine that causing
| a lot of problems elsewhere...
If you want to handle something like A'*B as a special case, then I
think you just want to be looking at the parse tree and recognizing
the expression tree that matches the pattern for a transposed
expression times another expression, then calling a special function
to evaluate that. More generally, you might want to do some other
transformations, so having a general mechanism to do this rather than
doing it on an ad-hoc case-by-case basis would be better (and of
course, more work).
jwe
- Re: Octave and GSOC'2008, (continued)
- Re: Octave and GSOC'2008, John W. Eaton, 2008/02/26
- Re: Octave and GSOC'2008, Søren Hauberg, 2008/02/26
- Re: Octave and GSOC'2008, Jaroslav Hajek, 2008/02/28
- Re: Octave and GSOC'2008, John W. Eaton, 2008/02/28
- Re: Octave and GSOC'2008, Jaroslav Hajek, 2008/02/28
- Re: Octave and GSOC'2008,
John W. Eaton <=
- Re: Octave and GSOC'2008, Jaroslav Hajek, 2008/02/28
- Re: Octave and GSOC'2008, Jaroslav Hajek, 2008/02/28
- Re: Octave and GSOC'2008, John W. Eaton, 2008/02/28