[sage-devel] Re: Heavy-computation @property in Matrix class

[Simon King]

Hi Johan,

On 2016-04-27, Johan S  R  Nielsen  wrote:
>> - I am -1 to deprecate properties in general (here I include lazy
>>   attributes, which I find handy).
>
> Can you give me an example of a handy lazy attribute, to make it
> concrete for me?

Basically you spare the calling overhead, which in some applications has
made a difference.

OTOH, in all these cases that I can recall, one could argue that the
properties in question were *not* really part of the API, and were
still accessible through methods.

So, let me refrase:
- I am -1 to deprecate properties in general --- but properties shouldn't
  be considered part of the API. And I guess that means throwing exceptions
  and running long computations is fine, because tab-completion should only
  show what's part of the API, isn't it?

Best regards,
Simon


-- 
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] Re: Heavy-computation @property in Matrix class

[Marc Mezzarobba]

Johan S. R. Nielsen wrote:
> 1) This is a property that can throw an exception. Isn't that a
> problem?
> 
> 2) This is a property that runs a heavy computation when called. Isn't
> that a problem?

My two cents: both are problems, and matrix.I is problematic for this
reason. However, things like matrix.T that don't have these problems(?)
are fine with me (though I think ideally matrix.T should return a
*view* on the transpose). A lazy variant of matrix.I that wouldn't
compute the inverse right away would be okay too.

-- 
Marc

-- 
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.

Re: [sage-devel] Let's talk specifics (was Re: how we develop sage)

[William Stein]

On Wed, Apr 27, 2016 at 7:09 AM, Kwankyu Lee  wrote:
> This discussion is hardening the terms: Sage core and external packages. But
> from the point of view of the people developing the would-be external
> packages, the official term would better be
>
> Sage extension,
> Sage library extension,
> Sage library extension package,
> or SLEP.
>
> Or simply extension package.

Or

 Python package (that depends on Sage)

>
>
> --
> 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.



-- 
William (http://wstein.org)

-- 
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.

Re: [sage-devel] Re: Heavy-computation @property in Matrix class

[Bruno Grenet]

+1 to everything Johan is writing. I think that the example B.I.roo 
that hangs forever (or almost) is particularly striking.


As an aside, I agree that deprecation has a cost, and this observation 
shows up in several discussions these days on sage-devel. For general 
changes, like deprecate the use of properties for the end user, or 
change the way packages can be installed, etc., we may take the 
opportunity of the future switch from Python 2 to Python 3 to implement 
them. Thus we could then advertise that from version 10.0 (say), the 
interface of Sage changes (in a backward incompatible manner, due in 
particular to Py2>Py3). If this comes together with a clear document, 
easily found on sagemath.org, etc. that explains all the changes, it 
would minimize the pain caused to the users.


Bruno




Le 27/04/2016 14:24, Johan S. R. Nielsen a écrit :

VulK writes:

sage: B = matrix()
sage: B.T.roo

and get

sage: B.T.rook_vector

I see, didn't know that.

Of course, the reason that IDEs follow this is the underlying convention
that

a) Properties are blazingly fast to compute.
b) Properties don't throw exceptions.

Neither of which are satisfied for Matrix.I. If B is a 1000x1000
matrix over ZZ(x), then B.I.roo is going to hang your IDE for a
while :-)

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.

Re: [sage-devel] Let's talk specifics (was Re: how we develop sage)

[Kwankyu Lee]

This discussion is hardening the terms: Sage core and external packages. 
But from the point of view of the people developing the would-be external 
packages, the official term would better be 

Sage extension,
Sage library extension,
Sage library extension package,
or SLEP.

Or simply extension package. 


-- 
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.

Re: [sage-devel] Re: Delete old optional packages

[Dima Pasechnik]

On Wednesday, April 27, 2016 at 1:53:27 PM UTC+1, tdumont wrote:
>
> Le 27/04/2016 12:34, mmarco a écrit : 
> > Several of the maintainers answered me telling that it is OK to remove 
> > those packages. The rest of them either couldn't be contacted or did not 
> > answer at all. So it is safe to delete the packages. 
> > 
> > El miércoles, 20 de abril de 2016, 11:19:29 (UTC+2), mmarco escribió: 
> > 
> > In theory, each od these packages should have a mantainer. I think 
> > we should, at least, consult them before removing the packages. 
> > 
> > If a package has no mantainer at all... that is already a good 
> > reason to remove it from the list of optional packages. 
> > 
> > El miércoles, 20 de abril de 2016, 9:24:01 (UTC+2), Volker Braun 
> > escribió: 
> > 
> > Since we once again had a thread about the pains of accidentally 
> > installing an old-style optional package, I propose to delete 
> > them except the following instead of opening a trac ticket for 
> > each one once something bad happened. If there is anything else 
> > you want to hit reply... 
> > 
> > See the list here: http://files.sagemath.org/spkg/optional/ 
> >  >
>  
>
> > 
> > To keep: 
> > 
> > - chomp 
> > - java3d 
> > - phc 
> > - qhull 
> > - kash3 
> > 
>
> Mhhh, I have colleagues who use "lie". 
>

Lie is a new style package. 
See http://files.sagemath.org/spkg/upstream/lie/index.html
What will be removed is just an old spkg file...



> An other package: coxeter. It was written by a colleague and friend of 
> mine, Fokko Ducloux, who passed away now 10  years ago. If I remember 
> well, people from the Sage-Combinat group wanted to work on it. What is 
> the situation ? 
>
> yours 
> t. 
> > -- 
> > 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+...@googlegroups.com  
> > . 
> > To post to this group, send email to sage-...@googlegroups.com 
>  
> > . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
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.

Re: [sage-devel] Re: Delete old optional packages

[Travis Scrimshaw]

> Mhhh, I have colleagues who use "lie". 
>

It has been converted to a new-style skpg, but is experimental because it 
needs an overhaul on its build system. It is on my todo list, but 
unfortunately not very high. Also I need to learn how to work with 
autotools (not just use the final product). Any help here would be 
appreciated.

>
> An other package: coxeter. It was written by a colleague and friend of 
> mine, Fokko Ducloux, who passed away now 10  years ago. If I remember 
> well, people from the Sage-Combinat group wanted to work on it. What is 
> the situation ? 
>
> That would be me in particular. I've created a github page for it: 
https://github.com/tscrim/coxeter. Again, I haven't had time to really work 
on it. I've started to write a test suite for it (most importantly, doing 
the timings) and cleaning up the code, but more work is needed. Help is 
welcomed.

Best,
Travis

 

-- 
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.

Re: [sage-devel] Re: Heavy-computation @property in Matrix class

[VulK]

An interested question: my example from before was not extremely far fetched:
I am working precisely on something of that sort. A is a Cluster algebra, S
are its seeds and current_seed is a pointer to the current seed. Would it be ok
for future  sage integration if I were to implement A.current_seed as a 
property or
should I stick to methods?
Thanks
S.


* Johan S. R. Nielsen  [2016-04-27 14:24:33]:

> VulK writes:
> > sage: B = matrix()
> > sage: B.T.roo
> >
> > and get
> >
> > sage: B.T.rook_vector
> 
> I see, didn't know that.
> 
> Of course, the reason that IDEs follow this is the underlying convention
> that
> 
> a) Properties are blazingly fast to compute.
> b) Properties don't throw exceptions.
> 
> Neither of which are satisfied for Matrix.I. If B is a 1000x1000
> matrix over ZZ(x), then B.I.roo is going to hang your IDE for a
> while :-)
> 
> 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.

-- 
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.

Re: [sage-devel] Re: Delete old optional packages

[Thierry Dumont]

Le 27/04/2016 12:34, mmarco a écrit :

Several of the maintainers answered me telling that it is OK to remove
those packages. The rest of them either couldn't be contacted or did not
answer at all. So it is safe to delete the packages.

El miércoles, 20 de abril de 2016, 11:19:29 (UTC+2), mmarco escribió:

In theory, each od these packages should have a mantainer. I think
we should, at least, consult them before removing the packages.

If a package has no mantainer at all... that is already a good
reason to remove it from the list of optional packages.

El miércoles, 20 de abril de 2016, 9:24:01 (UTC+2), Volker Braun
escribió:

Since we once again had a thread about the pains of accidentally
installing an old-style optional package, I propose to delete
them except the following instead of opening a trac ticket for
each one once something bad happened. If there is anything else
you want to hit reply...

See the list here: http://files.sagemath.org/spkg/optional/


To keep:

- chomp
- java3d
- phc
- qhull
- kash3



Mhhh, I have colleagues who use "lie".

An other package: coxeter. It was written by a colleague and friend of 
mine, Fokko Ducloux, who passed away now 10  years ago. If I remember 
well, people from the Sage-Combinat group wanted to work on it. What is 
the situation ?


yours
t.

--
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.


--
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] Re: Heavy-computation @property in Matrix class

[Johan S . R . Nielsen]

VulK writes:
> sage: B = matrix()
> sage: B.T.roo
>
> and get
>
> sage: B.T.rook_vector

I see, didn't know that.

Of course, the reason that IDEs follow this is the underlying convention
that

a) Properties are blazingly fast to compute.
b) Properties don't throw exceptions.

Neither of which are satisfied for Matrix.I. If B is a 1000x1000
matrix over ZZ(x), then B.I.roo is going to hang your IDE for a
while :-)

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.

Re: [sage-devel] Re: Heavy-computation @property in Matrix class

[VulK]

This example is dumb because it does not give any real benefit but it will
do. On the command line you could run something like

sage: B = matrix()
sage: B.T.roo

and get

sage: B.T.rook_vector

but 

sage: sage: B.transpose().roo

will complete to useless stuff.

Now as I said this does not make a lot of sense with matrices. On the other
hand suppose you have a mathematical structure A endowed with building blocks
S and a pointer to the current block. Suppose also that each building block
has some method defined. Then properties allow to autocomplete things like

sage: A.current_S.some_method()

The same example does not work if A.current_S is a method itself and not a 
property.

By this I do not imply that properties should be preserved in sage. I am only
answering your question on which benefit is there in omitting the
parenthesis.

Best
S.



* Johan S. R. Nielsen  [2016-04-27 13:46:08]:

> > One advantage of properties over methods is that they autocomplete
> 
> I don't understand? Tab-completion covers both methods and properties in
> all IDEs I'm aware of.
> 
> 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.

-- 
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] Re: Heavy-computation @property in Matrix class

[Johan S . R . Nielsen]

> One advantage of properties over methods is that they autocomplete

I don't understand? Tab-completion covers both methods and properties in
all IDEs I'm aware of.

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.

Re: [sage-devel] Re: Heavy-computation @property in Matrix class

[VulK]

One advantage of properties over methods is that they autocomplete
S.

* Johan S. R. Nielsen  [2016-04-27 13:22:57]:

> > Would it be feasible to let properties return some kind of "Undefined"
> > or "NotImplemented" or "None", rather than throwing an exception?
> 
> That would side-step the entire purpose of exceptions: catching errors
> fast and where they occur. This is extremely bad for debugging, and yet
> another source of inconsistency that we should definitely not be
> teaching our prospective Sagesters.
> 
> And the benefit of this sidestepping is to omit an empty pair of
> parentheses?
> 
> > - I am -1 to deprecate properties in general (here I include lazy
> >   attributes, which I find handy).
> 
> Can you give me an example of a handy lazy attribute, to make it
> concrete for me?
> 
> Essentially, I find the use of properties to go directly against a
> general pattern in Sage (and OOP): that private fields are only
> accessible through methods. For instance, there is no Matrix.nrows --
> there is Matrix.nrows(). Why is this not a property? Consistency! In
> sage.coding, we also recently refactored everything so that length,
> dimension, etc. of a code is private fields, publicly accessible through
> method calls. Everywhere I look in Sage, we have methods, not
> properties. Why should these four examples in Matrix be so special?
> 
> 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.

-- 
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] Re: Heavy-computation @property in Matrix class

[Johan S . R . Nielsen]

> Would it be feasible to let properties return some kind of "Undefined"
> or "NotImplemented" or "None", rather than throwing an exception?

That would side-step the entire purpose of exceptions: catching errors
fast and where they occur. This is extremely bad for debugging, and yet
another source of inconsistency that we should definitely not be
teaching our prospective Sagesters.

And the benefit of this sidestepping is to omit an empty pair of
parentheses?

> - I am -1 to deprecate properties in general (here I include lazy
>   attributes, which I find handy).

Can you give me an example of a handy lazy attribute, to make it
concrete for me?

Essentially, I find the use of properties to go directly against a
general pattern in Sage (and OOP): that private fields are only
accessible through methods. For instance, there is no Matrix.nrows --
there is Matrix.nrows(). Why is this not a property? Consistency! In
sage.coding, we also recently refactored everything so that length,
dimension, etc. of a code is private fields, publicly accessible through
method calls. Everywhere I look in Sage, we have methods, not
properties. Why should these four examples in Matrix be so special?

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.

[sage-devel] Re: Delete old optional packages

[mmarco]

Several of the maintainers answered me telling that it is OK to remove 
those packages. The rest of them either couldn't be contacted or did not 
answer at all. So it is safe to delete the packages.

El miércoles, 20 de abril de 2016, 11:19:29 (UTC+2), mmarco escribió:
>
> In theory, each od these packages should have a mantainer. I think we 
> should, at least, consult them before removing the packages. 
>
> If a package has no mantainer at all... that is already a good reason to 
> remove it from the list of optional packages.
>
> El miércoles, 20 de abril de 2016, 9:24:01 (UTC+2), Volker Braun escribió:
>>
>> Since we once again had a thread about the pains of accidentally 
>> installing an old-style optional package, I propose to delete them except 
>> the following instead of opening a trac ticket for each one once something 
>> bad happened. If there is anything else you want to hit reply...
>>
>> See the list here: http://files.sagemath.org/spkg/optional/
>>
>> To keep:
>>
>> - chomp
>> - java3d
>> - phc
>> - qhull
>> - kash3
>>
>

-- 
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] Re: Heavy-computation @property in Matrix class

[Simon King]

On 2016-04-27, Johan S  R  Nielsen  wrote:
> From that point of view, I would agree that there should be a *method*
> "Matrix.T()". Leaving out the parentheses by making T a property is a
> micro-optimisation which is bad for consistency reasons. The fact that
> Matrix.I throws an exception in the general case is even worse.

Would it be feasible to let properties return some kind of "Undefined"
or "NotImplemented" or "None", rather than throwing an exception?

But generally,
- I am -1 to deprecate properties in general (here I include lazy
  attributes, which I find handy).
- I am +1 to introduce the policy that properties should never throw
  exceptions (and thus to deprecate all properties that currently do
  throw exceptions).

Best regards,
Simon

-- 
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.

Re: [sage-devel] Re: Heavy-computation @property in Matrix class

[Johan S . R . Nielsen]

> well, deprecating ".T", etc, just because it breaks an emacs mode, looks like
> a huge overkill, especially from the vim camp :-\)

Ah, you misunderstand me. I'm not arguing against the sugar due to the
Emacs mode - I'm arguing against the sugar because it's Bad For
Consistency.

> Besides, ".T" is bog-standard all over the numerical world. Removing nice
> syntactic sugar should not be done so easily.

>From that point of view, I would agree that there should be a *method*
"Matrix.T()". Leaving out the parentheses by making T a property is a
micro-optimisation which is bad for consistency reasons. The fact that
Matrix.I throws an exception in the general case is even worse.

There was a discussion on sage-devel a while back involving properties,
and multiple people posited that it was sick to make a property that
often throws exceptions...

> I don't quite understand the problem however. Are you saying that emacs mode
> triggers an attempt to actually compute ".T", etc, when you do
> tab completion?

The Emacs mode was simply how I stumbled across the issue, because it --
incidentally -- *does* currently break tab-completion. Exactly why this
happens is not clear to me, but apparently pressing m. in
ipython-mode will call all properties on m; if one of those throw an
exception, the method poll is cancelled and the lisp code determines
that m has no methods at all. m.I throws an exception if m is singular.

This is clearly a problem with ipython-mode! But as I said: I'm not
against the properties on Matrix due to that Emacs mode but because it's
inconsistent, and hence confusing, syntactic sugar.

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.

[sage-devel] Re: Heavy-computation @property in Matrix class

[Dima Pasechnik]

On Tuesday, April 26, 2016 at 9:53:41 AM UTC+1, Johan S. R. Nielsen wrote:
>
> Hi 
>
> I came across the following in sage/matrix/matrix2.pyx:14367: 
>
> @property 
> def I(self): 
> r""" 
> Returns the inverse of the matrix, if it exists. 
>  
> """ 
> return ~self 
>
> Basically, I don't understand why this def should be a property, and it 
> seems to me to be problematic. Specifically: 
>
> 1) This is a property that can throw an exception. Isn't that a problem? 
>
> 2) This is a property that runs a heavy computation when called. Isn't 
> that a problem? 
>
> I came across this because it currently breaks tab-completion on 
> matrices in the Emacs sage-mode: perhaps due to a bug, IPython inspects 
> the properties when tab-completing, so when a property throws an 
> exception, no tab-completion is given. That means that invertible 
> matrices don't tab-complete in sage-mode. The terminal is OK, and I 
> don't know about other interfaces. 
>
> There are other @property defs in that class, like conjugate and 
> hermitian. 
>

well, deprecating ".T", etc, just because it breaks an emacs mode, looks 
like a huge overkill, especially from the vim camp :-)

Besides, ".T" is bog-standard all over the numerical world. Removing nice 
syntactic sugar should not be done so easily. 

I don't quite understand the problem however. Are you saying that emacs 
mode triggers an attempt to actually compute ".T", etc, when you do
tab completion?


 

>
> 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.

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

[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)

[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)

[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.