Re: [sage-devel] Re: BUGS in tensor products of algebras
>
> I've created #24914.
>
IMO, would be better to have individual tickets for each file/issue as they
are independent. If you decide to do that, you can either keep #24914 as a
meta-ticket or recycle it as one of the tickets for one of the specific
issues.
> I will get around to it by the end of the week. I would appreciate
> pointers to where tensor() is defined
>
sage: import_statements(tensor)
from sage.categories.tensor import tensor
One of the most useful tools for development IMO. :)
> and how would one actually define an arbitrary ordering for pbw_basis.
>
>
There is the example in the PBW class and in the Verma modules code. The
API is you define a function that takes an index of the Lie algebra's basis
and returns a key object just like for Python's sorted() key parameter (in
fact, it essentially feeds it off to sorted()).
>> +1 You should also apply for funding as a participant for
>> SageDays@ICERM too.
>>
>
> Will do. Thanks!
>
It will be great to talk to you in person at both of these and work on
improving (Lie) algebras in Sage. :)
>
>
>>
>>>
> My objection is not only that pbw_basis() doesn't return a basis of L,
> but also that it returns algebra (with a preffered chosen basis).
>
I agree that it is not the best that it does not return a basis *of L*,
but there is fundamentally no difference between a basis of the UEA and
the
UEA in a distinguished basis (other than possibly the interface).
>>>
>>> There is a big conceptual difference between algebra and a basis of an
>>> algebra. For all practical purposes, pbw_basis() returns an object that
>>> behaves and is used, as far as I can see, as an algebra. I showed the
>>> current behavior to participants of SageDays93 and we all agreed that the
>>> current behavior of universal_enveloping_algebra() and pbw_basis() is
>>> confusing.
>>>
>>
>> I do not know how you presented it, but I feel that it a bit unfair to
>> say because you yourself had said you are confused by it. Also, the
>> pbw_basis() is not an algebra in the abstract concept but a class modeling
>> a chosen PBW basis of the UEA. So there is a lot more structure (and
>> limitations).
>>
>
> Sorry. I tried to be fair. I am attachign the notebook I used for
> demonstration.
>
I do not mean to suggest you did not try, but I just feel it is hard to be.
> Somebody actually proposed the same thing as Sebastian. Since, as you say,
>>> there are implementation difficulties with that approach, what about:
>>> universal_enveloping_algebra -> abstract_universal_enveloping_algebra &
>>> pbw_basis -> universal_enveloping_algebra? Another suggestion was pbw_basis
>>> -> universal_enveloping_algebra_with_pbw_basis.
>>>
>>
>> I believe that is completely unmanageable unless I am misunderstanding
>> something about your approach. You would require a (sub)class for each Lie
>> algebra that wanted to implement a different UEA that the PBW basis. Let me
>> say again that mathematics has a lot more freedom than computer
>> implementations; the canonical being the real numbers and formal power
>> series.
>>
>> Here is an idea based on one of your suggestions for how to have
>> universal_enveloping_algebra() be more, ahem, universal.
>>
>> def universal_enveloping_algebra(self, implementation=None, **kwds):
>> if implementation is None:
>> return self.lift.codomain()
>> elif implementation is "PBW":
>> return self.pbw_basis(**kwds)
>> else:
>> raise ValueError("invalid implementation")
>>
>> This way you can specify the implementation with having a default being
>> the (distinguished) one from _construct_UEA() and you get the PBW basis.
>> (Well, technically this would go in the LieAlgebrasWithBasis category and
>> the one in LieAlgebras would not have the extra PBW implementation elif.)
>>
>>
> I believe this is pretty much what I suggested on 23.2. The latter
> suggestions are merely renames of the current methods. I think the absolute
> minimum we should do is to rename pbw_basis to something like
> universal_enveloping_algebra_pbw That way the naming is not confusing and
> the feature is easily discoverable by the user. Merging these two methods
> in the way you propose is IMHO nicer API.
>
It is not in a couple of key areas. The biggest is that is gives you a hook
to have multiple implementations (say, as an NC poly ring, the PBW basis,
and some other class that is custom built for your purposes). It also has a
consistent API for those Lie algebras that may not have a distinguished
basis. Let me be clear, I am in no way proposing or suggesting removing
pbw_basis().
I also do not like the suggested change of the method name. It is too much
of a mouthful and does not offer really any clarity IMO. Again, if we
rewrite L.pbw_basis() in function form of pbw_basis(L), wouldn't you prefer
that over universal_enveloping_algebra_pbw_basis(L)?
Re: [sage-devel] Re: Git push issues
> No problem. And this was a mistake *I* made. This is a side-effect I > did not consider and might want to think more about how to prevent... GitHub forbids using an ssh key twice. It seems the only reasonable thing to do. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Git push issues
On Tue, Mar 6, 2018 at 7:29 PM, Meghana.M Reddy wrote: > This was the mistake I made. It worked now. Thanks a lot for helping me out. No problem. And this was a mistake *I* made. This is a side-effect I did not consider and might want to think more about how to prevent... > On Tuesday, March 6, 2018 at 9:01:56 PM UTC+5:30, Eric Gourgoulhon wrote: >> >> Hi, >> >> Le mardi 6 mars 2018 13:17:56 UTC+1, Meghana.M Reddy a écrit : >>> >>> ! [remote rejected] HEAD -> t/24909/boruvka_algorithm_for_mst (hook >>> declined) >>> error: failed to push some refs to 'g...@trac.sagemath.org:sage.git' >>> >> >> The target on trac does not seem correct; the syntax of the push command >> should be >> >> git push trac HEAD:u/user_name/branch_name >> >> >> >> where user_name is the user name of your trac account. It seems that you >> used the ticket number instead (24909), which of course, is not a valid user >> name. If you want the latter to appear, you should put it after the >> user_name: >> >> >> >> git push trac HEAD:u/user_name/24909/branch_name >> >> Best wishes, >> >> Eric. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Git push issues
Dear Erik, I'm able to push my branch now. Thank you for your quick reply and helping me with the SSH key. Regards, Meghana On Tuesday, March 6, 2018 at 9:35:01 PM UTC+5:30, Erik Bray wrote: > > Hi Meghana, > > I've manually deleted your duplicate SSH key, so you should be able to > push again for now. > > Best, > E > > On Tue, Mar 6, 2018 at 5:02 PM, Erik Bray > wrote: > > There's also an issue that if you've made both a local account on the > > Trac server, and you have logged in with GitHub (i.e. your > > gh- username), and if you've saved the same SSH key with > > both accounts, then the push authorization scripts can fail. > > > > This is because "" and "gh-" are treated as > > distinct users. However, the way SSH authentication for git works is > > that your "username" is determined by your SSH key. So if two users > > have the same SSH key, it's arbitrary which user you get authenticated > > as when you authenticate to the git server. > > > > Please associate your SSH key with one account or the other, but not > > both (or use different SSH keys with each account). In most cases you > > don't even need both... > > > > On Tue, Mar 6, 2018 at 4:37 PM, Eric Gourgoulhon > wrote: > >> > >> Le mardi 6 mars 2018 16:31:56 UTC+1, Eric Gourgoulhon a écrit : > >>> > >>> > >>> The target on trac does not seem correct; the syntax of the push > command > >>> should be > >>> > >>> git push trac HEAD:u/user_name/branch_name > >>> > >>> > >> > >> For more details, see > >> > http://doc.sagemath.org/html/en/developer/manual_git.html#pushing-your-changes-to-a-ticket > > >> > >> Eric. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "sage-devel" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to sage-devel+...@googlegroups.com . > >> To post to this group, send email to sage-...@googlegroups.com > . > >> Visit this group at https://groups.google.com/group/sage-devel. > >> For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Git push issues
This was the mistake I made. It worked now. Thanks a lot for helping me out. On Tuesday, March 6, 2018 at 9:01:56 PM UTC+5:30, Eric Gourgoulhon wrote: > > Hi, > > Le mardi 6 mars 2018 13:17:56 UTC+1, Meghana.M Reddy a écrit : >> >> ! [remote rejected] HEAD -> t/24909/boruvka_algorithm_for_mst (hook >> declined) >> error: failed to push some refs to 'g...@trac.sagemath.org:sage.git' >> >> > The target on trac does not seem correct; the syntax of the push command > should be > > git push trac HEAD:u/user_name/branch_name > > > where user_name is the user name of your trac account. It seems that you > used the ticket number instead (24909), which of course, is not a valid > user name. If you want the latter to appear, you should put it after the > user_name: > > > git push trac HEAD:u/user_name/24909/branch_name > > Best wishes, > > Eric. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: lib*.so conflict
On Tue, Mar 6, 2018 at 5:20 PM, Ralf Stephan wrote:
> Very good. Doesn't it only work if the user not only has the library but
> also the respective headers, i.e., the corresponding xyz-devel package
> installed?
Depends on the package, but if one package is a build dependency of
another package then yes, most likely it will require the headers.
> On Tuesday, March 6, 2018 at 4:54:12 PM UTC+1, Erik Bray wrote:
>>
>> On Mon, Mar 5, 2018 at 12:02 PM, Dima Pasechnik wrote:
>> >
>> >
>> > On Monday, March 5, 2018 at 9:48:25 AM UTC, Ralf Stephan wrote:
>> >>
>> >> I'm interested in a fix because it prevents clean patchbot results on
>> >> OpenSuSE
>> >
>> >
>> > Erik has an implementation of such feature generically, on some recent
>> > open
>> > ticket.
>>
>> I didn't actually have a ticket up for this work yet, but I do now:
>> https://trac.sagemath.org/ticket/24919
>> It provides a simple (arguably...) mechanism for providing per-package
>> configure-time checks. I haven't gone and added that for every
>> package yet though, and it wouldn't be worth trying until an
>> agreed-upon mechanism is fully implemented first.
>>
>> But then we could, say, add a configure-time check for readline so
>> that Sage will stop building its own copy where it isn't necessary to.
>>
>>
>> >>> How to tell "configure" not to install the Sage-shipped version ? I
>> >>> think
>> >>> I am able to look at the configuration of the Sage-shipped packages
>> >>> for
>> >>> which this happens in order to understand what is done and
>> >>> clone/adapt the
>> >>> process. What are they ?
>> >>>
>> >>> What features are necessary in {libtinfo|libreadline|wwhatever} for
>> >>> Sage
>> >>> to run correcly (i. e. what should "configure" test) ?
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "sage-devel" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to sage-devel+...@googlegroups.com.
>> > To post to this group, send email to sage-...@googlegroups.com.
>> > Visit this group at https://groups.google.com/group/sage-devel.
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: lib*.so conflict
Very good. Doesn't it only work if the user not only has the library but
also the respective headers, i.e., the corresponding xyz-devel package
installed?
On Tuesday, March 6, 2018 at 4:54:12 PM UTC+1, Erik Bray wrote:
>
> On Mon, Mar 5, 2018 at 12:02 PM, Dima Pasechnik > wrote:
> >
> >
> > On Monday, March 5, 2018 at 9:48:25 AM UTC, Ralf Stephan wrote:
> >>
> >> I'm interested in a fix because it prevents clean patchbot results on
> >> OpenSuSE
> >
> >
> > Erik has an implementation of such feature generically, on some recent
> open
> > ticket.
>
> I didn't actually have a ticket up for this work yet, but I do now:
> https://trac.sagemath.org/ticket/24919
> It provides a simple (arguably...) mechanism for providing per-package
> configure-time checks. I haven't gone and added that for every
> package yet though, and it wouldn't be worth trying until an
> agreed-upon mechanism is fully implemented first.
>
> But then we could, say, add a configure-time check for readline so
> that Sage will stop building its own copy where it isn't necessary to.
>
>
> >>> How to tell "configure" not to install the Sage-shipped version ? I
> think
> >>> I am able to look at the configuration of the Sage-shipped packages
> for
> >>> which this happens in order to understand what is done and
> clone/adapt the
> >>> process. What are they ?
> >>>
> >>> What features are necessary in {libtinfo|libreadline|wwhatever} for
> Sage
> >>> to run correcly (i. e. what should "configure" test) ?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to sage-devel+...@googlegroups.com .
> > To post to this group, send email to sage-...@googlegroups.com
> .
> > Visit this group at https://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Git push issues
Hi Meghana, I've manually deleted your duplicate SSH key, so you should be able to push again for now. Best, E On Tue, Mar 6, 2018 at 5:02 PM, Erik Bray wrote: > There's also an issue that if you've made both a local account on the > Trac server, and you have logged in with GitHub (i.e. your > gh- username), and if you've saved the same SSH key with > both accounts, then the push authorization scripts can fail. > > This is because "" and "gh-" are treated as > distinct users. However, the way SSH authentication for git works is > that your "username" is determined by your SSH key. So if two users > have the same SSH key, it's arbitrary which user you get authenticated > as when you authenticate to the git server. > > Please associate your SSH key with one account or the other, but not > both (or use different SSH keys with each account). In most cases you > don't even need both... > > On Tue, Mar 6, 2018 at 4:37 PM, Eric Gourgoulhon > wrote: >> >> Le mardi 6 mars 2018 16:31:56 UTC+1, Eric Gourgoulhon a écrit : >>> >>> >>> The target on trac does not seem correct; the syntax of the push command >>> should be >>> >>> git push trac HEAD:u/user_name/branch_name >>> >>> >> >> For more details, see >> http://doc.sagemath.org/html/en/developer/manual_git.html#pushing-your-changes-to-a-ticket >> >> Eric. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sage-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sage-devel+unsubscr...@googlegroups.com. >> To post to this group, send email to sage-devel@googlegroups.com. >> Visit this group at https://groups.google.com/group/sage-devel. >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] can't install dot2tex package in Sage 8.1
On 2018-03-06 14:42, Vít Tuček wrote: I tried install dot2tex in Sage 8.1 How? Which command did you run? and got error building mpfr. Which error did you get exactly? See https://www.chiark.greenend.org.uk/~sgtatham/bugs.html -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Git push issues
There's also an issue that if you've made both a local account on the Trac server, and you have logged in with GitHub (i.e. your gh- username), and if you've saved the same SSH key with both accounts, then the push authorization scripts can fail. This is because "" and "gh-" are treated as distinct users. However, the way SSH authentication for git works is that your "username" is determined by your SSH key. So if two users have the same SSH key, it's arbitrary which user you get authenticated as when you authenticate to the git server. Please associate your SSH key with one account or the other, but not both (or use different SSH keys with each account). In most cases you don't even need both... On Tue, Mar 6, 2018 at 4:37 PM, Eric Gourgoulhon wrote: > > Le mardi 6 mars 2018 16:31:56 UTC+1, Eric Gourgoulhon a écrit : >> >> >> The target on trac does not seem correct; the syntax of the push command >> should be >> >> git push trac HEAD:u/user_name/branch_name >> >> > > For more details, see > http://doc.sagemath.org/html/en/developer/manual_git.html#pushing-your-changes-to-a-ticket > > Eric. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: lib*.so conflict
On Mon, Mar 5, 2018 at 12:02 PM, Dima Pasechnik wrote:
>
>
> On Monday, March 5, 2018 at 9:48:25 AM UTC, Ralf Stephan wrote:
>>
>> I'm interested in a fix because it prevents clean patchbot results on
>> OpenSuSE
>
>
> Erik has an implementation of such feature generically, on some recent open
> ticket.
I didn't actually have a ticket up for this work yet, but I do now:
https://trac.sagemath.org/ticket/24919
It provides a simple (arguably...) mechanism for providing per-package
configure-time checks. I haven't gone and added that for every
package yet though, and it wouldn't be worth trying until an
agreed-upon mechanism is fully implemented first.
But then we could, say, add a configure-time check for readline so
that Sage will stop building its own copy where it isn't necessary to.
>>> How to tell "configure" not to install the Sage-shipped version ? I think
>>> I am able to look at the configuration of the Sage-shipped packages for
>>> which this happens in order to understand what is done and clone/adapt the
>>> process. What are they ?
>>>
>>> What features are necessary in {libtinfo|libreadline|wwhatever} for Sage
>>> to run correcly (i. e. what should "configure" test) ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Git push issues
Le mardi 6 mars 2018 16:31:56 UTC+1, Eric Gourgoulhon a écrit : > > > The target on trac does not seem correct; the syntax of the push command > should be > > git push trac HEAD:u/user_name/branch_name > > > For more details, see http://doc.sagemath.org/html/en/developer/manual_git.html#pushing-your-changes-to-a-ticket Eric. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Git push issues
Hi, Le mardi 6 mars 2018 13:17:56 UTC+1, Meghana.M Reddy a écrit : > > ! [remote rejected] HEAD -> t/24909/boruvka_algorithm_for_mst (hook > declined) > error: failed to push some refs to 'g...@trac.sagemath.org:sage.git' > > The target on trac does not seem correct; the syntax of the push command should be git push trac HEAD:u/user_name/branch_name where user_name is the user name of your trac account. It seems that you used the ticket number instead (24909), which of course, is not a valid user name. If you want the latter to appear, you should put it after the user_name: git push trac HEAD:u/user_name/24909/branch_name Best wishes, Eric. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: BUGS in tensor products of algebras
Dne pátek 2. března 2018 0:08:46 UTC+1 Travis Scrimshaw napsal(a):
>
>
>
>>>
Free abelian monoid... Hmmm... What free abelian monoid?
sage: PBW.basis().keys().an_element()
PBW[alpha[1]]^2*PBW[alphacheck[1]]^2*PBW[-alpha[1]]^3
So PBW.basis() is _indexed_ by elements of the basis of PBW? I am sorry
for all these stupid questions but (as you can clearly see) I am confused
as hell.
>>>
>>> No, they are just have the same names. A good parallel would be the
>>> polynomial ring R = ZZ[x,y] in the natural basis. Here, R is the ZZ-algebra
>>> of the abelian monoid A = , and subsequently, the basis elements are
>>> indexed by elements in A. We can call the elements in the monoid , but
>>> that induces undue overhead on the programmer. For the PBW case, granted it
>>> is not a monoid algebra, so we cannot simply *coerce* in things from
>>> the indexing monoid (but of course, conversion is allowed), but the design
>>> is there. I would just be taking products of the algebra generators anyways
>>> and not worrying about constructing elements via the basis.
>>>
>>>
>>
>> Thank you for clarification. I checked and they are different objects.
>> They just have the same _repr_ string. Probably nothing to be done about
>> that.
>>
>
> The reason for that is somewhere between being natural and being lazy. The
> easiest way to implement the PBW basis was to pass the prefix to the
> underlying basis indexing set and not do any string parsing and replacing
> in the subclass of CombinatorialFreeModule. I also felt it was natural as I
> outlined above.
>
>>
>>
>>> I looked at the ticket and I have no idea what it is about.
>>>
>>> Right now, if we are trying to construct a monomial, we do not convert
>>> it into the indexing set of the basis and instead trust the user to do it.
>>> The ticket #18750 is about changing that.
>>>
>>
>> OK. I don't really understand the wording of the ticket. I checked the
>> example given there and it works and as far as I can tell it works as it
>> should. In my opinion, Sage should give errors when the user tries to input
>> something like
>>
>> C.basis()[(1,0)]
>>
>
> Not if the basis is indexed by tuples or the indexing set that takes
> tuples as input? You then put the burden on the user and double create the
> indexing elements (or worse, you force a containment test). Also, there is
> no reason why we should force the indexing set to be a subclass of Parent
> or be a callable object.
>
>>
>> I don't know enough about implementation details to see why any
>> performance hit there would matter. In case the speed is really needed
>> perhaps we could have another (private) method without the checks that
>> would be used in heavy calculations? Waiting few hours more for some
>> extensive calculations is definitely better than risking a worng output
>> because you somewhere made a transposition error (0, 1) -> (1, 0).
>>
>
> It is used in a tight loop (which this code can be), that can a few hours
> can actually be double the time it used to take.
>
>
>> sage: C.basis()
>>> Lazy family (Term map from Subsets of {0, 1} to The Clifford
>>> algebra of the Quadratic form in 2 variables over Rational Field
>>> with coefficients:
>>> [ 1 0 ]
>>> [ * 1 ](i))_{i in Subsets of {0, 1}}
>>>
>>> So it is expecting subsets and that the user will not input bad
>>> data. There is no reason for it to simplify and not a bug. Granted, we
>>> could put a check on the user input here, but there is a speed penalty
>>> as
>>> this can be a well-used code path internally. Moreover, ducktyping can
>>> also
>>> be useful. So we are fairly permissive here, but not without due cause
>>> IMO.
>>>
>>>
>> Pardon my ignorance, but If there is no simplification then what is
>> all this good for? It does simplify for universal enveloping algebra and
>> so
>> it should do it for Clifford algebras as well. Also I have a big issue
>> with
>> naming convention here. The method basis() does not produce a basis!
>>
>
> it is *bad input*. It does produce a basis, one indexed by *subsets*,
> not words/multisets. In math terms, if you have a sequence (x_i)_{i \in
> I},
> then want x_j, where j \notin I, then you have an error. With #18750,
> this
> input might instead raise an error. If you want to do that, then you can
> do
> this:
>
> sage: Q = QuadraticForm(QQ, 2, [1,0,1])
> sage: C = CliffordAlgebra(Q)
> sage: g = list(C.algebra_generators()); g
> [e0, e1]
> sage: prod(g[i] for i in [0,0,1,0,1,1,0,0])
> -e0*e1
>
> If you took your input and wrapped it with set:
>
> sage: set((1,1,0,1))
> {0, 1}
>
> which would be the other possible outcome with #18750.
>
But sets are unhashable so how do I actually input the correct
[sage-devel] can't install dot2tex package in Sage 8.1
Hi! I tried install dot2tex in Sage 8.1 and got error building mpfr. See the attached log. At first it actually failed with complaints about mpfr being too old (version 3.8 or something) so I did ./sage --package update mpfr 4.0.1 --url ftp://ftp.fu-berlin.de/unix/misc/sage/spkg/upstream/mpfr/mpfr-4.0.1.tar.bz2 Best regards, Vit -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. Attempting to download package mpfr-4.0.1 Downloading the Sage mirror list Searching fastest mirror 177ms: http://files.sagemath.org/ 4456ms: http://ftp.iitm.ac.in/sage/ 367ms: http://ftp.leg.uct.ac.za/pub/packages/sage/ 257ms: http://ftp.ntua.gr/pub/sagemath/ 842ms: http://ftp.riken.jp/sagemath/ 910ms: http://ftp.tsukuba.wide.ad.jp/software/sage/ 641ms: http://ftp.yz.yamagata-u.ac.jp/pub/math/sage/ 515ms: http://linorg.usp.br/sage/ 1476ms: http://mirror.aarnet.edu.au/pub/sage/ 942ms: http://mirror.hust.edu.cn/sagemath/ 112ms: http://mirror.switch.ch/mirror/sagemath/ 665ms: http://mirror.ufs.ac.za/sagemath/ 929ms: http://mirror.yandex.ru/mirrors/sage.math.washington.edu/ 174ms: http://mirrors-usa.go-parts.com/sage/sagemath/ 162ms: http://mirrors.mit.edu/sage/ 1727ms: http://mirrors.tuna.tsinghua.edu.cn/sagemath/ 2534ms: http://mirrors.ustc.edu.cn/sagemath/ 326ms: http://mirrors.xmission.com/sage/ 190ms: http://sage.mirror.garr.it/mirrors/sage/ 1288ms: http://sagemath.c3sl.ufpr.br/ 452ms: http://sagemath.mirror.ac.za/ 1912ms: http://sagemath.polytechnic.edu.na/ 128ms: http://www-ftp.lip6.fr/pub/math/sagemath/ 528ms: http://www.cecm.sfu.ca/sage/ 91ms: http://www.mirrorservice.org/sites/www.sagemath.org/ 149ms: https://mirror.koddos.net/sagemath/ 173ms: https://mirrors.sorengard.com/sage/ 206ms: https://mirrors.up.pt/pub/sage/ Fastest mirror: http://www.mirrorservice.org/sites/www.sagemath.org/ >>> Checking online list of optional packages. >>> Checking online list of experimental packages. >>> Checking online list of huge packages. Error: could not find a package matching mpfr-4.0.1 Try 'sage --package list' to see the available packages There is no package similar to mpfr-4.0.1 You can find further packages at http://files.sagemath.org/spkg/ Attempting to download package mpfr-4.0.1 >>> Checking online list of optional packages. >>> Checking online list of experimental packages. >>> Checking online list of huge packages. Error: could not find a package matching mpfr-4.0.1 Try 'sage --package list' to see the available packages There is no package similar to mpfr-4.0.1 You can find further packages at http://files.sagemath.org/spkg/ Attempting to download package mpfr-4.0.1 >>> Checking online list of optional packages. >>> Checking online list of experimental packages. >>> Checking online list of huge packages. Error: could not find a package matching mpfr-4.0.1 Try 'sage --package list' to see the available packages There is no package similar to mpfr-4.0.1 You can find further packages at http://files.sagemath.org/spkg/ Attempting to download package mpfr-4.0.1 >>> Checking online list of optional packages. >>> Checking online list of experimental packages. >>> Checking online list of huge packages. Error: could not find a package matching mpfr-4.0.1 Try 'sage --package list' to see the available packages There is no package similar to mpfr-4.0.1 You can find further packages at http://files.sagemath.org/spkg/ Attempting to download package mpfr-4.0.1 >>> Checking online list of optional packages. >>> Checking online list of experimental packages. >>> Checking online list of huge packages. Error: could not find a package matching mpfr-4.0.1 Try 'sage --package list' to see the available packages There is no package similar to mpfr-4.0.1 You can find further packages at http://files.sagemath.org/spkg/ Attempting to download package mpfr-4.0.1 >>> Checking online list of optional packages. >>> Checking online list of experimental packages. >>> Checking online list of huge packages. Error: could not find a package matching mpfr-4.0.1 Try 'sage --package list' to see the available packages There is no package similar to mpfr-4.0.1 You can find further packages at http://files.sagemath.org/spkg/ Attempting to download package mpfr-4.0.1 >>> Checking online list of optional packages. >>> Checking online list of experimental packages. >>> Checking online list of huge packages. Error: could not find a package matching mpfr-4.0.1 Try 'sage --package list' to see the available packages There is no packa
[sage-devel] Git push issues
Hi, I am new to sage and fairly new to git too. I am working on implementing an algorithm in Sage and I followed all the doc pages for setting up git trac. I have created a new ticket for the algorithm I implemented and would like to push my local branch to this ticket. The git trac push #TICKETNUM gave some issues, so I tried to do it "manually" as suggested in some older mails in this group. I tried the command - git push trac HEAD:u/24909/boruvka_algorithm_for_mst. I get the following error - Counting objects: 12, done. Delta compression using up to 4 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (12/12), 2.37 KiB | 0 bytes/s, done. Total 12 (delta 9), reused 0 (delta 0) remote: FATAL: W refs/heads/t/24909/boruvka_algorithm_for_mst sage gh-meghanamreddy DENIED by fallthru remote: error: hook declined to update refs/heads/t/24909/boruvka_algorithm_for_mst To g...@trac.sagemath.org:sage.git ! [remote rejected] HEAD -> t/24909/boruvka_algorithm_for_mst (hook declined) error: failed to push some refs to 'g...@trac.sagemath.org:sage.git' I tried to search in google and in the older mails in sage-devel group. Could not find a fix. Maybe this is a simple error and I'm not able to see through it, apologies. Thank you, Meghana M Reddy -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Make JupyterLab a standard package
On 2018-03-06 00:29, Samuel Lelièvre wrote: I opened a ticket to make JupyterLab a standard package: https://trac.sagemath.org/ticket/24904 Any opinions? Shouldn't it be an optional package first? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Asking for advice: differential operators in the global namespace
Thank you all for your answers! The conclusion is pretty clear: the differential operators will *not* be added to the global namespace at start, even less be added silently when a pseudo-Riemannian manifold is constructed. The only way to get them will be an explicit demand from the user, in the form of a Python import: from sage.manifolds.operators import * or even more explicitly: from sage.manifolds.operators import grad, div, curl, laplacian It seems pretty safe to keep the standard notations here (i.e. "grad" instead of "gradient" and "div" instead of "divergence"), because the context of the import is clearly that of differential geometry. If for some reason, the name "div" was already used, it remains possible to do from sage.manifolds.operators import div as divergence. Eric. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
