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

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

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

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

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

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

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

+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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

> 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

[sage-devel] Re: Delete old optional packages

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

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

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

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

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

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

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

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

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

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

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] Deprecating Matrix.T, Matrix.I, etc. (was: Heavy-computation @property in Matrix class)

> 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

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

This has been a very interesting discussion... There are pros and cons to modularity, and it's worth noting that this can be done at various different levels. For example, where I work we have a single, monolithic codebase (very convenient) but at the same time have fairly strict, explicit