[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0 of 4] Implement basic sparse op diag and diag op sparse sup

From: Jason Riedy
Subject: Re: [PATCH 0 of 4] Implement basic sparse op diag and diag op sparse support.
Date: Thu, 12 Mar 2009 10:39:23 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux)

And Jaroslav Hajek writes:
> I have applied all Jason's changes to my test repository, fixed the
> diagonal * sparse problems, removed the checks for single-element
> diagonal matrices and made a few other adjustments (such as not
> introducing namespaces yet).

Thanks!  I'll check on it when I have a sensible network connection
tomorrow.  My work became hung up when I realized scalar double *
complex diagonal was becoming double sparse * complex diagonal when
performed explicitly, which is another reason why the single-element
checks should be avoided.

I became lost trying to add scalar double * complex diagonal[1].  ;)

At some point, the scalar->matrix constructors in liboctave should be
marked as explicit.  That may flush out some surprising things that just
happen to work...

> These changes do not yet modify the default conversion of diagonal
> matrices - that would be the most incompatible change, probably, and
> maybe should be further discussed.

I still need to revisit your comments on the permutation matrices.
Thanks for looking at all this!

With the basic sparse & diag (and sparse & permutation) ops, I don't see
why either diag or sparse should fall back to sparse.  And the
discussion of the "right" thing to do with diag .* sparse or sparse ./
diag definitely is future work; there are at least two "right" things,
depending on the use.


[1]  For one reason why that might be useful, consider
        1 * diag ([1 + I() * Inf, 1])
Converting the scalar 1 to a complex produces NaNs.  For further
examples and reasons, see
  W. Kahan and J.W. Thomas
  Augmenting a Programming Language with Complex Arithmetic
And yes, there's another whole discussion about Infs in complex
arithmetic that leads back to a compromise made in the 70s. ;)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]