วันอังคารที่ 31 พฤษภาคม พ.ศ. 2554

[sage-devel] Re: patch ticket says it was merged, but patch doesn't appear to be merged

On 5/31/11 3:59 AM, Jeroen Demeyer wrote:
> On 2011-05-30 20:54, Jason Grout wrote:
>> I just noticed that
>>
>> http://trac.sagemath.org/sage_trac/ticket/7002
>>
>> says it was merged a long time ago, but the help file that you get when
>> clicking "Help" in 4.7 in the notebook, the line "Autoevaluate Cells on
>> Load" still lists the old text.
>>
>> Question 1: Is this patch touching the right file to change the text in
>> the page that pops up when you click "Help" in the notebook?
> No, devel/sage/server/notebook is the *old* notebook. I have fixed #7002.


Ah, of course! This patch maybe slipped through the cracks when we
moved to the current notebook.

>
> Perhaps the old notebook can be removed?
> http://trac.sagemath.org/sage_trac/ticket/11409
>

If we are merging the flask notebook this next release, I think that it
would be appropriate to remove the old notebook.

Jason

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] patch ticket says it was merged, but patch doesn't appear to be merged

On 2011-05-30 20:54, Jason Grout wrote:
> I just noticed that
>
> http://trac.sagemath.org/sage_trac/ticket/7002
>
> says it was merged a long time ago, but the help file that you get when
> clicking "Help" in 4.7 in the notebook, the line "Autoevaluate Cells on
> Load" still lists the old text.
>
> Question 1: Is this patch touching the right file to change the text in
> the page that pops up when you click "Help" in the notebook?
No, devel/sage/server/notebook is the *old* notebook. I have fixed #7002.

Perhaps the old notebook can be removed?
http://trac.sagemath.org/sage_trac/ticket/11409

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Can we afford a new attribute of sage.structure.element.Element?

On Tue, May 31, 2011 at 1:23 AM, Robert Bradshaw
<robertwb@math.washington.edu> wrote:
> On Tue, May 31, 2011 at 12:23 AM, Simon King <simon.king@uni-jena.de> wrote:
>> Hi Robert,
>>
>> Thank you for resuming this thread.
>>
>> On 31 Mai, 08:13, Robert Bradshaw <rober...@math.washington.edu>
>> wrote:
>>> > So, the additional memory usage seems affordable to me.
>>>
>>> Elements of small finite fields are cached, so this test doesn't
>>> really show anything.
>>>
>>> sage: GF(2)(1) is GF(2)(-1)
>>> True
>>
>> I see.
>>
>> I am trying to sum up what the few participants of the discussion
>> agreed upon.
>>
>> * By default, a cached method or a lazy attribute tries to use
>> attribute assignment in order to make itself work. That's probably the
>> fastest what one can do, and it is how things already worked before
>> #11115.
>>
>> * If attribute assignment fails (that may happen for extension
>> classes) then it is tried to store stuff in an attribute
>> __cached_methods. That's new in #11115.
>>
>> * The __cached_methods attribute is added to parents. The rationale is
>> that (1) cached methods seem to be most frequently used for parents
>> (not for elements), (2) parents are big anyway, so that an additional
>> attribute should not count so much. Note that the stuff stored in
>> __cached_method would otherwise be stored via attribute assignment,
>> and the new attribute will be None if attribute assignment is possible
>> -- hence, there should be no memory problem.
>>
>> * In contrast to what I had originally planned, the patches from
>> #11115 do *not* add __cached_methods to
>> sage.structure.element.Element. That means: One can still use cached
>> methods and lazy attributes on elements that accept attribute
>> assignment; but on other elements, cached methods and lazy attributes
>> are not supported.
>>
>> * If one wants cached methods on an element class that for some reason
>> can not accept general attribute assignment, #11115 adds a new
>> subclass of Element, called ElementWithCachedMethod. It provides the
>> __cached_methods attribute.
>>
>> By consequence, both cached methods and lazy attributes work for *all*
>> parents and *most* elements, and there is the big speed up for cached
>> methods. Just to avoid misunderstanding: The speed-up is not related
>> with the existence of __cached_methods.
>>
>>> > But I guess I
>>> > should try to find out why the element creation became slower for
>>> > GF(2), while it became faster for GF(101), and again slower for
>>> > GF(next_prime(10^6)) (see example on the ticket).
>>>
>>> Noise?
>>
>> Perhaps.
>>
>>> I think the increased memory usage is a bigger issue than performance
>>> (it can impact the latter, but in hard-to-measure ways).
>>
>> I did not notice a big increase in memory consumption.
>
> This is because you were testing with finite fields that create all
> their elements ahead of time and re-use them.

Or perhaps you're referring to the total startup memory? We create
lots of Parents at startup, but (relatively) few elements (compared to
typical use).

In any case, I like the current solution best.

> sage: M = matrix(InfinitePolynomialRing(QQ), 100, 100, range(10000))
> sage: get_memory_usage()
> 228.75
> sage: max(a.max_index() for a in M.list()) # a cached method
> -1
> sage: get_memory_usage()
> 265.00390625
>
>> But perhaps you
>> can find a test case where this would be a problem?
>
> I can't think of one off the top of my head, but this is a problem in
> general (as explained so well by nbruin in on the ticket).
>
>>> In fact, some objects (e.g. matrices) already have a "cache" dict,
>>> this could be done at a higher level.
>>
>> Yep, I guess the purpose of __cached_methods is similar. Originally, I
>> only intended to use it for cached methods, but then I also used it to
>> make inherited lazy attributes (such as element_class) work on
>> extension classes.
>>
>>> Creating a new element means existing class hierarchies will have to
>>> be changed (e.g. RingElement) to take advantage of this, but that may
>>> be what's required.
>>
>> By "new element" you mean a new class such as ElementWithCachedMethod?
>> The patches from #11115 do not change the class hierarchy for things
>> like RingElement -- they offer ElementWithCachedMethod, but it is
>> currently not more than an offer.
>>
>>> Also, blindly marking all self-only methods as cached is a huge change
>>> in the time-memory performance tradeoff.
>>
>> Yep. Meanwhile I found that it makes more sense to add the
>> @cached_method decorator only to carefully chosen small frequently
>> used methods, such as modulus() of finite fields, and in some cases
>> caching gen() has a positive effect.
>
> +1 to thoughtful use. It's a wonderful decorator. (Actually, I wanted
> it at work for something just yesterday, but I was using Java :(.
>
>>> Some things may be
>>> better to re-compute rather than store (especially if they're biggish
>>> and cheap).
>>
>> In what sense do you mean "better"?
>
> That depends on how much time you have vs. how much memory you have.
> As another example, it'd be a waste to cache parent() or the degree of
> a univariate polynomial.
>
>> TIME-WISE, a cached method post-#11115 even beats a method that does
>> no computation at all:
>>
>> sage: class MyClass:
>> ....:     def __init__(self,m):
>> ....:         self.__modulus = m
>> ....:     def modulus(self):
>> ....:         return self.__modulus
>> ....:     @cached_method
>> ....:     def c_modulus(self):
>> ....:         return self.__modulus
>> ....:     def one(self):
>> ....:         return 1
>> ....:     @cached_method
>> ....:     def c_one(self):
>> ....:         return 1
>> ....:
>> sage: O = MyClass(5)
>> sage: timeit('O.modulus()', number=10^7)
>> 10000000 loops, best of 3: 247 ns per loop
>> sage: timeit('O.c_modulus()', number=10^7)
>> 10000000 loops, best of 3: 106 ns per loop
>> sage: timeit('O.one()', number=10^7)
>> 10000000 loops, best of 3: 419 ns per loop
>> sage: timeit('O.c_one()', number=10^7)
>> 10000000 loops, best of 3: 106 ns per loop
>
> That's because MyClass is implemented in Python, and cached_method in
> Cython :).
>
>> Or do you mean "better memory-wise"? That may be true, if the result
>> of a method is big and not often used.
>
> Yes.
>
>> However, there frequently are methods that look like
>>   def bla(self):
>>       try:
>>           return self.__bla
>>       except AttributeError:
>>           do some lengthy computation
>>           self.__bla = result
>>           return result
>>
>> Those should be replaced by
>>    @cached_method
>>    def bla(self):
>>        do some lengthy computation
>>        return result
>>
>> That's both shorter and faster.
>
> I agree completely, I was more referring to marking all methods by default.
>
>>> If your'e setting up a generic infrastructure, perhaps the
>>> default could be enabled/disabled with a flag (and with statement
>>> context).
>>
>> I don't understand that. Can you give me an example?
>
> You'd have a "maybe_cache" decorator that would decide to cache based
> on a global flag. Then you'd do
>
> with aggressive_caching():
>    [some calculation that uses maybe_cache decorated methods
> [here, all caches are cleared and memory reclaimed]
>
> Probably not worth it, and things will get garbage collected when
> you're done with them.
>
> - Robert
>

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Can we afford a new attribute of sage.structure.element.Element?

On Tue, May 31, 2011 at 12:23 AM, Simon King <simon.king@uni-jena.de> wrote:
> Hi Robert,
>
> Thank you for resuming this thread.
>
> On 31 Mai, 08:13, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>> > So, the additional memory usage seems affordable to me.
>>
>> Elements of small finite fields are cached, so this test doesn't
>> really show anything.
>>
>> sage: GF(2)(1) is GF(2)(-1)
>> True
>
> I see.
>
> I am trying to sum up what the few participants of the discussion
> agreed upon.
>
> * By default, a cached method or a lazy attribute tries to use
> attribute assignment in order to make itself work. That's probably the
> fastest what one can do, and it is how things already worked before
> #11115.
>
> * If attribute assignment fails (that may happen for extension
> classes) then it is tried to store stuff in an attribute
> __cached_methods. That's new in #11115.
>
> * The __cached_methods attribute is added to parents. The rationale is
> that (1) cached methods seem to be most frequently used for parents
> (not for elements), (2) parents are big anyway, so that an additional
> attribute should not count so much. Note that the stuff stored in
> __cached_method would otherwise be stored via attribute assignment,
> and the new attribute will be None if attribute assignment is possible
> -- hence, there should be no memory problem.
>
> * In contrast to what I had originally planned, the patches from
> #11115 do *not* add __cached_methods to
> sage.structure.element.Element. That means: One can still use cached
> methods and lazy attributes on elements that accept attribute
> assignment; but on other elements, cached methods and lazy attributes
> are not supported.
>
> * If one wants cached methods on an element class that for some reason
> can not accept general attribute assignment, #11115 adds a new
> subclass of Element, called ElementWithCachedMethod. It provides the
> __cached_methods attribute.
>
> By consequence, both cached methods and lazy attributes work for *all*
> parents and *most* elements, and there is the big speed up for cached
> methods. Just to avoid misunderstanding: The speed-up is not related
> with the existence of __cached_methods.
>
>> > But I guess I
>> > should try to find out why the element creation became slower for
>> > GF(2), while it became faster for GF(101), and again slower for
>> > GF(next_prime(10^6)) (see example on the ticket).
>>
>> Noise?
>
> Perhaps.
>
>> I think the increased memory usage is a bigger issue than performance
>> (it can impact the latter, but in hard-to-measure ways).
>
> I did not notice a big increase in memory consumption.

This is because you were testing with finite fields that create all
their elements ahead of time and re-use them.

sage: M = matrix(InfinitePolynomialRing(QQ), 100, 100, range(10000))
sage: get_memory_usage()
228.75
sage: max(a.max_index() for a in M.list()) # a cached method
-1
sage: get_memory_usage()
265.00390625

> But perhaps you
> can find a test case where this would be a problem?

I can't think of one off the top of my head, but this is a problem in
general (as explained so well by nbruin in on the ticket).

>> In fact, some objects (e.g. matrices) already have a "cache" dict,
>> this could be done at a higher level.
>
> Yep, I guess the purpose of __cached_methods is similar. Originally, I
> only intended to use it for cached methods, but then I also used it to
> make inherited lazy attributes (such as element_class) work on
> extension classes.
>
>> Creating a new element means existing class hierarchies will have to
>> be changed (e.g. RingElement) to take advantage of this, but that may
>> be what's required.
>
> By "new element" you mean a new class such as ElementWithCachedMethod?
> The patches from #11115 do not change the class hierarchy for things
> like RingElement -- they offer ElementWithCachedMethod, but it is
> currently not more than an offer.
>
>> Also, blindly marking all self-only methods as cached is a huge change
>> in the time-memory performance tradeoff.
>
> Yep. Meanwhile I found that it makes more sense to add the
> @cached_method decorator only to carefully chosen small frequently
> used methods, such as modulus() of finite fields, and in some cases
> caching gen() has a positive effect.

+1 to thoughtful use. It's a wonderful decorator. (Actually, I wanted
it at work for something just yesterday, but I was using Java :(.

>> Some things may be
>> better to re-compute rather than store (especially if they're biggish
>> and cheap).
>
> In what sense do you mean "better"?

That depends on how much time you have vs. how much memory you have.
As another example, it'd be a waste to cache parent() or the degree of
a univariate polynomial.

> TIME-WISE, a cached method post-#11115 even beats a method that does
> no computation at all:
>
> sage: class MyClass:
> ....:     def __init__(self,m):
> ....:         self.__modulus = m
> ....:     def modulus(self):
> ....:         return self.__modulus
> ....:     @cached_method
> ....:     def c_modulus(self):
> ....:         return self.__modulus
> ....:     def one(self):
> ....:         return 1
> ....:     @cached_method
> ....:     def c_one(self):
> ....:         return 1
> ....:
> sage: O = MyClass(5)
> sage: timeit('O.modulus()', number=10^7)
> 10000000 loops, best of 3: 247 ns per loop
> sage: timeit('O.c_modulus()', number=10^7)
> 10000000 loops, best of 3: 106 ns per loop
> sage: timeit('O.one()', number=10^7)
> 10000000 loops, best of 3: 419 ns per loop
> sage: timeit('O.c_one()', number=10^7)
> 10000000 loops, best of 3: 106 ns per loop

That's because MyClass is implemented in Python, and cached_method in
Cython :).

> Or do you mean "better memory-wise"? That may be true, if the result
> of a method is big and not often used.

Yes.

> However, there frequently are methods that look like
>   def bla(self):
>       try:
>           return self.__bla
>       except AttributeError:
>           do some lengthy computation
>           self.__bla = result
>           return result
>
> Those should be replaced by
>    @cached_method
>    def bla(self):
>        do some lengthy computation
>        return result
>
> That's both shorter and faster.

I agree completely, I was more referring to marking all methods by default.

>> If your'e setting up a generic infrastructure, perhaps the
>> default could be enabled/disabled with a flag (and with statement
>> context).
>
> I don't understand that. Can you give me an example?

You'd have a "maybe_cache" decorator that would decide to cache based
on a global flag. Then you'd do

with aggressive_caching():
[some calculation that uses maybe_cache decorated methods
[here, all caches are cleared and memory reclaimed]

Probably not worth it, and things will get garbage collected when
you're done with them.

- Robert

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Can we afford a new attribute of sage.structure.element.Element?

Hi Robert,

Thank you for resuming this thread.

On 31 Mai, 08:13, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> > So, the additional memory usage seems affordable to me.
>
> Elements of small finite fields are cached, so this test doesn't
> really show anything.
>
> sage: GF(2)(1) is GF(2)(-1)
> True

I see.

I am trying to sum up what the few participants of the discussion
agreed upon.

* By default, a cached method or a lazy attribute tries to use
attribute assignment in order to make itself work. That's probably the
fastest what one can do, and it is how things already worked before
#11115.

* If attribute assignment fails (that may happen for extension
classes) then it is tried to store stuff in an attribute
__cached_methods. That's new in #11115.

* The __cached_methods attribute is added to parents. The rationale is
that (1) cached methods seem to be most frequently used for parents
(not for elements), (2) parents are big anyway, so that an additional
attribute should not count so much. Note that the stuff stored in
__cached_method would otherwise be stored via attribute assignment,
and the new attribute will be None if attribute assignment is possible
-- hence, there should be no memory problem.

* In contrast to what I had originally planned, the patches from
#11115 do *not* add __cached_methods to
sage.structure.element.Element. That means: One can still use cached
methods and lazy attributes on elements that accept attribute
assignment; but on other elements, cached methods and lazy attributes
are not supported.

* If one wants cached methods on an element class that for some reason
can not accept general attribute assignment, #11115 adds a new
subclass of Element, called ElementWithCachedMethod. It provides the
__cached_methods attribute.

By consequence, both cached methods and lazy attributes work for *all*
parents and *most* elements, and there is the big speed up for cached
methods. Just to avoid misunderstanding: The speed-up is not related
with the existence of __cached_methods.

> > But I guess I
> > should try to find out why the element creation became slower for
> > GF(2), while it became faster for GF(101), and again slower for
> > GF(next_prime(10^6)) (see example on the ticket).
>
> Noise?

Perhaps.

> I think the increased memory usage is a bigger issue than performance
> (it can impact the latter, but in hard-to-measure ways).

I did not notice a big increase in memory consumption. But perhaps you
can find a test case where this would be a problem?

> In fact, some objects (e.g. matrices) already have a "cache" dict,
> this could be done at a higher level.

Yep, I guess the purpose of __cached_methods is similar. Originally, I
only intended to use it for cached methods, but then I also used it to
make inherited lazy attributes (such as element_class) work on
extension classes.

> Creating a new element means existing class hierarchies will have to
> be changed (e.g. RingElement) to take advantage of this, but that may
> be what's required.

By "new element" you mean a new class such as ElementWithCachedMethod?
The patches from #11115 do not change the class hierarchy for things
like RingElement -- they offer ElementWithCachedMethod, but it is
currently not more than an offer.

> Also, blindly marking all self-only methods as cached is a huge change
> in the time-memory performance tradeoff.

Yep. Meanwhile I found that it makes more sense to add the
@cached_method decorator only to carefully chosen small frequently
used methods, such as modulus() of finite fields, and in some cases
caching gen() has a positive effect.

> Some things may be
> better to re-compute rather than store (especially if they're biggish
> and cheap).

In what sense do you mean "better"?

TIME-WISE, a cached method post-#11115 even beats a method that does
no computation at all:

sage: class MyClass:
....: def __init__(self,m):
....: self.__modulus = m
....: def modulus(self):
....: return self.__modulus
....: @cached_method
....: def c_modulus(self):
....: return self.__modulus
....: def one(self):
....: return 1
....: @cached_method
....: def c_one(self):
....: return 1
....:
sage: O = MyClass(5)
sage: timeit('O.modulus()', number=10^7)
10000000 loops, best of 3: 247 ns per loop
sage: timeit('O.c_modulus()', number=10^7)
10000000 loops, best of 3: 106 ns per loop
sage: timeit('O.one()', number=10^7)
10000000 loops, best of 3: 419 ns per loop
sage: timeit('O.c_one()', number=10^7)
10000000 loops, best of 3: 106 ns per loop

Or do you mean "better memory-wise"? That may be true, if the result
of a method is big and not often used.

However, there frequently are methods that look like
def bla(self):
try:
return self.__bla
except AttributeError:
do some lengthy computation
self.__bla = result
return result

Those should be replaced by
@cached_method
def bla(self):
do some lengthy computation
return result

That's both shorter and faster.

> If your'e setting up a generic infrastructure, perhaps the
> default could be enabled/disabled with a flag (and with statement
> context).

I don't understand that. Can you give me an example?

Best regards,
Simon

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

วันจันทร์ที่ 30 พฤษภาคม พ.ศ. 2554

Re: [sage-devel] Re: Can we afford a new attribute of sage.structure.element.Element?

On Sat, Apr 30, 2011 at 1:27 AM, Simon King <simon.king@uni-jena.de> wrote:
> Hi Nicolas,
>
> On 29 Apr., 23:06, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
> wrote:
>> Can you give it a shot with GF(2), so as to hit one of the smallest
>> possible sage Element?
>
> Sage-4.7.alpha5 with patches:
>
> sage: K = GF(2)
> sage: get_memory_usage()
> 842.01171875
> sage: %time L = [K(i) for i in xrange(10^7)]
> CPU times: user 25.85 s, sys: 0.05 s, total: 25.91 s
> Wall time: 25.91 s
> sage: get_memory_usage()
> 920.51171875
> sage: 920.51171875 - 842.01171875
> 78.5000000000000
>
> Sage-4.7.alpha5 without patches:
>
> sage: K = GF(2)
> sage: get_memory_usage()
> 839.96875
> sage: %time L = [K(i) for i in xrange(10^7)]
> CPU times: user 24.71 s, sys: 0.04 s, total: 24.75 s
> Wall time: 24.75 s
> sage: get_memory_usage()
> 918.4609375
> sage: 918.4609375 - 839.96875
> 78.4921875000000
>
> So, the additional memory usage seems affordable to me.

Elements of small finite fields are cached, so this test doesn't
really show anything.

sage: GF(2)(1) is GF(2)(-1)
True

> But I guess I
> should try to find out why the element creation became slower for
> GF(2), while it became faster for GF(101), and again slower for
> GF(next_prime(10^6)) (see example on the ticket).

Noise?

I think the increased memory usage is a bigger issue than performance
(it can impact the latter, but in hard-to-measure ways). I'm not as
worried about one field as a precedent, and I'm glad you brought this
up (even if it just sat starred in my inbox for a while). Perhaps for
infrequently accessed fields a level of indirection would be
worthwhile, a single lazily-initialized field (either an actual Python
dictionary, or some cdef object with special fields (+ a dict too?)).
In fact, some objects (e.g. matrices) already have a "cache" dict,
this could be done at a higher level.

Creating a new element means existing class hierarchies will have to
be changed (e.g. RingElement) to take advantage of this, but that may
be what's required.

Also, blindly marking all self-only methods as cached is a huge change
in the time-memory performance tradeoff. In terms of memory, imagine I
did

def all_possible_orders(element_list):
return set(g.order() for g in element_list)

I have now doubled my memory usage if g was small. Some things may be
better to re-compute rather than store (especially if they're biggish
and cheap). If your'e setting up a generic infrastructure, perhaps the
default could be enabled/disabled with a flag (and with statement
context).

- Robert

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: problem using magma with 4.7 not just in the notebook

Why the new ticket when #11401 is already open on this?

John

On Mon, May 30, 2011 at 8:56 PM, William Stein <wstein@gmail.com> wrote:
> On Mon, May 30, 2011 at 9:15 AM, Nils Bruin <nbruin@sfu.ca> wrote:
>> This will probably help the person who is going to track down this
>> bug: It's not just in the notebook and it looks like newlines in the
>> input knock the interface out of sync (but not always!) The following
>> example fails reliably for me:
>>
>> sage: magma.execute("a:=1;b:=2;")
>> ''
>> sage: magma.execute("print a,b;")
>> '1 2'
>> sage: magma.execute("""a:=1;
>> ....: b:=2;""")
>> 'b:=2;'
>> sage:  magma.execute("print a,b;")
>> ''
>>
>> The first two lines work as expected. The third line seems to ruin it
>> (that "b:=2;" should be executed, not echoed) and after that nothing
>> works
>>
>
> It might be clearer to express your failing test case as:
>
> sage: magma.eval("a:=2;\nb:=3;\nprint a,b;")
> 'b:=3;\nprint a,b;'
>
> instead of the expected
>
> sage: magma.eval("a:=2;\nb:=3;\nprint a,b;")
> '2 3'
>
> Where the latter is to be expected since
>
> Magma V2.17-4     Mon May 30 2011 12:54:51 on deep     [Seed = 2436835871]
> Type ? for help.  Type <Ctrl>-D to quit.
>> a :=2;
>> b :=3;
>> print a,b;
> 2 3
>
>
> This is now http://trac.sagemath.org/sage_trac/ticket/11405
>
>
>
>> --
>> To post to this group, send an email to sage-devel@googlegroups.com
>> To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
>> For more options, visit this group at http://groups.google.com/group/sage-devel
>> URL: http://www.sagemath.org
>>
>
>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: problem using magma with 4.7 not just in the notebook

On Mon, May 30, 2011 at 9:15 AM, Nils Bruin <nbruin@sfu.ca> wrote:
> This will probably help the person who is going to track down this
> bug: It's not just in the notebook and it looks like newlines in the
> input knock the interface out of sync (but not always!) The following
> example fails reliably for me:
>
> sage: magma.execute("a:=1;b:=2;")
> ''
> sage: magma.execute("print a,b;")
> '1 2'
> sage: magma.execute("""a:=1;
> ....: b:=2;""")
> 'b:=2;'
> sage:  magma.execute("print a,b;")
> ''
>
> The first two lines work as expected. The third line seems to ruin it
> (that "b:=2;" should be executed, not echoed) and after that nothing
> works
>

It might be clearer to express your failing test case as:

sage: magma.eval("a:=2;\nb:=3;\nprint a,b;")
'b:=3;\nprint a,b;'

instead of the expected

sage: magma.eval("a:=2;\nb:=3;\nprint a,b;")
'2 3'

Where the latter is to be expected since

Magma V2.17-4 Mon May 30 2011 12:54:51 on deep [Seed = 2436835871]
Type ? for help. Type <Ctrl>-D to quit.
> a :=2;
> b :=3;
> print a,b;
2 3


This is now http://trac.sagemath.org/sage_trac/ticket/11405

> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: problem using magma in notebook with 4.7

On May 29, 11:51 pm, Nils Bruin <nbr...@sfu.ca> wrote:
> (for Rob Beezer: #11374 only fixes a typo in a doctest. This must be
> another issue).

Thanks, Nils. Not being very careful. #11374 was a follow-on to
#9605 (which was what I was remembering) and I see #9605 now being
discussed on the new ticket.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] patch ticket says it was merged, but patch doesn't appear to be merged

I just noticed that

http://trac.sagemath.org/sage_trac/ticket/7002

says it was merged a long time ago, but the help file that you get when
clicking "Help" in 4.7 in the notebook, the line "Autoevaluate Cells on
Load" still lists the old text.

Question 1: Is this patch touching the right file to change the text in
the page that pops up when you click "Help" in the notebook?

Question 2: If this patch was somehow unmerged, what other patches
should we check to see if they were also unmerged?

Thanks,

Jason

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: [linbox-use] Nullspace of a rational matrix?

On Sat, May 28, 2011 at 1:41 PM, Josh <joshuag83@gmail.com> wrote:
> Hi all,
>
> I would like to compute the nullspace basis of a dense (exact)
> rational matrix. Is this possible in linbox? It looks like the methods
> in solutions/nullspace.h only work for finite fields, as they use
> FFLAS for the LU decomposition... (but I'm a little new to all these
> linear algebra packages, so forgive me if this is a silly question).
>
> If it's not possible in linbox, does anyone have any suggestions of
> packages that do this? (I was using GAP, but it was incredibly slow,
> because the bit-sizes of the intermediate results get big, and it's
> doing straightforward exact rational arithmetic rather than something
> like p-adic lifting.)

I wrote code that is in Sage (see [1] and [2]), which is free and open
source, to do this, that is a wrapper around IML [3] + Linbox + some
of my own ideas. It can do nullspace of a 300x301 with 64-bit
entries in about 4 seconds (the entries of the answers have over 10000
digits each).

Here's an example of how to use Sage for this problem:

sage: a = matrix(QQ, 2, 3, [1,2,7/9,8,4,6/3])
sage: a.right_kernel()
Vector space of degree 3 and dimension 1 over Rational Field
Basis matrix:
[ 1 19/4 -27/2]

For many more examples, see the worksheet I just published at [4].
For bigger problems you may need more RAM, which means installing Sage
on your own computer.

I compared some timings with GAP (as you'll see in [4]), and Sage is
dramatically faster. This is probably partly because the released
version of GAP (at least the one in Sage) doesn't even have
asymptotically fast arbitrary precision integers (e.g., [5])...

10 x 11 -- Sage: 0.05 seconds, GAP: 0.03 seconds
20 x 21 -- Sage: 0.01 seconds, GAP: 0.20 seconds
30 x 31 -- Sage: 0.02 seconds, GAP: 0.93 seconds
40 x 41 -- Sage: 0.03 seconds, GAP: 2.77 seconds
50 x 51 -- Sage: 0.04 seconds, GAP: 7.77 seconds

[1] http://sagemath.org
[2] try instantly at http://flask.sagenb.org
[3] http://www.cs.uwaterloo.ca/~astorjoh/iml.html
[4] http://flask.sagenb.org/home/pub/72/
[5] http://mpir.org/


When I wrote this code in 2007, for some range of matrix sizes and
bitsizes it was the fastest code in the world (even solidly beating
Magma, which was the fastest before)... mainly since IML is so damned
good. I don't know what the current situation is.

-- William


>
> Thanks,
> Josh
>
> --
> You received this message because you are subscribed to the Google Groups "linbox-use" group.
> To post to this group, send email to linbox-use@googlegroups.com.
> To unsubscribe from this group, send email to linbox-use+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/linbox-use?hl=en.
>
>

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: problem using magma with 4.7 not just in the notebook

Looking at the magma.eval() function, I see that if the string to be
passed to magma does not end in ';' then a semicolon is appended.
That is clearly intended for convenience (Sage users are not used to
ending lines with ';') but must cause problems with continuation
lines, surely?

I tried Nils's exact code after first setting
sage: magma = Magma(logfile="magma.log")

and afterwards the log file contains

Magma V2.17-5 Mon May 30 2011 17:45:19 on John-laptop [Seed = 1409144779]
Type ? for help. Type <Ctrl>-D to quit.
SetPrompt(">>>"); SetLineEditor(false); SetColumns(0);
SetPrompt(">>>"); SetLineEditor(false); SetColumns(0);
> SetPrompt(">>>"); SetLineEditor(false); SetColumns(0);
>>>AttachSpec("/home/john/.sage/temp/John_laptop/19013/dir_0/data//spec");
AttachSpec("/home/john/.sage/temp/John_laptop/19013/dir_0/data//spec");
>>>a:=1;b:=2;
a:=1;b:=2;
>>>print a,b;
print a,b;
1 2
>>>a:=1;
b:=2;
a:=1;
b:=2;
>>>print a,b;
>>>print a,b;
print a,b;
1 2
>>>print a,b;
quit
1 2
>>>quit
>>>

in case that helps!

John

On Mon, May 30, 2011 at 5:15 PM, Nils Bruin <nbruin@sfu.ca> wrote:
> This will probably help the person who is going to track down this
> bug: It's not just in the notebook and it looks like newlines in the
> input knock the interface out of sync (but not always!) The following
> example fails reliably for me:
>
> sage: magma.execute("a:=1;b:=2;")
> ''
> sage: magma.execute("print a,b;")
> '1 2'
> sage: magma.execute("""a:=1;
> ....: b:=2;""")
> 'b:=2;'
> sage:  magma.execute("print a,b;")
> ''
>
> The first two lines work as expected. The third line seems to ruin it
> (that "b:=2;" should be executed, not echoed) and after that nothing
> works
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] sage days in KL in September

Hi,

we are planning to organize Sage/Singular days in Kaiserslautern some
time in September. The focus will be on the development of
the Sage-Singular interface, and libSingular, but anybody interested
is welcome to participate.

Financial support will be available, especially for the brave who can
look libSingular in the eye. :)

If you are interested, please write back to me this week with date
constraints and any other suggestions. We will probably settle the dates
towards the end of next week.


Cheers,
Burcin

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: problem using magma with 4.7 not just in the notebook

This will probably help the person who is going to track down this
bug: It's not just in the notebook and it looks like newlines in the
input knock the interface out of sync (but not always!) The following
example fails reliably for me:

sage: magma.execute("a:=1;b:=2;")
''
sage: magma.execute("print a,b;")
'1 2'
sage: magma.execute("""a:=1;
....: b:=2;""")
'b:=2;'
sage: magma.execute("print a,b;")
''

The first two lines work as expected. The third line seems to ruin it
(that "b:=2;" should be executed, not echoed) and after that nothing
works

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] [sage-combinat-devel] Trac server problem...

Hi there,

I currently quite often got "internal server error" from the trac
server. Retrying a few time seems to work. Is there a maintenance or something
going on ?

Cheers,

Florent

--
You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to sage-combinat-devel+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: problem using magma in notebook with 4.7

Thanks for checking this out, Nils. I had a report from one of my
students who uses this, soon after switching to 4.7 on our server, but
it was too late in the evening for me to investigate myself.

I'll tell him it's being trac'ed.

John

On Mon, May 30, 2011 at 7:51 AM, Nils Bruin <nbruin@sfu.ca> wrote:
> Confirmed. This is now http://trac.sagemath.org/sage_trac/ticket/11401.
> (for Rob Beezer: #11374 only fixes a typo in a doctest. This must be
> another issue). No idea what the problem is, but it's an annoying one.
> I do use the notebook interface for magma occasionally, especially for
> presentations.
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

วันอาทิตย์ที่ 29 พฤษภาคม พ.ศ. 2554

[sage-devel] Re: problem using magma in notebook with 4.7

Confirmed. This is now http://trac.sagemath.org/sage_trac/ticket/11401.
(for Rob Beezer: #11374 only fixes a typo in a doctest. This must be
another issue). No idea what the problem is, but it's an annoying one.
I do use the notebook interface for magma occasionally, especially for
presentations.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Solving a gcd equation for polynomials

On May 29, 2:09 am, javier <vengor...@gmail.com> wrote:
> I have been looking at the paper and at first glance don't see any
> reason that would prevent the stabilization algorithm from working
> over any Euclidean domain, as there you have division with remainder,
> gcd, xgcd, all ideals are principal, sum of ideals is generated by the
> gcd and so on. The only obvious change that I see is that in the Split
> algorithm ceil(log log D) should be replaced by something like
> ceil(log log N(D)) where N is the Euclidean norm (which would be the
> degree in your case for polynomials over a field). Or am I missing
> something?

Yes, that was exactly my impression as well. Though I thought maybe
the "celing log log D" would become just "ceiling log(degree)" It
seemed to be that one of the logs came from the observation that 2 is
the smallest prime, which would not be useful (or applicable) in the
case of polynomials. But I have not gone back to double-check my
work, nor yet attempted to actually implement it.

Rob

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: problem using magma in notebook with 4.7

Is this the problem?

http://trac.sagemath.org/sage_trac/ticket/11374

It's a one-character patch, but I couldn't review it since I do not
have access to Magma.

Rob

On May 29, 3:06 pm, John Cremona <john.crem...@gmail.com> wrote:
> Can someone with magma try running a notebook which has magma set as
> the default language?  Some weird things are happening, with the
> output out of sync with the input, as though the identifiers were
> getting messed up.
>
> I will try to create an actual test case, sorry this is vague.
>
> John

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] problem using magma in notebook with 4.7

Can someone with magma try running a notebook which has magma set as
the default language? Some weird things are happening, with the
output out of sync with the input, as though the identifiers were
getting messed up.

I will try to create an actual test case, sorry this is vague.

John

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Solving a gcd equation for polynomials

I have been looking at the paper and at first glance don't see any
reason that would prevent the stabilization algorithm from working
over any Euclidean domain, as there you have division with remainder,
gcd, xgcd, all ideals are principal, sum of ideals is generated by the
gcd and so on. The only obvious change that I see is that in the Split
algorithm ceil(log log D) should be replaced by something like
ceil(log log N(D)) where N is the Euclidean norm (which would be the
degree in your case for polynomials over a field). Or am I missing
something?

Cheers
J


On 28 mayo, 21:41, Rob Beezer <goo...@beezer.cotse.net> wrote:
> On May 25, 2:22 pm, John Cremona <john.crem...@gmail.com> wrote:
>
> > If no-one else is more explicit I'll look for a reference tomorrow.
>
> For the record, off-list John Cremona pointed me to "Fast Algorithms
> for Linear Algebra mod N" by Storjohann and Mulders, where this is
> called "stablization of  p  and  q  mod  r" and there is an
> (apparently efficient) algorithm given (for integers).
>
> Thanks, John.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Versioning objects

On Sun, May 29, 2011 at 1:33 AM, Simon King <simon.king@uni-jena.de> wrote:
> Hi Kwankyu
>
> On 29 Mai, 07:32, Kwankyu Lee <ekwan...@gmail.com> wrote:
>> I thought of the proposal while fixing unpickling problem of the patch for
>> TermOrder objects for
>>
>> http://trac.sagemath.org/sage_trac/ticket/11316
>
> Thank you for a pointer to an actual use case!
>
>> The situation I described originally is of course what I faced while fixing
>> the problem.
>
> So, I guess that the further discussion should be on that ticket.
>
> Nevertheless, if you don't mind to read the same text here and on the
> ticket:
>
> The pickling of a TermOrder is actually quite simple, standard Python.
> It is an object with a __dict__, and an instance can be constructed
> with __new__.
>
> EXAMPLE:
>
> First, we obtain an order:
>
>  sage: P.<x,y>=QQ[]
>  sage: T = P.term_order()
>
> Now, if I am not mistaken, S=loads(dumps(T)) essentially boils down to
> the following.
> First, we create a new instance of the class:
>
>  sage: S = T.__new__(T.__class__)
>
> And then, we provide the new instance with a copy of the old
> instance's __dict__:
>
>  sage: S.__dict__ = copy(T.__dict__)
>
> As a result, we have a copy of T:
>
>  sage: S
>  Degree reverse lexicographic term order
>  sage: S == T
>  True
>  sage: S is T
>  False
>
> If I understand correctly, the problem on #11316 is that your patch
> introduces a new attribute _weights, that has a default value for
> trivial degree weights. So, if __dict__ was taken from an old pickle,
> then it lacks the key '_weights'. Hence, requesting S._weights would
> fail.
>
> One suggestion on the ticket is to introduce a __getattr__ method,
> that returns the default weights and puts them into
> S.__dict__['_weights']. That ensures that S.__getattr__('_weights') is
> called at most once.
>
> The other suggestion, that was discussed on the thread cited above:
> Introduce the default _weights as a class attribute.

+1 to the suggestion of adding a class attribute.

> It seems to me that in both cases unpickling of old pickles should
> just work. One should test, though, whether one of the solutions has a
> speed penalty. I reckon that introducing __getattr__ may slow things
> down.
>
> Cheers,
> Simon
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Versioning objects

Hi Kwankyu

On 29 Mai, 07:32, Kwankyu Lee <ekwan...@gmail.com> wrote:
> I thought of the proposal while fixing unpickling problem of the patch for
> TermOrder objects for
>
> http://trac.sagemath.org/sage_trac/ticket/11316

Thank you for a pointer to an actual use case!

> The situation I described originally is of course what I faced while fixing
> the problem.

So, I guess that the further discussion should be on that ticket.

Nevertheless, if you don't mind to read the same text here and on the
ticket:

The pickling of a TermOrder is actually quite simple, standard Python.
It is an object with a __dict__, and an instance can be constructed
with __new__.

EXAMPLE:

First, we obtain an order:

sage: P.<x,y>=QQ[]
sage: T = P.term_order()

Now, if I am not mistaken, S=loads(dumps(T)) essentially boils down to
the following.
First, we create a new instance of the class:

sage: S = T.__new__(T.__class__)

And then, we provide the new instance with a copy of the old
instance's __dict__:

sage: S.__dict__ = copy(T.__dict__)

As a result, we have a copy of T:

sage: S
Degree reverse lexicographic term order
sage: S == T
True
sage: S is T
False

If I understand correctly, the problem on #11316 is that your patch
introduces a new attribute _weights, that has a default value for
trivial degree weights. So, if __dict__ was taken from an old pickle,
then it lacks the key '_weights'. Hence, requesting S._weights would
fail.

One suggestion on the ticket is to introduce a __getattr__ method,
that returns the default weights and puts them into
S.__dict__['_weights']. That ensures that S.__getattr__('_weights') is
called at most once.

The other suggestion, that was discussed on the thread cited above:
Introduce the default _weights as a class attribute.

It seems to me that in both cases unpickling of old pickles should
just work. One should test, though, whether one of the solutions has a
speed penalty. I reckon that introducing __getattr__ may slow things
down.

Cheers,
Simon

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

วันเสาร์ที่ 28 พฤษภาคม พ.ศ. 2554

[sage-devel] Re: Versioning objects

Hi Simon,

I thought of the proposal while fixing unpickling problem of the patch for TermOrder objects for

http://trac.sagemath.org/sage_trac/ticket/11316

The situation I described originally is of course what I faced while fixing the problem.

On 27 Mai, 18:10, Kwankyu Lee <ekwa...@gmail.com> wrote:
> How does Sage solve the following situation? A user stores objects pickled
> in Sage version X.1. Then a developer changes internal logic and data
> structure of the class of the objects for Sage version X.2. If we assume the
> developer's patch is merged to Sage X.2, then typically the user's objects
> fail to be unpickled in Sage X.2.

No. Typically they won't fail. The reason is that the way an object is pickled has typically
*nothing* to do with the *internal* data structure. The serialisation
is based on some data (such as tuples of coefficients, strings that
provide a name, etc), and on an unpickling function that is able to
create an object out of the given data.

So, a pickle from version X.1 will only fail to be readable in version
X.2 if the *interface of the unpickling function* has changed.
 
My understanding of the pickling procedure came from the Python documentation. A relevant passage is:
------------------------------------
... when class instances are pickled, their class's code and data are not pickled along with them. Only the instance data are pickled. This is done on purpose, so you can fix bugs in a class or add methods to the class and still load objects that were created with an earlier version of the class. If you plan to have long-lived objects that will see many versions of a class, it may be worthwhile to put a version number in the objects so that suitable conversions can be made by the class's __setstate__() method.
-------------------------------------
This seemed to be true at least for the pickled TermOrder objects.
 
Kwankyu

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] arithmetic dynamics

Hi Sage-Devel,

If you're a Sage developer seriously interested in improving Sage's
capabilities in "arithmetic dynamics" [1] (=number theory + dynamical
systems) email me, since there may be a conference I might be able to
get you invited to...

[1] http://en.wikipedia.org/wiki/Arithmetic_dynamics

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: building sage 4.7 with gcc 4.6 fails

On 05/28/2011 04:54 PM, Francois Bissey wrote:
> > Hi,
> >
> > system:
> > Linux 2.6.38-ARCH #1 SMP PREEMPT i686 Intel(R) Pentium(R) M processor
> > 1600MHz GenuineIntel GNU/Linux
> >
> > with gcc 4.6.0
> >
> > Sage 4.7 fails to build. make exited with this error
> > ---------------------------------------
> > running build_ext
> > building 'Crypto.PublicKey._fastmath' extension
> > creating build/temp.linux-i686-2.6
> > creating build/temp.linux-i686-2.6/src
> > gcc -Wall -Wstrict-prototypes -I/home/grout/sage-4.7/local/include
> > -L/home/grout/sage-4.7/local/lib -fPIC -O3 -fomit-frame-pointer -Isrc/
> > -I/home/grout/sage-4.7/local/include/python2.6 -c src/_fastmath.c -o
> > build/temp.linux-i686-2.6/src/_fastmath.o
> > /usr/lib/gcc/i686-pc-linux-gnu/4.6.0/cc1: symbol lookup error:
> > /usr/lib/libppl_c.so.4: undefined symbol:
> > _ZN23Parma_Polyhedra_Library13have_sse_unitE
> > error: command 'gcc' failed with exit status 1
> > Error installing PyCrypto... exiting
> >
> > real 0m0.348s
> > user 0m0.127s
> > sys 0m0.030s
> > sage: An error occurred while installing pycrypto-2.1.0
> > Please email sage-devel http://groups.google.com/group/sage-devel
> > explaining the problem and send the relevant part of
> > of /home/grout/sage-4.7/install.log. Describe your computer,
> > operating system, etc.
> > If you want to try to fix the problem yourself, *don't* just cd to
> > /home/grout/sage-4.7/spkg/build/pycrypto-2.1.0 and type 'make check'
> > or whatever is appropriate.
> > Instead, the following commands setup all environment variables
> > correctly and load a subshell for you to debug the error:
> > (cd '/home/grout/sage-4.7/spkg/build/pycrypto-2.1.0' &&
> > '/home/grout/sage-4.7/sage' -sh)
> > When you are done debugging, you can type "exit" to leave the
> > subshell.
> > make[1]: *** [installed/pycrypto-2.1.0] Error 1
> > make[1]: Leaving directory `/home/grout/sage-4.7/spkg'
> >
> > real 178m48.140s
> > user 98m15.989s
> > sys 7m54.596s
> > Error building Sage.
> > make: *** [build] Error 1
> > --------------------------------------------------
> >
> > I ran into the same error doing sage -upgrade, which unfortunately broke
> > my current sage.
> >
> This has already been reported on this list and trac.
> See here for the reports from Robert Gross from Arch:
> https://groups.google.com/forum/#!topic/sage-devel/hLL02U1Q5zU
> http://trac.sagemath.org/sage_trac/ticket/11391
Thanks for the link. The solution in the google groups discussion seems
to work for me (replacing the libppl.so.9.0.0 in sage lib dir with the
system version of the library).

Thanks
Ryan

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] building sage 4.7 with gcc 4.6 fails

> Hi,
>
> system:
> Linux 2.6.38-ARCH #1 SMP PREEMPT i686 Intel(R) Pentium(R) M processor
> 1600MHz GenuineIntel GNU/Linux
>
> with gcc 4.6.0
>
> Sage 4.7 fails to build. make exited with this error
> ---------------------------------------
> running build_ext
> building 'Crypto.PublicKey._fastmath' extension
> creating build/temp.linux-i686-2.6
> creating build/temp.linux-i686-2.6/src
> gcc -Wall -Wstrict-prototypes -I/home/grout/sage-4.7/local/include
> -L/home/grout/sage-4.7/local/lib -fPIC -O3 -fomit-frame-pointer -Isrc/
> -I/home/grout/sage-4.7/local/include/python2.6 -c src/_fastmath.c -o
> build/temp.linux-i686-2.6/src/_fastmath.o
> /usr/lib/gcc/i686-pc-linux-gnu/4.6.0/cc1: symbol lookup error:
> /usr/lib/libppl_c.so.4: undefined symbol:
> _ZN23Parma_Polyhedra_Library13have_sse_unitE
> error: command 'gcc' failed with exit status 1
> Error installing PyCrypto... exiting
>
> real    0m0.348s
> user    0m0.127s
> sys     0m0.030s
> sage: An error occurred while installing pycrypto-2.1.0
> Please email sage-devel http://groups.google.com/group/sage-devel
> explaining the problem and send the relevant part of
> of /home/grout/sage-4.7/install.log.  Describe your computer,
> operating system, etc.
> If you want to try to fix the problem yourself, *don't* just cd to
> /home/grout/sage-4.7/spkg/build/pycrypto-2.1.0 and type 'make check'
> or whatever is appropriate.
> Instead, the following commands setup all environment variables
> correctly and load a subshell for you to debug the error:
> (cd '/home/grout/sage-4.7/spkg/build/pycrypto-2.1.0' &&
> '/home/grout/sage-4.7/sage' -sh)
> When you are done debugging, you can type "exit" to leave the
> subshell.
> make[1]: *** [installed/pycrypto-2.1.0] Error 1
> make[1]: Leaving directory `/home/grout/sage-4.7/spkg'
>
> real    178m48.140s
> user    98m15.989s
> sys     7m54.596s
> Error building Sage.
> make: *** [build] Error 1
> --------------------------------------------------
>
> I ran into the same error doing sage -upgrade, which unfortunately broke
> my current sage.
>
This has already been reported on this list and trac.
See here for the reports from Robert Gross from Arch:
https://groups.google.com/forum/#!topic/sage-devel/hLL02U1Q5zU
http://trac.sagemath.org/sage_trac/ticket/11391

Francois

[sage-devel] building sage 4.7 with gcc 4.6 fails

Hi,

system:
Linux 2.6.38-ARCH #1 SMP PREEMPT i686 Intel(R) Pentium(R) M processor
1600MHz GenuineIntel GNU/Linux

with gcc 4.6.0

Sage 4.7 fails to build. make exited with this error
---------------------------------------
running build_ext
building 'Crypto.PublicKey._fastmath' extension
creating build/temp.linux-i686-2.6
creating build/temp.linux-i686-2.6/src
gcc -Wall -Wstrict-prototypes -I/home/grout/sage-4.7/local/include
-L/home/grout/sage-4.7/local/lib -fPIC -O3 -fomit-frame-pointer -Isrc/
-I/home/grout/sage-4.7/local/include/python2.6 -c src/_fastmath.c -o
build/temp.linux-i686-2.6/src/_fastmath.o
/usr/lib/gcc/i686-pc-linux-gnu/4.6.0/cc1: symbol lookup error:
/usr/lib/libppl_c.so.4: undefined symbol:
_ZN23Parma_Polyhedra_Library13have_sse_unitE
error: command 'gcc' failed with exit status 1
Error installing PyCrypto... exiting

real 0m0.348s
user 0m0.127s
sys 0m0.030s
sage: An error occurred while installing pycrypto-2.1.0
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /home/grout/sage-4.7/install.log. Describe your computer,
operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/home/grout/sage-4.7/spkg/build/pycrypto-2.1.0 and type 'make check'
or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd '/home/grout/sage-4.7/spkg/build/pycrypto-2.1.0' &&
'/home/grout/sage-4.7/sage' -sh)
When you are done debugging, you can type "exit" to leave the
subshell.
make[1]: *** [installed/pycrypto-2.1.0] Error 1
make[1]: Leaving directory `/home/grout/sage-4.7/spkg'

real 178m48.140s
user 98m15.989s
sys 7m54.596s
Error building Sage.
make: *** [build] Error 1
--------------------------------------------------

I ran into the same error doing sage -upgrade, which unfortunately broke
my current sage.

Ryan G.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Solving a gcd equation for polynomials

On May 25, 2:22 pm, John Cremona <john.crem...@gmail.com> wrote:
> If no-one else is more explicit I'll look for a reference tomorrow.

For the record, off-list John Cremona pointed me to "Fast Algorithms
for Linear Algebra mod N" by Storjohann and Mulders, where this is
called "stablization of p and q mod r" and there is an
(apparently efficient) algorithm given (for integers).

Thanks, John.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Cached method and inheritance

Hi Simon,

> On 28 Mai, 18:12, Florent Hivert <florent.hiv...@univ-rouen.fr> wrote:
> > Just to let you know, I tried the following work around:
> >
> > ...
> > but since A.toto.f.__name__ is still toto. It doesn't work. However the
> > following works (on unpatched sage-4.6.2):
> >
> > def change_name(fun, name):
> >     fun = copy(fun)
> >     fun.__name__ = name
> >     return fun
> >
> > class CC(A):
> >     toto_cached = cached_method(change_name(A.toto.f, "toto_cached"))
> >     def toto(self, arg=2):
> >         return self.toto_cached(arg)
>
> Note that my patch adds an optional argument "name" to the cached
> method decorator.

Excellent !

> So, your work-around is easily possible with my patch:
>
> sage: class A(SageObject):
> ....: @cached_method
> ....: def toto(self,arg):
> ....: return arg+1
> ....:
> sage: class CC(A):
> ....: toto_cached = cached_method(A.toto.f,name="toto_cached")
> ....: def toto(self,arg=2):
> ....: return self.toto_cached(arg)
> ....:
> sage: c = CC()
> sage: c.toto()
> 3
> sage: c.toto()
> 3
> sage: c.toto() is c.toto()
> True
>
> However, it is a work-around and not an actual solution, IMO.

I completely agree,

Florent

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Cached method and inheritance

Hi Florent,

On 28 Mai, 18:12, Florent Hivert <florent.hiv...@univ-rouen.fr> wrote:
> Just to let you know, I tried the following work around:
>
> ...
> but since A.toto.f.__name__ is still toto. It doesn't work. However the
> following works (on unpatched sage-4.6.2):
>
> def change_name(fun, name):
>     fun = copy(fun)
>     fun.__name__ = name
>     return fun
>
> class CC(A):
>     toto_cached = cached_method(change_name(A.toto.f, "toto_cached"))
>     def toto(self, arg=2):
>         return self.toto_cached(arg)

Note that my patch adds an optional argument "name" to the cached
method decorator.

So, your work-around is easily possible with my patch:

sage: class A(SageObject):
....: @cached_method
....: def toto(self,arg):
....: return arg+1
....:
sage: class CC(A):
....: toto_cached = cached_method(A.toto.f,name="toto_cached")
....: def toto(self,arg=2):
....: return self.toto_cached(arg)
....:
sage: c = CC()
sage: c.toto()
3
sage: c.toto()
3
sage: c.toto() is c.toto()
True

However, it is a work-around and not an actual solution, IMO.

Cheers,
Simon

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Cached method and inheritance

Hi Florent,

On 27 Mai, 23:16, Florent Hivert <florent.hiv...@univ-rouen.fr> wrote:
> Using the C class thing are even more weird:
>
> sage: c = C()
> sage: c.toto()
> [...]
> TypeError: toto() takes exactly 2 arguments (3 given)

I think I understand what happens in that case:

Inside c.toto(...), there is the line A.toto(self, arg). But A.toto
also is a CachedMethodCaller. If I understood correctly, the reason
for introducing that behaviour was in order to make cached methods
work with parent classes of categories, but I could be mistaken.

Anyway: The distinction of methods into "bound" and "unbound" methods
does currently not exist for cached methods.

Hence, if you call A.toto(self,arg) then indeed toto is called with
the three arguments A (a class), self (c, in this example), and arg.
But it expects only two arguments, namely "self" and "arg". Hence, the
error.

Cheers,
Simon

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Cached method and inheritance

Hi Simon,

> > But my patches do not solve the problem either -- only the error
> > message for b is different:
> > sage: b = B()
> > sage: b.toto()
> > 3
> > sage: b.toto()
> > Traceback (most recent call last):
> > ...
> > TypeError: toto() takes exactly 2 arguments (1 given)
> >
> > I can explain that example: If you call b.toto() the first time, then
> > the cached method defined in class A is called.
> > One of the things a cached method does with my patch is to replace
> > itself by a CachedMethodCaller (without the patch, the
> > CachedMethodCaller would be constructed over and over again, which is
> > a waste of time and may break the cache).
> > Hence, if you call b.toto() the second time, it becomes a different
> > method, expecting different arguments (the default argument is gone).
>
> Yes ! That's what I figured out.

Just to let you know, I tried the following work around:

class A(SageObject):
@cached_method
def toto(self, arg):
return arg+1
class CC(A):
toto_cached = cached_method(A.toto.f)
def toto(self, arg=2):
return self.toto_cached(arg)

but since A.toto.f.__name__ is still toto. It doesn't work. However the
following works (on unpatched sage-4.6.2):

def change_name(fun, name):
fun = copy(fun)
fun.__name__ = name
return fun

class CC(A):
toto_cached = cached_method(change_name(A.toto.f, "toto_cached"))
def toto(self, arg=2):
return self.toto_cached(arg)

I'll try with your patch as well.

Cheers,

Florent

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Cached method and inheritance

Hi Simon,

> just for clarification: What you are reporting is the behaviour or
> unpatched Sage, i.e., it is not caused by my patches from #11115,
> correct?

Sorry, for my unprecise bug report. I indeed had the problem with unpatched
sage 4.6.2.

> But my patches do not solve the problem either -- only the error
> message for b is different:
> sage: b = B()
> sage: b.toto()
> 3
> sage: b.toto()
> Traceback (most recent call last):
> ...
> TypeError: toto() takes exactly 2 arguments (1 given)
>
> I can explain that example: If you call b.toto() the first time, then
> the cached method defined in class A is called.
> One of the things a cached method does with my patch is to replace
> itself by a CachedMethodCaller (without the patch, the
> CachedMethodCaller would be constructed over and over again, which is
> a waste of time and may break the cache).
> Hence, if you call b.toto() the second time, it becomes a different
> method, expecting different arguments (the default argument is gone).

Yes ! That's what I figured out.

> I have some ideas how this could be solved: When A.toto is called from
> an instance b, it should test whether b.toto is actually defined in A
> or overridden in a subclass (so that it is either called directly or
> using "super"). If it is overridden, then it must not try to assign
> the CachedMethodCaller as an attribute to b. I'll try to implement it
> and update my patches at #11115.

Cool ! I'll follow it to help the review.

Cheers,

Florent

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Cached method and inheritance

Hi Florent,

just for clarification: What you are reporting is the behaviour or
unpatched Sage, i.e., it is not caused by my patches from #11115,
correct?

But my patches do not solve the problem either -- only the error
message for b is different:
sage: b = B()
sage: b.toto()
3
sage: b.toto()
Traceback (most recent call last):
...
TypeError: toto() takes exactly 2 arguments (1 given)

I can explain that example: If you call b.toto() the first time, then
the cached method defined in class A is called.
One of the things a cached method does with my patch is to replace
itself by a CachedMethodCaller (without the patch, the
CachedMethodCaller would be constructed over and over again, which is
a waste of time and may break the cache).
Hence, if you call b.toto() the second time, it becomes a different
method, expecting different arguments (the default argument is gone).

I have some ideas how this could be solved: When A.toto is called from
an instance b, it should test whether b.toto is actually defined in A
or overridden in a subclass (so that it is either called directly or
using "super"). If it is overridden, then it must not try to assign
the CachedMethodCaller as an attribute to b. I'll try to implement it
and update my patches at #11115.

However, I currently don't understand what happens in the case of
c.toto.

Best regards,
Simon

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: ptestlong failure for 4.7.rc4

I don't think 4.6.2.alpha1 -> 4.7 or 4.6.2.alpha1 -> 4.7.alpha2 would work, unless 4.6.2.alpha1 was released before Jeroen started his history-rewriting prereleases. Essentially each new version (prerelease or otherwise) is created by backtracking to the latest stable release and readding all the currently accepted patches. You can't upgrade from an alpha or rc because mercurial isn't smart enough to backtrack down the history tree and back up the rebuilt tree for the new version you're upgrading to - instead, it tries to "merge" your current dev version's tree with the new rebuilt tree. (This is because Jeroen's backtracking release pattern doesn't leave any information about how the trees are the same other than release version labels at points along the tree.) The reason it works when you're upgrading from a stable version is that all Jeroen's backtracking is going on in trees in "future history" from the perspective of your current stable sage version, i.e. above you, so Mercurial doesn't need to backtrack anywhere to climb up the latest tree.

Honestly I don't really see what the point of this backtracking is. Even if you want to unapprove patches that were accepted for a previous alpha version, that is essentially the exact purpose of the `hg backout` command.

-Keshav

----
Join us in #sagemath on irc.freenode.net !

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

วันศุกร์ที่ 27 พฤษภาคม พ.ศ. 2554

[sage-devel] Cached method and inheritance

Dear all,

First of all thanks to Simon for his optimization of the cached_method
decorator. Lots of code are now much faster. However it seems that there is a
problem using it with inheritance. I need to overload a cached method to
provide a default value for its argument. Here is a code reproducing the
problem:

class A(SageObject):
@cached_method
def toto(self, arg):
return arg+1
class B(A):
def toto(self, arg=2):
return super(B, self).toto(arg)
class C(A):
def toto(self, arg=2):
return A.toto(self, arg)

Then:

sage: b = B()
sage: b.toto()
3
sage: b.toto()
---------------------------------------------------------------------------
KeyError Traceback (most recent call last)

/home/data/Sage-Install/sage-4.6.2/devel/sage-combinat/sage/categories/<ipython console> in <module>()

/home/florent/src/Sage/sage/local/lib/python2.6/site-packages/sage/misc/cachefunc.pyc in __call__(self, *args, **kwds)
549 k = self._default_key
550 except AttributeError:
--> 551 k = self._default_key = self.get_key()
552 try:
553 return self.cache[k]

/home/florent/src/Sage/sage/local/lib/python2.6/site-packages/sage/misc/cachefunc.pyc in get_key(self, *args, **kwds)
601 if self._inst_in_key:
602 return (self._instance,self._argumentfixer.fix_to_pos(*args,**kwds))
--> 603 return self._argumentfixer.fix_to_pos(*args,**kwds)
604
605 def __get__(self, inst, cls=None):

/home/florent/src/Sage/sage/local/lib/python2.6/site-packages/sage/misc/function_mangling.so in sage.misc.function_mangling.ArgumentFixer.fix_to_pos (sage/misc/function_mangling.c:1423)()

KeyError: 'arg'


In this case, during the call super(B, self).toto(arg) the method b.toto is
replaced by an attribute which overload it.

Using the C class thing are even more weird:

sage: c = C()
sage: c.toto()
[...]
TypeError: toto() takes exactly 2 arguments (3 given)

So the question are: is this a known bug ? Is this expected ? Are there any
idea to solve the problem ?

Cheers,

Florent

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Versioning objects

Hi Kwankyu,

On 27 Mai, 18:10, Kwankyu Lee <ekwan...@gmail.com> wrote:
> How does Sage solve the following situation? A user stores objects pickled
> in Sage version X.1. Then a developer changes internal logic and data
> structure of the class of the objects for Sage version X.2. If we assume the
> developer's patch is merged to Sage X.2, then typically the user's objects
> fail to be unpickled in Sage X.2.

No. Typically they won't fail.

The reason is that the way an object is pickled has typically
*nothing* to do with the *internal* data structure. The serialisation
is based on some data (such as tuples of coefficients, strings that
provide a name, etc), and on an unpickling function that is able to
create an object out of the given data.

So, a pickle from version X.1 will only fail to be readable in version
X.2 if the *interface of the unpickling function* has changed.

> I think we should provide some infrastructure for the developer.

What's wrong with Python's and Cython's pickling infrastructure?

And also note that there are several tools in Sage to create unique
objects. These tools can not only be used for having "QQ['x'] is
QQ['x']", but they also provide pickling facilities, so that
"loads(dumps(P)) is P".

Example 1:
The module sage.structure.unique_representation.
In particular, consider the function
sage.structure.unique_representation.unpickle and the method
sage.structure.unique_representation.UniqueRepresentation.__reduce__


Example 2:
The module sage.structure.factory.
Cited from the documentation of that module:
The objects created are cached (using weakrefs) based on their key
and
returned directly rather than re-created if requested again.
Pickling
will return the same object for the same version of Sage, and
distinct
(but hopefully equal) objects for different versions of Sage.

Typically one only needs to implement create_key and
create_object.

Perhaps you'll like that versioning is addressed, e.g., by
sage.structure.factory.UniqueFactory.get_version. You may also like to
study existing applications of UniqueFactory. From within a sage
session, you may do Integers?? or InfinitePolynomialRing??, which are
two use cases of a unique factory.

> Simon answered to my similar question earlier. However, his answer was not
> sufficient for me to be satisfied.

For the record: That was a part of from
http://groups.google.com/group/sage-devel/browse_thread/thread/faef6072f805c9/c9f8860a647549c1

Cheers,
Simon

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org