Ready for review - I've ended up rewriting quite a bit in echelon_form
On Saturday, 1 August 2015 02:50:01 UTC-6, Volker Braun wrote:
>
> The principle of least surprise would suggest that mutability should
> follow the same rules independent of the matrix size. And echelon_form
> should always
The principle of least surprise would suggest that mutability should follow
the same rules independent of the matrix size. And echelon_form should
always return an immutable matrix.
On Saturday, August 1, 2015 at 1:51:12 AM UTC+2, Andrey Novoseltsev wrote:
>
> Hello,
>
> While working on http
On Monday, October 7, 2013 11:35:47 AM UTC-7, Volker Braun wrote:
>
> I think you are missing the point that it is supposed to be a mixin class.
>
Ah, right. Perhaps it could be used like that, and it looks like it was
before pyrexification. Presently it's just not used at all, and its last
use w
I think you are missing the point that it is supposed to be a mixin class.
Of course that is not possible in matrices, which brings me to the second
point: The matrix classes are a completely atypical example in Sage.
Matrices are much more optimized than what would be appropriate in the rest
o
On Monday, October 7, 2013 9:40:20 AM UTC-7, Volker Braun wrote:
>
> On Monday, October 7, 2013 5:05:52 PM UTC+1, Nils Bruin wrote:
>>
>> I think this holds uniformly, i.e., the class can go, being an
>> inappropriate abstraction. I think in all cases a simple boolean (both in
>> cython and in
On Monday, October 7, 2013 5:05:52 PM UTC+1, Nils Bruin wrote:
>
> I think this holds uniformly, i.e., the class can go, being an
> inappropriate abstraction. I think in all cases a simple boolean (both in
> cython and in python code) will do better.
>
I don't think the Python attribute is going
See:
http://trac.sagemath.org/ticket/13949
It's not just a technical issue: matrices used to have a 'mutability'
instance stored on an attribute, to encode a simple boolean. That increases
memory footprint and reduces performance significantly. Just storing the
boolean straight away should be
sage.structure.mutability was added very recently, so there isn't anything
yet that uses it afaik. Feel free to be the first ;-)
On Monday, October 7, 2013 3:57:40 PM UTC+1, Daniel Krenn wrote:
>
> mutability.pyx:45 self._is_immutable = 1
> sequence.py: self._is_immutable = True
>
T
Hi!
FWIW: I created decorators @require_mutable and @require_immutable at
#14524, which needs review.
Note that the patch does not *use* the two decorators. Using them for, say,
graphs shall be a second ticket.
Best regards,
Simon
Am Donnerstag, 2. Mai 2013 16:47:10 UTC+2 schrieb Travis Scrim
Hi Nils,
On 2013-05-02, Nils Bruin wrote:
> Having the decorators is not particularly damaging. I wouldn't like
> the overhead, but getting rid of them in favour of more efficient
> solutions is an easy transformation.
It is perhaps similar to the situation with @cached_method: It used to
have a
On 2 May 2013 20:11, kcrisman wrote:
>
>
> On Thursday, May 2, 2013 3:11:26 PM UTC-4, kcrisman wrote:
>>
>>
>>> Or perhaps you were just quoting Monty Python after all and I should
>>> myself ire domum.
>>>
>>
>> Yes, I think so.
>
>
> Sorry, that sounded rude - I meant "yes" to the Monty Python,
On Thursday, May 2, 2013 3:11:26 PM UTC-4, kcrisman wrote:
>
>
> Or perhaps you were just quoting Monty Python after all and I should
>> myself ire domum.
>>
>>
> Yes, I think so.
>
Sorry, that sounded rude - I meant "yes" to the Monty Python, not the ire
domum.
--
You received this messag
> Or perhaps you were just quoting Monty Python after all and I should
> myself ire domum.
>
>
Yes, I think so.
--
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
On 2 May 2013 19:41, leif wrote:
> Volker Braun:
>
>> On Thursday, May 2, 2013 6:42:48 PM UTC+1, Nils Bruin wrote:
>>
>> Furthermore, to express a requirement the optative
>> subjunctive mood is probably more appropriate than a future tense.
>>
>>
>> ROMANES EUNT DOMUS
Well it is 41 yea
Volker Braun:
On Thursday, May 2, 2013 6:42:48 PM UTC+1, Nils Bruin wrote:
Furthermore, to express a requirement the optative
subjunctive mood is probably more appropriate than a future tense.
ROMANES EUNT DOMUS
A thousand times, please!
-leif
--
() The ASCII Ribbon Campaign
/\
On Thursday, May 2, 2013 2:06:12 PM UTC-4, Volker Braun wrote:
>
> On Thursday, May 2, 2013 6:42:48 PM UTC+1, Nils Bruin wrote:
>
>> Furthermore, to express a requirement the optative
>> subjunctive mood is probably more appropriate than a future tense.
>
>
> ROMANES EUNT DOMUS
>
>
Ils sont fou
On Thursday, May 2, 2013 6:42:48 PM UTC+1, Nils Bruin wrote:
> Furthermore, to express a requirement the optative
> subjunctive mood is probably more appropriate than a future tense.
ROMANES EUNT DOMUS
--
You received this message because you are subscribed to the Google Groups
"sage-devel
On May 2, 8:32 am, Simon King wrote:
> What do people think?
> [ ] @invariant and @mutabor is fine
Having the decorators is not particularly damaging. I wouldn't like
the overhead, but getting rid of them in favour of more efficient
solutions is an easy transformation.
"invariant" has the wrong
>
> No Latin, definitely not :-)
>
> @require_mutable / @require_immutable
>
+1
--Mike
--
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...@goo
On Thursday, May 2, 2013 4:32:06 PM UTC+1, Simon King wrote:
> I suggest the name "@invariant" for the first and
> "@mutabor" (this is Latin for "I will be changed") for the second
> decorator.
>
No Latin, definitely not :-)
@require_mutable / @require_immutable
--
You received this messag
Hi Travis,
On 2013-05-02, Travis Scrimshaw wrote:
>I don't think so... This would be useful for other mutable things such
> as matrices and simplicial complex rather than explicitly check it in the
> methods themselves.
OK. Thanks to sage.misc.decorators.sage_wraps, it will be easy to
crea
Hey Simon,
I don't think so... This would be useful for other mutable things such
as matrices and simplicial complex rather than explicitly check it in the
methods themselves.
Best,
Travis
On Thursday, May 2, 2013 9:38:06 AM UTC-4, Simon King wrote:
>
> Hi!
>
> Is there a decorator that wr
On Jan 1, 10:36 pm, William Stein wrote:
> See below for how it could wreak havoc:
Yes, since the echelon form gets cached. There could be others (over
other rings), I just haven't checked. But doing a quick survey is on
my list for Bug Days coming up.
Rob
--
To post to this group, send an e
On Sat, Jan 1, 2011 at 8:09 PM, Rob Beezer wrote:
> A fix is available at http://trac.sagemath.org/sage_trac/ticket/10543
Good, because this is a major bug! See below for how it could wreak havoc:
sage: A = matrix(QQ,2,range(4))
sage: C = A.echelon_form()
sage: C[0,0] = 20
sage: A.echelon_for
A fix is available at http://trac.sagemath.org/sage_trac/ticket/10543
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/g
Thanks, Robert. I'll dig deeper.
On Dec 28, 11:24 pm, Robert Bradshaw
wrote:
> On Tue, Dec 28, 2010 at 8:38 PM, Rob Beezer wrote:
> > sage: A=matrix(QQ,2,range(4))
> > sage: B=matrix(ZZ,2,range(4))
> > sage: C=A.echelon_form()
> > sage: D=B.echelon_form()
> > sage: C.is_mutable()
> > True
> > s
On Dec 27, 2010, at 11:25 , Robert Bradshaw wrote:
> On Mon, Dec 27, 2010 at 11:14 AM, Justin C. Walker wrote:
>> Thanks for the reply.
>>
>> On Dec 26, 2010, at 03:17 , Volker Braun wrote:
>>
>>> Python has no "const". You can always manually change the innards of your
>>> class. The set_immu
On Mon, Dec 27, 2010 at 11:14 AM, Justin C. Walker wrote:
> Thanks for the reply.
>
> On Dec 26, 2010, at 03:17 , Volker Braun wrote:
>
>> Python has no "const". You can always manually change the innards of your
>> class. The set_immutable() is just implemented by hand.
>
> Tuples are "really" im
Thanks for the reply.
On Dec 26, 2010, at 03:17 , Volker Braun wrote:
> Python has no "const". You can always manually change the innards of your
> class. The set_immutable() is just implemented by hand.
Tuples are "really" immutable, correct? Is this possible because the tuple is
an internal
Python has no "const". You can always manually change the innards of your
class. The set_immutable() is just implemented by hand.
One could override __setattr__() to catch assignments to existing
attributes, but I think that is not done anywhere in Sage.
--
To post to this group, send an email
30 matches
Mail list logo
