Re: [sage-devel] Deprecating Matrix.T, Matrix.I, etc. (was: Heavy-computation @property in Matrix class)

2016-04-27 Thread Jori Mäntysalo

On Wed, 27 Apr 2016, Johan S. R. Nielsen wrote:


I think that such magic is bad, for all the properties (transpose,
conjugate, conj-transp, inverse). It is not helpful to newcomers to Sage
to see that, apparently, *some* methods on objects don't require
parentheses, while almost everything else does -- such exceptions might
seem convenient the first 10 seconds, but afterwards it becomes
confusing.


+1 for this. No, at least +2.


New-comers to Sage often meet matrices as one of the first things. The
impression that leaves is important.


And one more +1 for this.

--
Jori Mäntysalo


[sage-devel] Deprecating Matrix.T, Matrix.I, etc. (was: Heavy-computation @property in Matrix class)

2016-04-27 Thread Johan S. R. Nielsen
Attempting to change the subject to focus on the suggestion to deprecate 
the properties.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Deprecating Matrix.T, Matrix.I, etc. (was: Heavy-computation @property in Matrix class)

2016-04-27 Thread Johan S . R . Nielsen
> I agree those things are a problem. I think I know why it was done:
>
> Transposition of a matrix is often written as M^T . It's difficult to
> support that syntax, so using M.T seems like a nice approximation. Once you
> have that, doing the same for conjugate and conjugate-transpose is a small
> step. And now that we have all these properties for order-two matrix
> operations, it's only natural to introduce one for inverses too.

That seems like a sensible explanation. 

> Given the ubiquity of tab-completion I agree that this is now probably a bad
> idea. I don't know if it's bad enough to break existing code, though.
> Perhaps deprecate their use? Even that has a cost.

I think that such magic is bad, for all the properties (transpose,
conjugate, conj-transp, inverse). It is not helpful to newcomers to Sage
to see that, apparently, *some* methods on objects don't require
parentheses, while almost everything else does -- such exceptions might
seem convenient the first 10 seconds, but afterwards it becomes
confusing.

New-comers to Sage often meet matrices as one of the first things. The
impression that leaves is important. In particular, they should
definitely not experience exceptions to Python conventions that arise
nowhere else in Sage.

In the interest of moving Sage to where it should be, as fast as
possible, I would vote for deprecating the behaviour. As you say,
deprecation - and in the end, removal - has a cost, but the greater goal
of having a coherent Sage is more important, I feel.

For the record, I would be OK with supporting abbreviations of the
methods (i.e. Matrix.T() == Matrix.transpose()). I don't know how/if
that could be implemented simultaneously with deprecating "Matrix.T".

Best,
Johan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.