[sage-combinat-devel] (free) algebras
Hi!
Looking around the code recently, it seems to me that currently there are
several ways to access/implement free algebras. One option is
sage: F = FreeAlgebra(ZZ,3,'x')
sage: F
Free Algebra on 3 generators (x0, x1, x2) over Integer Ring
On the other hand, there is an example in
sage: A = AlgebrasWithBasis(ZZ).example()
sage: A
An example of an algebra with basis: the free algebra on the generators ('a',
'b', 'c') over Integer Ring
Which should be used in the long run?
In the example it is much easier to have access to the support
sage: A.an_element()
B[word: ] + 2*B[word: a] + 3*B[word: b]
sage: A.an_element().support()
[word: , word: a, word: b]
Is it already possible or would it be easy to implement a quotient of the free
algebra
by specifying relations between the generators?
Best,
Anne
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Refactoring of posets
On Mon, Mar 21, 2011 at 07:53:03PM -0700, Andrey Novoseltsev wrote: How about lt for and le for =? I think these are more standard. That is to follow the convention for operator.* and the .__*__ methods. That sounds good to me. Everybody ok? And just to make sure I understand it correctly: since elements are not aware of the poset, it means that I can have P1.lt(a,b) True P2.lt(b,a) True if, say, P2 is P1 with reversed order, correct? Precisely. As well as ab, or not. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] #7922 reviewer's patch
On Mon, Mar 21, 2011 at 07:58:59PM -0700, Daniel Bump wrote: I just pushed my changes on the Sage-Combinat queue. The code uses standard coercion now. Thanks! At the moment, I can say that after your patch, the code seems to be about the same speed as before, which is good. In theory, there was no ground for speed regression. It's good that practice confirms that :-) I won't touch the thing tomorrow, so feel free to fold all the 7922 patches together for a better overview. I won't fold it on the combinat queue, but if I agree with everything I'll repost it on the trac server. Whatever is practical to you. I just pushed another patch on top of the previous one. Now the weyl character ring knows that it is a subalgebra of the weight ring, with back and forth coercions / conversion (and no user interface change except for the new methods ambient/lift/retract): sage: A2 = WeylCharacterRing(A2) sage: x = -A2(2,1,1) - A2(2,2,0) + A2(3,1,0) sage: a2 = WeightRing(A2) sage: a2(x) a2(1,3,0) + a2(1,0,3) + a2(3,1,0) + a2(3,0,1) + a2(0,1,3) + a2(0,3,1) sage: A2(a2(x)) -A2(2,1,1) - A2(2,2,0) + A2(3,1,0) Note: for whatever it's worth, one can disable product_on_basis, and have the code still run. I did not check if that made any speed difference. Oh, and by the way I fixed a tiny bug which prevented one to construct the WeightRing of a reducible cartan type: sage: WeightRing(A1xA1) Traceback (most recent call last): File ipython console, line 1, in module File /opt/sage/local/lib/python2.6/site-packages/sage/combinat/root_system/weyl_characters.py, line 2523, in __init__ self._cartan_type = self._parent._cartan_type AttributeError: 'str' object has no attribute '_cartan_type' Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] promotion operator
Hi again! Is the promotion operator on arbitrary tableaux already in sage? I think I once implemented the promotion operator on rectangular tableaux as sage: t = Tableau([[1,2],[2,3]]) sage: t.promotion(2) [[1, 2], [3, 3]] sage: t [[1, 2], [2, 3]] There is also a strange promotion_operator which seems to add boxes to a tableau, but there is no explanation what it does. Perhaps it is a misnomer? def promotion_operator(self, i): EXAMPLES:: sage: t = Tableau([[1,2],[3]]) sage: t.promotion_operator(1) [[[1, 2], [3], [4]], [[1, 2], [3, 4]], [[1, 2, 4], [3]]] sage: t.promotion_operator(2) [[[1, 1], [2, 3], [4]], [[1, 1, 2], [3], [4]], [[1, 1, 4], [2, 3]], [[1, 1, 2, 4], [3]]] sage: Tableau([[1]]).promotion_operator(2) [[[1, 1], [2]], [[1, 1, 2]]] sage: Tableau([[1,1],[2]]).promotion_operator(3) [[[1, 1, 1], [2, 2], [3]], [[1, 1, 1, 2], [2], [3]], [[1, 1, 1, 3], [2, 2]], [[1, 1, 1, 2, 3], [2]]] TESTS:: sage: Tableau([]).promotion_operator(2) [[[1, 1]]] sage: Tableau([]).promotion_operator(1) [[[1]]] Best, Anne -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] promotion operator
There is also a strange promotion_operator which seems to add boxes to a tableau, but there is no explanation what it does. Perhaps it is a misnomer? This is part of the combinatorial definition of k-Schur functions. I believe what it does is add a horizontal i-strip in all possible ways, and then uses the symmetric group action on each of the resulting tableaux so that they all have partition weight. I do not know why it is called promotion. Yes, this is a misnomer! Best, Anne -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Refactoring of posets
Dear poset fans,
I posted below the current log of the patch. Altogether, I am
essentially done, except for looking at the antichains optimizations,
and a couple issues to be discussed now:
- Currently P.hasse_diagram() returns a graph G whose nodes are the
elements of P (wrapped as elements of P; so one needs to do
x.element to actually get the original element). This graph is still
in the HasseDiagram class. The issue is that HasseDiagram's expect
their vertices to be 0,1,...,n-1, so most of the extra methods just
break.
Option 1: P.hasse_diagram() returns a plain digraph
Option 2: P.hasse_diagram() returns the internal HasseDiagram, with
vertices labelled 0,1,...,n
What do you prefer? I personally vote for 2; as a user, that's what
I would expect.
Another question is whether we want the vertices P.hasse_diagram()
to be wrapped or not. And if we are unhappy with the situation, is
still time to change this?
- There are many methods that are duplicated, depending on whether we
go up or down (order_ideal / order_filter, ...). It would make sense
to factor out the code, by using an option like:
sage: P.order_ideal(direction=up)
(of course keeping P.order_filter as a backward compatibility alias)
I have already used such an option for some of the new methods. What
would be good names for this option and its possible values?
sage: P.order_ideal(ideal = 'up') # resp. 'down'
sage: P.order_ideal(direction = 'ideal') # resp. 'filter'
- Do we want panyuschev_complement to accept such an option?
If yes, should the option describe the direction of the ideal or of
its complement?
- Should methods like order_ideal, order_ideal_generators,
panyushev_complement return set's, tuple's, list's, or Set's?
Currently it's some sort of a mix. I could be convinced to use Sets,
but don't have a strong opinion.
- Does anyone care if the hash function for posets changes? Otherwise
we could just use the default implementation provided by UniqueRepresentation.
Cheers,
Nicolas
--
Highlights
==
- Adds new categories: Posets(), Lattices() and their finite variants
- Puts Posets(), Posets(n), Poset(...), LatticePoset(...) ... all in
the appropriate categories
- Fix a couple glitches caught by the generic tests (containment,
an_element, ...)
- Add unique representation to Posets
- Adds the following methods:
- order_ideal_generators, order_filter_generators
- is_poset_morphism, is_poset_isomorphism
- is_lattice_morphism
- panyushev_complement, panyushev_orbits
- Standardizes the comparison function names to P.lt(x,y) / le / gt / ge / ...
(TODO: finish)
- Changes the hash of poset elements to delegate the work to the hash
of the underlying element (typically much faster than using repr)
- Systematic renaming of __repr__ to _repr_ in all the Poset code
- Poset elements now have unique representation. This noticably
reduces the overhead of conversion from internal vertices and
elements. In the following an example posted by Christian on
sage-combinat-devel, P.antichains() used to take more than 6s before
the patch:
sage: P = Posets.DiamondPoset(18)
sage: %time A = P._hasse_diagram.antichains()
CPU times: user 0.63 s, sys: 0.00 s, total: 0.63 s
Wall time: 0.65 s
sage: %time A = P.antichains()
CPU times: user 1.05 s, sys: 0.02 s, total: 1.07 s
Wall time: 1.11 s
- As an experimental feature, one can construct facade posets::
sage: P = Poset(DiGraph({'d':['c','b'],'c':['a'],'b':['a']}),
... facade = True)
In this example, the elements of the posets remain plain strings::
sage: d,c,b,a = list(P)
sage: type(a)
type 'str'
Of course, those strings are not aware of `P`. So to compare two
such strings, one needs to query `P`::
sage: a b
True
sage: P.lt(a,b)
False
which models the usual mathematical notation `a_P b`.
Depends on: #10651 (empty set), #9065 (facade sets), #10938 (Set-issubset)
--
Nicolas M. Thiéry Isil nthi...@users.sf.net
http://Nicolas.Thiery.name/
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] (free) algebras
Hi Nicolas,
On Tue, Mar 22, 2011 at 12:54:44AM -0700, Anne Schilling wrote:
Looking around the code recently, it seems to me that currently there are
several ways to access/implement free algebras. One option is
sage: F = FreeAlgebra(ZZ,3,'x')
sage: F
Free Algebra on 3 generators (x0, x1, x2) over Integer Ring
On the other hand, there is an example in
sage: A = AlgebrasWithBasis(ZZ).example()
sage: A
An example of an algebra with basis: the free algebra on the generators ('a',
'b', 'c') over Integer Ring
Which should be used in the long run?
FreeAlgebra. But it should be refactored to use categories and to
accept any index set for the generators, as does the example. And it
would be best implemented as the algebra of the free monoid:
sage: FreeMonoid(3,['a','b','c']).algebra(QQ) # does not work ...
Then, it would in particular benefit from the features you
mentioned. There was a discussion about this in March 2010, but alas
nothing happened yet.
This would be slightly different from the current implementation of the free
algebra
as an example of AlgebrasWithBasis, right?
Is it already possible or would it be easy to implement a quotient
of the free algebra by specifying relations between the generators?
Unless Singular can provide something (but I guess that would be more
for skew-commutative algebras; Simon: can you confirm?), the proper
way to do this would be to use gap's KBMAG package. It should be
fairly straightforward, but not instantaneous either.
What about in monoids or the word code? Is it already possible there to
work in a quotient specifying certain relations?
Cheers,
Anne
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Refactoring of posets
Dear Nicolas, Impressive, your work on posets! ... - Currently P.hasse_diagram() returns a graph G whose nodes are the elements of P (wrapped as elements of P; so one needs to do x.element to actually get the original element). This graph is still in the HasseDiagram class. The issue is that HasseDiagram's expect their vertices to be 0,1,...,n-1, so most of the extra methods just break. Option 1: P.hasse_diagram() returns a plain digraph Option 2: P.hasse_diagram() returns the internal HasseDiagram, with vertices labelled 0,1,...,n What do you prefer? I personally vote for 2; as a user, that's what I would expect. I would probably prefer 2 as well. Another question is whether we want the vertices P.hasse_diagram() to be wrapped or not. And if we are unhappy with the situation, is still time to change this? If it is possible not to wrap them, I think this would be good. At least I ran into some problems when playing with posets in the past. Cheers, Anne -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] CoxeterGroup broken?
Hi, is CoxeterGroup broken, or is just something wrong on my computer with the chevie package? sage: W = CoxeterGroup(['A',4]) ... AttributeError: 'builtin_function_or_method' object has no attribute 'sage' Thanks, Christian -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] (free) algebras
On Tuesday, March 22, 2011 1:34:44 AM UTC-7, Nicolas M. Thiéry wrote:
Is it already possible or would it be easy to implement a quotient
of the free algebra by specifying relations between the generators?
Unless Singular can provide something (but I guess that would be more
for skew-commutative algebras; Simon: can you confirm?), the proper
way to do this would be to use gap's KBMAG package. It should be
fairly straightforward, but not instantaneous either.
I don't know anything about KBMAG; I should look into that. Meanwhile,
Singular does let you define certain quotients of free algebras. See
http://www.singular.uni-kl.de/Manual/3-1-0/sing_404.htm. In Sage, I can
define a GF(2)-algebra S to be the free algebra on x and y subject to the
relation [x,y] = y^2:
sage: singular.LIB('ncall.lib')
sage: R=singular.ring(2,'(x,y)')
sage: C = singular.matrix(2, 2, '(1,1,1,1)')
sage: D = singular.matrix(2, 2, '(0, y*y, 0, 0)')
sage: S = C.nc_algebra(D)
sage: S.set_ring()
sage: x = singular('x')
sage: y = singular('y')
sage: x*y
x*y
sage: y*x
x*y+y^2
There are limitations on the sorts of algebras which can be defined this way
-- I think they need to have a PBW basis, basically -- see
http://www.singular.uni-kl.de/Manual/3-1-0/sing_420.htm#SEC461 -- but
Singular does give you some quotients of free algebras.
--
John
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] (free) algebras
On Tue, 22 Mar 2011 11:22:28 -0700 (PDT)
John H Palmieri jhpalmier...@gmail.com wrote:
On Tuesday, March 22, 2011 1:34:44 AM UTC-7, Nicolas M. Thiéry wrote:
Is it already possible or would it be easy to implement a quotient
of the free algebra by specifying relations between the
generators?
Unless Singular can provide something (but I guess that would be
more for skew-commutative algebras; Simon: can you confirm?), the
proper way to do this would be to use gap's KBMAG package. It
should be fairly straightforward, but not instantaneous either.
I don't know anything about KBMAG; I should look into that.
Meanwhile, Singular does let you define certain quotients of free
algebras. See
http://www.singular.uni-kl.de/Manual/3-1-0/sing_404.htm. In Sage,
I can define a GF(2)-algebra S to be the free algebra on x and y
subject to the relation [x,y] = y^2:
sage: singular.LIB('ncall.lib')
sage: R=singular.ring(2,'(x,y)')
sage: C = singular.matrix(2, 2, '(1,1,1,1)')
sage: D = singular.matrix(2, 2, '(0, y*y, 0, 0)')
sage: S = C.nc_algebra(D)
sage: S.set_ring()
sage: x = singular('x')
sage: y = singular('y')
sage: x*y
x*y
sage: y*x
x*y+y^2
There are limitations on the sorts of algebras which can be defined
this way -- I think they need to have a PBW basis, basically -- see
http://www.singular.uni-kl.de/Manual/3-1-0/sing_420.htm#SEC461 --
but Singular does give you some quotients of free algebras.
This is also accessible through the patch at #4539:
http://trac.sagemath.org/sage_trac/ticket/4539
Here is how you can do the example above with that patch:
sage: A.x,y = FreeAlgebra(QQ, 2)
sage: H = A.g_algebra({y*x: x*y + y^2})
sage: H.inject_variables()
sage: x*y
x*y
sage: y*x
x*y + y^2
Cheers,
Burcin
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: #7922 reviewer's patch
I won't fold it on the combinat queue, but if I agree with everything I'll repost it on the trac server. Whatever is practical to you. I added one small patch to the combinat queue, and in my own queue I folded the patches and posted to trac. I didn't qfold them on the combinat server simply because it is an irreversible process, but if you think it is better to have just one patch feel free to qfold. The sum of the following patches in the combinat queue: 91 A trac_7922-rebased-4.6.1 92 A trac_7922-doc.patch 93 A trac_7922-review-nt.patch 94 A trac_7922-revisions.patch 95 A trac_7922_coercion-nt.patch 96 A trac_7922-coercion2-nt.patch 97 A trac_7922-revisions2.patch equals the following patch on the trac server: trac_7922-rebased-4.7.alpha2.patch Dan -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-devel] Re: XCode 4
I tried to get Xcode 4 from the local Apps Store, and got The item you've requested is not currently available in the Singapore Store. Given that I read on the net about people actually buying it from this store, this is fishy... (Xcode 3 gets moved to /Applications/Developer-old/ when one installs Xcode 4, they say) On Mar 22, 11:20 am, Jason Grout jason-s...@creativetrax.com wrote: On 3/21/11 9:58 PM, kcrisman wrote: I only have the option to upgrade to 3.2.6 right now from Software Update, so it must be app-store only. Yes, app store, and $4.99 or something like that to boot. Though it's free if you already pay for their developer or iOS memberships. I can see this update potentially causing problems for the OS X App, if I understand the announcement correctly as being a major change in how things are built. I would strongly suggest testing that. Also, I think you can have more than one XCode at a time, right? I don't know. 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: bug with algebraic real field and partial_fraction_decomposition
This is now trac ticket #10981. On Mar 21, 12:46 pm, Pierre pierre.guil...@gmail.com wrote: noone really? shall I create a ticket? can anyone reproduce that bug? On 18 mar, 12:14, Pierre pierre.guil...@gmail.com wrote: sage: x= AA['x'].gen() sage: P= 1/(1+x^4) sage: P.partial_fraction_decomposition() ... ... AttributeError: 'sage.rings.complex_interval.ComplexIntervalFieldElement' object has no attribute 'lower' what's going on? -- 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/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Changing Complex Plot
What would people think about changing complex_plot.pyx in the following manner: ComplexPlot is changed so that the complex_to_rgb function is passed as a parameter on creation. The complex_plot function will then pass the currently defined complex_to_rgb to ComplexPlot when it is used. This allows different functions (currently complex_plot and Riemann_Map.plot_colored) to use their own coloring settings, or for hands on users to define and use their own coloring functions without having to modify the source? This also allows me to eliminate the redundancy in Riemann_Map. If this sounds like a good idea, I'll double check to make sure there are no significant performance ramifications. Ethan -- 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/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Changing Complex Plot
On Tue, Mar 22, 2011 at 1:52 PM, Ethan Van Andel evlu...@gmail.com wrote: What would people think about changing complex_plot.pyx in the following manner: ComplexPlot is changed so that the complex_to_rgb function is passed as a parameter on creation. The complex_plot function will then pass the currently defined complex_to_rgb to ComplexPlot when it is used. This allows different functions (currently complex_plot and Riemann_Map.plot_colored) to use their own coloring settings, or for hands on users to define and use their own coloring functions without having to modify the source? This also allows me to eliminate the redundancy in Riemann_Map. If this sounds like a good idea, I'll double check to make sure there are no significant performance ramifications. I think such a modification would make sense. As complex_to_rgb operates on the full array of values, there should be little to no overhead for passing it around. (Actually, custom ones could probably be written relatively efficiently in a vectorized format.) - 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Specify patches and dependencies in description
To all Sage developers: In the future, please make sure to put information like apply only this patch or this patch depends on that ticket or this is the URL for the new spkg in the ticket *description* as opposed to a ticket comment. I don't have time to read all 50 comments of every ticket to check for this information. I would obviously prefer that the patchbot also only looks at the ticket description to force people not to use comments for this. Thanks, Jeroen. -- 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/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Specify patches and dependencies in description
On 3/22/11 4:28 PM, Jeroen Demeyer wrote: I would obviously prefer that the patchbot also only looks at the ticket description to force people not to use comments for this. That sounds reasonable. +1. 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Problem building sage from source
Hi, I'm unable to successfully build sage 4.6.2 from source on OS X 10.6.7. Everything in the build seems to work fine until the very end. Here is where the build starts complaining: Sage build/upgrade complete! spkg/pipestatus ./sage -docbuild all html 21 tee -a dochtml.log sphinx-build -b html -d /Volumes/Extra/jtyard/sage-4.6.2/devel/sage/ doc/output/doctrees/en/a_tour_of_sage/Volumes/Extra/jtyard/ sage-4.6.2/devel/sage/doc/en/a_tour_of_sage /Volumes/Extra/jtyard/ sage-4.6.2/devel/sage/doc/output/html/en/a_tour_of_sage Traceback (most recent call last): File /Volumes/Extra/jtyard/sage-4.6.2/local/bin/sphinx-build, line 6, in module import sage.all File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python2.6/site- packages/sage/all.py, line 319, in module sage.misc.lazy_import.save_cache_file() File lazy_import.pyx, line 779, in sage.misc.lazy_import.save_cache_file (sage/misc/lazy_import.c:4185) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 264, in move copy2(src, real_dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 100, in copy2 copystat(src, dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 77, in copystat os.chflags(dst, st.st_flags) OSError: [Errno 45] Operation not supported: '/nh/nest/u/jtyard/.sage/ _Volumes_Extra_jtyard_sage-4.6.2_devel_sage-main- lazy_import_cache.pickle' Build finished. The built documents can be found in /Volumes/Extra/ jtyard/sage-4.6.2/devel/sage/doc/output/html/en/a_tour_of_sage sphinx-build -b html -d /Volumes/Extra/jtyard/sage-4.6.2/devel/sage/ doc/output/doctrees/en/bordeaux_2008/Volumes/Extra/jtyard/ sage-4.6.2/devel/sage/doc/en/bordeaux_2008 /Volumes/Extra/jtyard/ sage-4.6.2/devel/sage/doc/output/html/en/bordeaux_2008 Traceback (most recent call last): File /Volumes/Extra/jtyard/sage-4.6.2/local/bin/sphinx-build, line 6, in module import sage.all File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python2.6/site- packages/sage/all.py, line 319, in module sage.misc.lazy_import.save_cache_file() File lazy_import.pyx, line 779, in sage.misc.lazy_import.save_cache_file (sage/misc/lazy_import.c:4185) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 264, in move copy2(src, real_dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 100, in copy2 copystat(src, dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 77, in copystat os.chflags(dst, st.st_flags) OSError: [Errno 45] Operation not supported: '/nh/nest/u/jtyard/.sage/ _Volumes_Extra_jtyard_sage-4.6.2_devel_sage-main- lazy_import_cache.pickle' Build finished. The built documents can be found in /Volumes/Extra/ jtyard/sage-4.6.2/devel/sage/doc/output/html/en/bordeaux_2008 sphinx-build -b html -d /Volumes/Extra/jtyard/sage-4.6.2/devel/sage/ doc/output/doctrees/en/constructions/Volumes/Extra/jtyard/ sage-4.6.2/devel/sage/doc/en/constructions /Volumes/Extra/jtyard/ sage-4.6.2/devel/sage/doc/output/html/en/constructions Traceback (most recent call last): File /Volumes/Extra/jtyard/sage-4.6.2/local/bin/sphinx-build, line 6, in module import sage.all File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python2.6/site- packages/sage/all.py, line 319, in module sage.misc.lazy_import.save_cache_file() File lazy_import.pyx, line 779, in sage.misc.lazy_import.save_cache_file (sage/misc/lazy_import.c:4185) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 264, in move copy2(src, real_dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 100, in copy2 copystat(src, dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 77, in copystat os.chflags(dst, st.st_flags) OSError: [Errno 45] Operation not supported: '/nh/nest/u/jtyard/.sage/ _Volumes_Extra_jtyard_sage-4.6.2_devel_sage-main- lazy_import_cache.pickle' Build finished. The built documents can be found in /Volumes/Extra/ jtyard/sage-4.6.2/devel/sage/doc/output/html/en/constructions sphinx-build -b html -d /Volumes/Extra/jtyard/sage-4.6.2/devel/sage/ doc/output/doctrees/en/developer/Volumes/Extra/jtyard/sage-4.6.2/ devel/sage/doc/en/developer /Volumes/Extra/jtyard/sage-4.6.2/devel/ sage/doc/output/html/en/developer Traceback (most recent call last): File /Volumes/Extra/jtyard/sage-4.6.2/local/bin/sphinx-build, line 6, in module import sage.all File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python2.6/site- packages/sage/all.py, line 319, in module sage.misc.lazy_import.save_cache_file() File lazy_import.pyx, line 779, in sage.misc.lazy_import.save_cache_file (sage/misc/lazy_import.c:4185) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 264, in move copy2(src, real_dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 100, in copy2 copystat(src, dst) File
[sage-devel] Easy review for someone - they I doubt they can check it!!
If someone has a few minutes, this should be an easy review, though you will probably have to accept what I say when I say it works. There's a problem building GNU patch on AIX. The patch at http://trac.sagemath.org/sage_trac/ticket/10979 just adds 4 lines to spkg-install, which disables debug information just on AIX. That's all there is too it. if [ x$UNAME = xAIX ] ; then CFLAGS=$CFLAGS -g0 export CFLAGS fi Perhaps someone can review the ticket. I doubt you will have access to an AIX system, but the ticket shows the error message and the successful build after the change. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Dave -- 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/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: XCode 4 : Apple works with Apple constantly...
On Mar 22, 7:43 pm, Dima Pasechnik dimp...@gmail.com wrote: I tried to get Xcode 4 from the local Apps Store, and got The item you've requested is not currently available in the Singapore Store. Given that I read on the net about people actually buying it from this store, this is fishy... I filed a case with Apple Store support, and got a reply that blah blah blah, Apple constantly works with its content providers to expand the iTunes Store's catalog. I couldn't resist replying: Xcode is an Apple's own application! Should Apple work more with Apple, is this what you are saying? Corporate screw-ups might sometimes can be amusing... (Xcode 3 gets moved to /Applications/Developer-old/ when one installs Xcode 4, they say) On Mar 22, 11:20 am, Jason Grout jason-s...@creativetrax.com wrote: On 3/21/11 9:58 PM, kcrisman wrote: I only have the option to upgrade to 3.2.6 right now from Software Update, so it must be app-store only. Yes, app store, and $4.99 or something like that to boot. Though it's free if you already pay for their developer or iOS memberships. I can see this update potentially causing problems for the OS X App, if I understand the announcement correctly as being a major change in how things are built. I would strongly suggest testing that. Also, I think you can have more than one XCode at a time, right? I don't know. 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] length of a symbolic expression??
In an ask.sagemath.org question [1], DSM found that since len(sqrt(2)) works, it causes matplotlib to assume that sqrt(2) is an iterable [2]. What is the use-case for having a length function for a symbolic expression, especially when you can't list that expression? sage: a=sqrt(2) sage: len(a) 2 sage: list(a) --- TypeError Traceback (most recent call last) /Users/grout/sage-trees/sage-4.7.alpha2/spkg/standard/matplotlib-1.0.1.p0/ipython console in module() TypeError: 'sage.symbolic.expression.Expression' object is not iterable The docs for a.__len__ say: Returns the number of arguments of this expression. and all it does is return self.number_of_operands(). To me, if len(a) works, then a should probably be iterable. Does anyone object if we depreciate the __len__ function on symbolic expressions, and instead point people to number_of_operands or len(a.operands())? Thanks, Jason [1] http://ask.sagemath.org/question/454/can-gridlines-be-painted-at-sqrt2 [2] I'm also sending a message to matplotlib (or Michael D. at Sage Days 29 :) to ask if they can check for iterability by either explicitly calling iter() or checking for to see if the object is an instance of collections.Iterable... -- 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/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Problem building sage from source
I don't really understand those error messages, but they look like they are only coming from the documentation builds. Can you start up Sage itself (i.e. do ./sage from the top-level sage directory)? -M. Hampton On Mar 22, 6:07 pm, jtyard jty...@gmail.com wrote: Hi, I'm unable to successfully build sage 4.6.2 from source on OS X 10.6.7. Everything in the build seems to work fine until the very end. Here is where the build starts complaining: Sage build/upgrade complete! spkg/pipestatus ./sage -docbuild all html 21 tee -a dochtml.log sphinx-build -b html -d /Volumes/Extra/jtyard/sage-4.6.2/devel/sage/ doc/output/doctrees/en/a_tour_of_sage /Volumes/Extra/jtyard/ sage-4.6.2/devel/sage/doc/en/a_tour_of_sage /Volumes/Extra/jtyard/ sage-4.6.2/devel/sage/doc/output/html/en/a_tour_of_sage Traceback (most recent call last): File /Volumes/Extra/jtyard/sage-4.6.2/local/bin/sphinx-build, line 6, in module import sage.all File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python2.6/site- packages/sage/all.py, line 319, in module sage.misc.lazy_import.save_cache_file() File lazy_import.pyx, line 779, in sage.misc.lazy_import.save_cache_file (sage/misc/lazy_import.c:4185) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 264, in move copy2(src, real_dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 100, in copy2 copystat(src, dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 77, in copystat os.chflags(dst, st.st_flags) OSError: [Errno 45] Operation not supported: '/nh/nest/u/jtyard/.sage/ _Volumes_Extra_jtyard_sage-4.6.2_devel_sage-main- lazy_import_cache.pickle' Build finished. The built documents can be found in /Volumes/Extra/ jtyard/sage-4.6.2/devel/sage/doc/output/html/en/a_tour_of_sage sphinx-build -b html -d /Volumes/Extra/jtyard/sage-4.6.2/devel/sage/ doc/output/doctrees/en/bordeaux_2008 /Volumes/Extra/jtyard/ sage-4.6.2/devel/sage/doc/en/bordeaux_2008 /Volumes/Extra/jtyard/ sage-4.6.2/devel/sage/doc/output/html/en/bordeaux_2008 Traceback (most recent call last): File /Volumes/Extra/jtyard/sage-4.6.2/local/bin/sphinx-build, line 6, in module import sage.all File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python2.6/site- packages/sage/all.py, line 319, in module sage.misc.lazy_import.save_cache_file() File lazy_import.pyx, line 779, in sage.misc.lazy_import.save_cache_file (sage/misc/lazy_import.c:4185) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 264, in move copy2(src, real_dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 100, in copy2 copystat(src, dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 77, in copystat os.chflags(dst, st.st_flags) OSError: [Errno 45] Operation not supported: '/nh/nest/u/jtyard/.sage/ _Volumes_Extra_jtyard_sage-4.6.2_devel_sage-main- lazy_import_cache.pickle' Build finished. The built documents can be found in /Volumes/Extra/ jtyard/sage-4.6.2/devel/sage/doc/output/html/en/bordeaux_2008 sphinx-build -b html -d /Volumes/Extra/jtyard/sage-4.6.2/devel/sage/ doc/output/doctrees/en/constructions /Volumes/Extra/jtyard/ sage-4.6.2/devel/sage/doc/en/constructions /Volumes/Extra/jtyard/ sage-4.6.2/devel/sage/doc/output/html/en/constructions Traceback (most recent call last): File /Volumes/Extra/jtyard/sage-4.6.2/local/bin/sphinx-build, line 6, in module import sage.all File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python2.6/site- packages/sage/all.py, line 319, in module sage.misc.lazy_import.save_cache_file() File lazy_import.pyx, line 779, in sage.misc.lazy_import.save_cache_file (sage/misc/lazy_import.c:4185) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 264, in move copy2(src, real_dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 100, in copy2 copystat(src, dst) File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python/shutil.py, line 77, in copystat os.chflags(dst, st.st_flags) OSError: [Errno 45] Operation not supported: '/nh/nest/u/jtyard/.sage/ _Volumes_Extra_jtyard_sage-4.6.2_devel_sage-main- lazy_import_cache.pickle' Build finished. The built documents can be found in /Volumes/Extra/ jtyard/sage-4.6.2/devel/sage/doc/output/html/en/constructions sphinx-build -b html -d /Volumes/Extra/jtyard/sage-4.6.2/devel/sage/ doc/output/doctrees/en/developer /Volumes/Extra/jtyard/sage-4.6.2/ devel/sage/doc/en/developer /Volumes/Extra/jtyard/sage-4.6.2/devel/ sage/doc/output/html/en/developer Traceback (most recent call last): File /Volumes/Extra/jtyard/sage-4.6.2/local/bin/sphinx-build, line 6, in module import sage.all File /Volumes/Extra/jtyard/sage-4.6.2/local/lib/python2.6/site- packages/sage/all.py, line 319, in module sage.misc.lazy_import.save_cache_file() File
