As for MatrixError, this patch from the issues uses it 
(http://code.google.com/p/sympy/issues/attachmentText?id=2172&aid=7991076070956652516&name=matrices_diagonalize_and_jordan_form.patch&token=55c6ae6df62efdb67515a195c5c41e67#90),
 where it is raised when a matrix is not diagonalizable (a condition which is 
not entirely dependent on shape).   So I am definitely going to keep it.

Unless anyone has an opinion on NonSquareMatrixError vs. 
NonSquareMatrixException, I am going to use the first, since the cases where it 
is raised is generally an error (like calling .det() on a non-square matrix).

Aaron Meurer

On Feb 11, 2011, at 1:31 PM, Aaron S. Meurer wrote:

> 
> On Feb 10, 2011, at 10:42 AM, Vinzent Steinberg wrote:
> 
>> On 9 Feb., 05:22, "Aaron S. Meurer" <[email protected]> wrote:
>>> I am trying to create a branch that backports all of my non-Risch Algorithm 
>>> commits from my integration3 branch.  One 
>>> commit,https://github.com/asmeurer/sympy/commit/846af4a187800a97520d771dc9e1...,
>>>  which is related tohttp://code.google.com/p/sympy/issues/detail?id=1991, 
>>> changes the exceptions in the code of matrices.py a little bit.  I am not 
>>> so sure now what the best way to have things is, though.  
>>> 
>>> Currently, there is a MatrixError exception, which is only used in one 
>>> place in matrices.py, and there I believe ShapeError should be used 
>>> instead.  All over the code there is "assert self.cols == self.rows".  I 
>>> have replaced all of these with NonSquareMatrixError, which I for some 
>>> reason have renamed NonSquareMatrixException to.  So my questions are:
>>> 
>>> 1. Should we have MatrixError, and if so, how should it be structured?
>>> 
>>> 2. Should it be called NonSquareMatrixError or NonSquareMatrixException?  
>>> It is raised in those cases where only a square matrix makes sense but a 
>>> non-square matrix was given (like Matrix.det()).
>>> 
>>> The current structure of the exceptions is
>>> 
>>> class NonSquareMatrixException(Exception):
>>>    pass
>>> 
>>> class ShapeError(ValueError):
>>>    """Wrong matrix shape"""
>>>    pass
>>> 
>>> class MatrixError(Exception):
>>>    pass
>>> 
>>> but I think it should be more like
>>> 
>>> class MatrixError(Exception):
>>>    """
>>>    If this is never raised directly, is it needed?
>>>    """
>>>    pass
>>> 
>>> class ShapeError(ValueError, MatrixError):
>>>    """Wrong matrix shape"""
>>>    pass
>>> 
>>> class NonSquareMatrixException(ShapeError):
>>>    pass
>> 
>> 
>> I would drop NonSquareMatrixException() completely, in my opinion this
>> is overkill. Maybe just replace it with something like
>> 
>>   raise ShapeError('square matrix expected, got %i x %i matrix')
> 
> But about half of all instances of ShapeError are because the matrix needed 
> to be square.  See the commit I referenced above.  I count thirteen instance 
> of ShapeError and ten instances of NonSqauareMatrixError (and actually, I see 
> that one of the ShapeErrors should really be a NonsquareMatrixError, so make 
> that twelve and eleven).  ShapeError occurs with things like matrix 
> multiplication which requires certain shape requirements to be met, as well 
> as things like .norm and .dot, which require vectors.  NonSquareMatrixError 
> is for all the matrix operations that require square matrices: .det(), inv(), 
> .trace(), various decompositions, etc.  So I personally think it can be 
> advantageous to have a separate 
> NonSquareMatrixError/NonSquareMatrixException.  Anyway, it derives from 
> ShapeError, so anything that catches ShapeError will also catch it too.  
> 
>> 
>> MatrixError() makes sense when you want to catch matrix-related errors
>> only and ShapeError() is to specific.
>> 
>> But I wonder, in which case a "MatrixError" is not a "ShapeError"? If
>> there is none, MatrixError should be dropped too.
>> 
>> 
>> Vinzent
> 
> No there isn't. That's why I was wondering about it, and I believe why I 
> originally removed it in that commit.  Do you know if in the future there 
> might be errors other than ShapeError that would derive from MatrixError?  Or 
> does it make sense from an object oriented point of view to have a 
> MatrixError base class even if it is derived only once at the moment (I am 
> really no good with OOP stuff, so I don't know)?
> 
> Aaron Meurer
> 

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Reply via email to