Re: [sage-devel] reddit'ers at it again discussing sage...
> > > Well, I think you didn't understand me or I don't understand you. > There is already numpy, scipy and matplotlib in Sage and there is no > obstruction whatsoever to use it. One has to turn off the preparser, > otherwise you might see really odd errors. > > I agree (probably needs better documentation). I would change the import directive for numpy to turn the preparser off and print a message about the preparser upon doing so (including how to turn it back on). Ironically, the best way to do this might be to use the preparser. Best, Travis -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: reddit'ers at it again discussing sage...
PS: On 2014-08-28, P Purkayastha wrote: > --=_Part_2178_941130182.1409191972645 > Content-Type: text/plain; charset=UTF-8 > > Never used slrn, so I am just guessing that your terminal might be lacking > in some aspect. Did you try urxvt? I just installed urxvt, and use it right now for writing this. However, the characters in the message to which I am replying here are still not shown nicely (although the message header says "Content-Type: text/plain; charset=UTF-8). What I see looks like =E4=BB=8A=E6=99= etc. Best regards, Simon > On Thursday, August 28, 2014 7:39:58 AM UTC+8, Simon King wrote: >> >> Hi all! >> >> On 2014-08-27, Francesco Biscani > >> wrote: >> >> On Wednesday, August 27, 2014 8:43:30 PM UTC+1, maldun wrote: >> >>> >> >>> With Ibus you can simply type every UTF-8 Character with ease like: >> =E2= >> >=88=9E, =CE=A3, >> >>> =E2=88=AB=EF=BD=86(=CE=B1)=EF=BD=84=CE=B1 using the well known latex >> com= >> > mands =3DD >> >>> =E4=BB=8A=E6=99=A9=E3=81=AF=E7=9A=86=E3=81=95 >> >>> >> >> >> > My browser was actually capable of rendering all that... What a time to >> be >> > alive! >> >> I use slrn to read the sage lists. In my ~/.slrnc, I have set utf8 >> encoding: >> charset display utf8 >> charset outgoing utf8 >> >> However, this is *not* enough to view anything meaningful in the text >> above. >> >> Can someone please give me a pointer how to make slrn capabable of >> reading the stuff above? >> >> Best regards, >> Simon >> >> > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: reddit'ers at it again discussing sage...
Hi! On 2014-08-28, P Purkayastha wrote: > Never used slrn, so I am just guessing that your terminal might be lacking > in some aspect. Did you try urxvt? Never heard of it before. A duckduckgo search tells that it is a terminal emulator. What can it do what konsole (that's what I'm using) or xterm or uxterm (which are installed on my laptop, too) can't? Best regards, Simon -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: How practical/useful would a native windows subset be?
Here's some idea about how to setup that connection (FTR I haven't tried them): - https://coderwall.com/p/yx23qw - http://askubuntu.com/questions/52147/how-can-i-access-apache-on-virtualbox-guest-from-host So the VM would just have a simple command-line style interface which tells the user what to do (and to exit out of Sage in order to use git and recompile it's Sage for more dev minded people). Best, Travis On Wednesday, August 27, 2014 12:35:32 PM UTC-7, Volker Braun wrote: > > On Wednesday, August 27, 2014 8:00:49 PM UTC+1, Travis Scrimshaw wrote: >> >> But running the VM surely has a speed penalty because it has to go >>> through that big fat layer of the VM? >>> >> > Virtual machines are extremely fast on somewhat-recent hardware due to > hardware support. Using the gui inside the VM is somewhat slow since it has > to go through the graphics emulation, but if you connect with the OS > browser its probably difficult to notice any speed difference. > > Of course the VM can't be much smaller than this if you want to be able to > develop inside it: > > $ du -sh Sage/ > 5.2G Sage/ > > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Power series normalisation
Hi Peter, sorry I removed a few lines from that email explaining that it may have been because Sage based its power series on the semantics observed in Pari that causes the issue. Not that it actually uses Pari. Anyhow, it looks like you'll probably have it sorted out before long. Bill. On Wednesday, 27 August 2014 20:32:30 UTC+2, Peter Bruin wrote: > > Hi Bill, > > > Fredrik and I found the following in Sage 6.3. > > sage: R. = PowerSeriesRing(ZZ) > > sage: S. = PowerSeriesRing(R) > > sage: x + O(x^4) + y + O(y^4) > > x + O(x^4) + y + O(y^4) > > sage: y + O(y^4) + x + O(x^4) > > x + y + O(y^4) > > I guess this comes from Pari defining: > > 0 == O(x^4) > > to be true. > > Sage currently implements power series on top of polynomials, not via > PARI (but I have been working on a different implementation based on > PARI series, see http://trac.sagemath.org/ticket/15601). > > Peter > > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: reddit'ers at it again discussing sage...
Never used slrn, so I am just guessing that your terminal might be lacking in some aspect. Did you try urxvt? On Thursday, August 28, 2014 7:39:58 AM UTC+8, Simon King wrote: > > Hi all! > > On 2014-08-27, Francesco Biscani > > wrote: > >> On Wednesday, August 27, 2014 8:43:30 PM UTC+1, maldun wrote: > >>> > >>> With Ibus you can simply type every UTF-8 Character with ease like: > =E2= > >=88=9E, =CE=A3, > >>> =E2=88=AB=EF=BD=86(=CE=B1)=EF=BD=84=CE=B1 using the well known latex > com= > > mands =3DD > >>> =E4=BB=8A=E6=99=A9=E3=81=AF=E7=9A=86=E3=81=95 > >>> > >> > > My browser was actually capable of rendering all that... What a time to > be > > alive! > > I use slrn to read the sage lists. In my ~/.slrnc, I have set utf8 > encoding: > charset display utf8 > charset outgoing utf8 > > However, this is *not* enough to view anything meaningful in the text > above. > > Can someone please give me a pointer how to make slrn capabable of > reading the stuff above? > > Best regards, > Simon > > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: reddit'ers at it again discussing sage...
Hi all! On 2014-08-27, Francesco Biscani wrote: >> On Wednesday, August 27, 2014 8:43:30 PM UTC+1, maldun wrote: >>> >>> With Ibus you can simply type every UTF-8 Character with ease like: =E2= >=88=9E, =CE=A3, >>> =E2=88=AB=EF=BD=86(=CE=B1)=EF=BD=84=CE=B1 using the well known latex com= > mands =3DD >>> =E4=BB=8A=E6=99=A9=E3=81=AF=E7=9A=86=E3=81=95 >>> >> > My browser was actually capable of rendering all that... What a time to be > alive! I use slrn to read the sage lists. In my ~/.slrnc, I have set utf8 encoding: charset display utf8 charset outgoing utf8 However, this is *not* enough to view anything meaningful in the text above. Can someone please give me a pointer how to make slrn capabable of reading the stuff above? Best regards, Simon -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
On 27 August 2014 22:29, Volker Braun wrote: > 𝙶𝑟℮𝖺𝔱 ℹ𝟃ℯ𝕒! > > > On Wednesday, August 27, 2014 8:43:30 PM UTC+1, maldun wrote: >> >> With Ibus you can simply type every UTF-8 Character with ease like: ∞, Σ, >> ∫ｆ(α)ｄα using the well known latex commands =D >> 今晩は皆さ >> > My browser was actually capable of rendering all that... What a time to be alive! -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
𝙶𝑟℮𝖺𝔱 ℹ𝟃ℯ𝕒! On Wednesday, August 27, 2014 8:43:30 PM UTC+1, maldun wrote: > > With Ibus you can simply type every UTF-8 Character with ease like: ∞, Σ, > ∫ｆ(α)ｄα using the well known latex commands =D > 今晩は皆さん > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Function for subposet search
On Fri, 22 Aug 2014, Nathann Cohen wrote: Does Sage has a function to check if poset A contains a subposet isomorphic to subposet B? Not... exactly. There is no Poset method that does that, but there is a DiGraph method that does that. But then, it depends on what you call a subposet of a poset. It seems that neither definition is not what I was thinking. In principle the function I want could be done with something like def has_isomorphic_subposet(A, B): for x in Subsets(A.list()): if A.subposet(x).is_isomorphic(B): return True return False which is of course extremely slow. In this definition i.e. lattice N_5 contains 4-element "diamond lattice". -- Jori Mäntysalo -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
On Wed, Aug 27, 2014 at 9:57 PM, maldun wrote: > Many of the Special functions still don't support direct input of numpy > arrays, and there are more points. Yes sure, that's the compatibility problem. It's normal that you cannot insert numpy arrays just anywhere :-) -- H -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
> > Well, I think you didn't understand me or I don't understand you. > There is already numpy, scipy and matplotlib in Sage and there is no > obstruction whatsoever to use it. One has to turn off the preparser, > otherwise you might see really odd errors. > > > Oversaw that comment ... No it's not only the preparser. Many of the Special functions still don't support direct input of numpy arrays, and there are more points. Not too long ago list_plot wasn't able to use numpy array one had to use .to_list() -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] How practical/useful would a native windows subset be?
On Wednesday, August 27, 2014, Volker Braun wrote: > On Wednesday, August 27, 2014 8:00:49 PM UTC+1, Travis Scrimshaw wrote: >> >> But running the VM surely has a speed penalty because it has to go >>> through that big fat layer of the VM? >>> >> > Virtual machines are extremely fast on somewhat-recent hardware due to > hardware support. Using the gui inside the VM is somewhat slow since it has > to go through the graphics emulation, but if you connect with the OS > browser its probably difficult to notice any speed difference. > > Of course the VM can't be much smaller than this if you want to be able to > develop inside it: > > $ du -sh Sage/ > 5.2G Sage/ > > One remark: that gets knocked almost in half if you use a compressed filesystem (btrfs or ZFS) like I do with SageMathCloud... > -- > 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 http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- William Stein Professor of Mathematics University of Washington http://wstein.org wst...@uw.edu -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
On Wed, Aug 27, 2014 at 9:12 PM, Travis Scrimshaw wrote: > I thought there was already something which you can do to turn the > preparsing off... Yes, there is. But imagine you are a new user! There is no way you can get from calling a function like this: >>> object.do_something(123) giving the stacktrace "error: argument must be an integer" to: "oh I see, that's the preparser". -- H -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [sage-release] You don't really think that Sage has failed, do you? (a comment about it)
The commenters outside sage-* are all blind. The mathematicians, if they can program, know nothing about Open Source and highly distributed development. The developers know nothing about what drives the choices in Sage. Students and enthusiasts grapple with both algebra and Python in Sage. And posters here think noone works specifically on what's missing in Sage! http://en.wikipedia.org/wiki/Blind_men_and_an_elephant -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
I know that, but it frightens me. I have no idea how to enter those characters ... Without knowing anything, I bluntly assume that Sage will have a Python-2-only policy for variable names. -- H Nothing simpler than that: https://code.google.com/p/ibus/wiki/LaTeX based on Ibus: https://code.google.com/p/ibus/ I have a normal US Keyboard Layout With Ibus you can simply type every UTF-8 Character with ease like: ∞, Σ, ∫ｆ(α)ｄα using the well known latex commands =D 今晩は皆さん -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
On Wed, Aug 27, 2014 at 10:45:52AM -0700, Volker Braun wrote: > sage: %preparse [on|off] > > Doesn't exist but would be easy enough to implement... On Wed, Aug 27, 2014 at 12:12:55PM -0700, Travis Scrimshaw wrote: > I thought there was already something which you can do to turn the > preparsing off... Definitely: sage: preparser(False) sage: 3^3 0 So, since we have a preparser, it should be easy to get rid of the leading '%', replace brackets by parenthesis, and replace 'off' by 'False'. The problem with this method would be to turn the preparser back to 'on' ;) Ciao, Thierry -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: How practical/useful would a native windows subset be?
On Wednesday, August 27, 2014 8:00:49 PM UTC+1, Travis Scrimshaw wrote: > > But running the VM surely has a speed penalty because it has to go through >> that big fat layer of the VM? >> > Virtual machines are extremely fast on somewhat-recent hardware due to hardware support. Using the gui inside the VM is somewhat slow since it has to go through the graphics emulation, but if you connect with the OS browser its probably difficult to notice any speed difference. Of course the VM can't be much smaller than this if you want to be able to develop inside it: $ du -sh Sage/ 5.2G Sage/ -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
On Wed, Aug 27, 2014 at 9:19 PM, maldun wrote: > Lacking numpy support is really one of the big flaws of Sage since > Numpy,Scipy et al form a marvelous Matlab replacement. Well, I think you didn't understand me or I don't understand you. There is already numpy, scipy and matplotlib in Sage and there is no obstruction whatsoever to use it. One has to turn off the preparser, otherwise you might see really odd errors. > And I hope truly that we get to Python 3 some time. Since Python has full > UTF8 support writing > if α < γ*ε: > return σ I know that, but it frightens me. I have no idea how to enter those characters ... Without knowing anything, I bluntly assume that Sage will have a Python-2-only policy for variable names. -- H -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
On Wednesday, August 27, 2014 8:19:06 PM UTC+1, maldun wrote: > > if α < γ*ε: > return σ > is not a dream anymore > A nightmare if you don't have a greek keyboard ;-) -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
On Wednesday, August 27, 2014 7:00:51 PM UTC+2, Harald Schilly wrote: > > > > On Wednesday, August 27, 2014 4:16:46 PM UTC+2, bluescarni wrote: >> >> My impression is that the Scipy-Numpy-Sympy ecosystem is a better fit >> than Sage, at least for numerical purposes. >> > > Mine too, and despite Sage lacking with updates there is nobody holding > you back from working with just that stack in Sage and access additional > features on demand. We should make sure that installing additional packages > via pip does work (hence, we have to update numpy/scipy and so on from time > to time to get pandas&co working) but besides that this is fine. > > There are only two major issues: > * compatibility: e.g. the .numpy() of a sage matrix gives you something > for numpy. one has to know that. > * out-of-the-box: The Sage preparser breaks an awful lot of things if you > do not know that it is transforming your input. Personally, I was never > very fond of it but I fully understand why it is there. > > Me dreaming: All of the above could be solved by yet another additional > sage spkg, which does not only add many of the numerical python libs, but > also changes some of the internals (like, disabling the preparser). The > actual question would be if that triggers any interest. I don't think so... > > --H > > +1 Lacking numpy support is really one of the big flaws of Sage since Numpy,Scipy et al form a marvelous Matlab replacement. And I hope truly that we get to Python 3 some time. Since Python has full UTF8 support writing if α < γ*ε: return σ is not a dream anymore Nevertheless the Sage notebook is really good to work in combination with Scipy since you can make a quite good presentation of your results -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
I thought there was already something which you can do to turn the preparsing off...IDK where I saw it IIRC. I do know you can remove the preparsing of Sage integers by doing something like: sage: Integer = int However +1 for having such a magic function. Best, Travis On Wednesday, August 27, 2014 10:45:52 AM UTC-7, Volker Braun wrote: > > sage: %preparse [on|off] > > Doesn't exist but would be easy enough to implement... > > > On Wednesday, August 27, 2014 6:00:51 PM UTC+1, Harald Schilly wrote: >> >> Me dreaming: All of the above could be solved by yet another additional >> sage spkg, which does not only add many of the numerical python libs, but >> also changes some of the internals (like, disabling the preparser). The >> actual question would be if that triggers any interest. I don't think so... >> >> -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] proposal: remove python spkg and use pip instead
On 2014-08-27 21:01, Julien Puydt wrote: but on a general basis people are quite welcoming of sensible contributions. Depends on the project. Whenever I think a patch is good for upstream, I do submit it upstream. My impression is that, unless upstream knows you personally, bug reports (even with patches) are often ignored. I'm not blaming those projects, but it makes the goal of having unpatched clean upstream sources much less realistic. Jeroen. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: How practical/useful would a native windows subset be?
Hi, Le 27/08/2014 21:00, Travis Scrimshaw a écrit : 2 - It's too big (I think it's something like 3+ GB) On my little ARM box where I have 16G for both chromeos and ubuntu, du -hc on the sage-6.3 directory says 3.9G. And on my amd64 box, the same command says 4.6G. I have no clue about the 700M difference. No VM in sight. No optional package. Snark on #sagemath -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] proposal: remove python spkg and use pip instead
Hi, Le 27/08/2014 20:53, Jeroen Demeyer a écrit : On 2014-08-27 18:24, Julien Puydt wrote: Push upstream-worthy patches upstream. And how exactly would one accomplish this? The usual way is: (*) for very small patches, just send a mail with the attached patch explaining it to the relevant developer mailing-list (*) for normal patches, open a bug report and attach the patch explaining it (*) for big changes, do all of the above, but also make available a repository of git/svn/whatever (the one most convenient to upstream maintainers) with a nice branch with tidy patches Of course, some upstreams might have more peculiar needs (don't start me on this...), but on a general basis people are quite welcoming of sensible contributions. Snark on #sagemath -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: How practical/useful would a native windows subset be?
> > > It seems this discussion about sage on windows surfaces periodically. > The virtual image is the most practical solution at the moment. > > My arguments: > a) a native windows port is not realistic. > b) cygwin needs constant care and code maintainance, New versions of sage > may or may not build. It has a speed penalty. > c) I built an andlinux version 3 years ago. This was not too hard and has > a good integration with the windows desktop on the surface. Under the hood > there are, like william stein mentioned, possible crashes, a speed penalty > (similar cygwin) and rough edges. The project is no longer maintained and > it is 32 bit only. > d) the speed penalty will also hit other colinux based versions, I guess > it is also only 32 bit. > > Arguments for the virtual image: > The virtual image has almost no speed penalty. It can always build on a > proven stable linux OS, so there is no extra cost for development. The size > should bot be a problem. Although a complete OS will not ship (not even > Puppy as mentioned) with 50 MB, it is possible to build a stable base OS > without desktop (no X) at around 50 - 70 MB - this size values refere to a > compressed image. This has not to be "Puppy" but can be e.g. Debian, or > probably Fedora. A few years ago I build Sage virtual machines around 400 > MB (compressed image), I estimate that today this could be around 700 - 800 > MB. A few years ago there was also "make stripped" build option which > should build a smaller, but full functional sage image, I don't know the > present stage of this developement. > But running the VM surely has a speed penalty because it has to go through that big fat layer of the VM? Unless we can make an extremely lightweight VM that primarily acts as a bridge between Sage and Windows (via the notebook or command-line). Couldn't we just take a Free-BSD or other feather-weight OS, make the appropriate changes to the kernel or installed packages, and ship that out? > The easiest approach to improve the user experience would be to write a > windows GUI to communicate with the VM over its commandline parameters. So > you can handle operation mode (headless mode, notebook), data transfer and > lots of other things. This could take care of most user inconveniences. > > For the installation process I once wrote a windows installer which > installed Virtualbox (if no Virtualbox or an older version was detected) > together with the the Sage VM, I think it even had some menu entries to > start the notebook etc. This should still work, although it is not tested > on windows 8. > > This is the link to the sage-windows thread about this combined installer: > https://groups.google.com/forum/#!topic/sage-windows/yoAcv8W5Fw0 > > unfortunately the download links over there don't work any more... > > To sum up, enduser experience of the VM approach could be improved quite > easily. > But whatever, everybody who is online can use the SageCloud. This should > take care for most users independent of OS. > IMO there are three big issues with the current Sage Windows VM: 1 - It's slow because it runs within the VM (which also causes some usability issues with multiple webpages by the OS setup); this also has high memory usage. 2 - It's too big (I think it's something like 3+ GB) 3 - You can't upgrade Sage or really work with different branches as far as I remember. To have such an easy way to get local versions of Sage running on Windows would be a major help for India, Japan, and South Korea -- when I was there last year giving some Sage demos, nearly everyone had a Windows laptop. (Although now I'd just refer them to SMC, but solid internet connections in India can be hit or miss.) Best, Travis -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] proposal: remove python spkg and use pip instead
On 2014-08-27 18:24, Julien Puydt wrote: Push upstream-worthy patches upstream. And how exactly would one accomplish this? -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] proposal: remove python spkg and use pip instead
On 27 August 2014 19:31, Vincent Delecroix <20100.delecr...@gmail.com> wrote: >> The subject of your email says "remove python spkg". That obviously >> cannot be done because > > I should have chosen "remove spkg that are just Python libraries and > use pip for them". I thought it was clear from the content of my > e-mail. It was clear to me :) if only because the alternative reading did not make sense! > > Vincent > > -- > 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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Power series normalisation
Hi Bill, > Fredrik and I found the following in Sage 6.3. > sage: R. = PowerSeriesRing(ZZ) > sage: S. = PowerSeriesRing(R) > sage: x + O(x^4) + y + O(y^4) > x + O(x^4) + y + O(y^4) > sage: y + O(y^4) + x + O(x^4) > x + y + O(y^4) > I guess this comes from Pari defining: > 0 == O(x^4) > to be true. Sage currently implements power series on top of polynomials, not via PARI (but I have been working on a different implementation based on PARI series, see http://trac.sagemath.org/ticket/15601). Peter -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] proposal: remove python spkg and use pip instead
> The subject of your email says "remove python spkg". That obviously > cannot be done because I should have chosen "remove spkg that are just Python libraries and use pip for them". I thought it was clear from the content of my e-mail. Vincent -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Project: add hundreds of contributors to sage
You don't need to know about that particular subcommand to develop, its just a bandaid until we have a better build system. There are plenty other git concepts and subcommands that can definitely be useful in certain circumstances, but aren't really necessary to work on a ticket. On Wednesday, August 27, 2014 4:08:23 PM UTC+1, kcrisman wrote: > > > > On Wednesday, August 27, 2014 8:33:24 AM UTC-4, Volker Braun wrote: >> >> yes it is... >> > > But it's not even in http://www.sagemath.org/doc/developer/git_trac.html > > Presumably the development of git trac should be pretty tightly connected > to that document. We keep telling people to read it, after all. > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Power series normalisation
Fredrik and I found the following in Sage 6.3. sage: R. = PowerSeriesRing(ZZ) sage: S. = PowerSeriesRing(R) sage: x + O(x^4) + y + O(y^4) x + O(x^4) + y + O(y^4) sage: y + O(y^4) + x + O(x^4) x + y + O(y^4) I guess this comes from Pari defining: 0 == O(x^4) to be true. Magma defines it to be false. So when the addition is done, it presumably creates the object O(x^4) at some point as an element of S, normalises it (which involves checking if it is equal to zero) and then nothing gets added. Surprisingly Pari/GP gets both of the above correct, even with its variant definition of equality. Bill. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] wrongly spelled package name
You just need to delete the corrupt pari tarball, it will be downloaded automatically the next time you run make. On Wednesday, August 27, 2014 5:05:12 PM UTC+1, Jeroen Demeyer wrote: > > Try re-downloading the tarball from > http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.1.tar.gz > > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
sage: %preparse [on|off] Doesn't exist but would be easy enough to implement... On Wednesday, August 27, 2014 6:00:51 PM UTC+1, Harald Schilly wrote: > > Me dreaming: All of the above could be solved by yet another additional > sage spkg, which does not only add many of the numerical python libs, but > also changes some of the internals (like, disabling the preparser). The > actual question would be if that triggers any interest. I don't think so... > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] taskforce: documentation
I've read most of the comments which did roll in in the last few days. One repeated topic was about the documentation. I'm curious if there is currently anyone working on improving it? I think the reference documentation is really good. But I can see a definite lack to make it more accessible to new users. Why not starting another branch and collect functionalities in a new way? I have some vague ideas how this could be done and I think it's actually not so complicated - technically. It's harder to get input from different areas and from those who already have experience in teaching Sage in order to produce something really useful. The cornerstones should be, in my eyes, that it is packaged and built along Sage, displayed in a modern web-browser, and all examples are doctested. -- H -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
On Wednesday, August 27, 2014 4:16:46 PM UTC+2, bluescarni wrote: > > My impression is that the Scipy-Numpy-Sympy ecosystem is a better fit than > Sage, at least for numerical purposes. > Mine too, and despite Sage lacking with updates there is nobody holding you back from working with just that stack in Sage and access additional features on demand. We should make sure that installing additional packages via pip does work (hence, we have to update numpy/scipy and so on from time to time to get pandas&co working) but besides that this is fine. There are only two major issues: * compatibility: e.g. the .numpy() of a sage matrix gives you something for numpy. one has to know that. * out-of-the-box: The Sage preparser breaks an awful lot of things if you do not know that it is transforming your input. Personally, I was never very fond of it but I fully understand why it is there. Me dreaming: All of the above could be solved by yet another additional sage spkg, which does not only add many of the numerical python libs, but also changes some of the internals (like, disabling the preparser). The actual question would be if that triggers any interest. I don't think so... --H -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: How practical/useful would a native windows subset be?
Am Mittwoch, 27. August 2014 11:17:59 UTC+2 schrieb wstein: > > I tried to port Sage to mingw once, back when it was easier (2006), > and failed already at building Python. > There was a huge page with hacks to maybe do it back then, but they > weren't working. > There's a stackoverflow question now about this problem: > > > http://stackoverflow.com/questions/15365249/build-python-with-mingw-and-gcc > > " Python does not build out of the box with MinGW, let alone for Win64." > > and another suggests this fork of Python 3.4 that's meant to build on > mingw: https://bitbucket.org/puqing/python-mingw > > but there are issues entitled "Build fails on mingw (msys)" down the > right side of the screen... > > On Wed, Aug 27, 2014 at 11:05 AM, Jean-Pierre Flori > wrote: > > > > > > On Wednesday, August 27, 2014 11:00:35 AM UTC+2, Jeroen Demeyer wrote: > >> > >> On 2014-08-27 10:22, Jean-Pierre Flori wrote: > >> > Note that cross-compiler running on linux and targetting mingw(64) > have > >> > been available since mingw(64) is. > >> Many packages in Sage do not support cross-compiling. For example, the > >> Python build toolchain does not really support cross-compiling. > > > > Sure, but GMP/MPIR/MPFR/FLINT do. > > You can even run testsuites using Wine64 :) > > > > -- > > 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 http://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > wst...@uw.edu It seems this discussion about sage on windows surfaces periodically. The virtual image is the most practical solution at the moment. My arguments: a) a native windows port is not realistic. b) cygwin needs constant care and code maintainance, New versions of sage may or may not build. It has a speed penalty. c) I built an andlinux version 3 years ago. This was not too hard and has a good integration with the windows desktop on the surface. Under the hood there are, like william stein mentioned, possible crashes, a speed penalty (similar cygwin) and rough edges. The project is no longer maintained and it is 32 bit only. d) the speed penalty will also hit other colinux based versions, I guess it is also only 32 bit. Arguments for the virtual image: The virtual image has almost no speed penalty. It can always build on a proven stable linux OS, so there is no extra cost for development. The size should bot be a problem. Although a complete OS will not ship (not even Puppy as mentioned) with 50 MB, it is possible to build a stable base OS without desktop (no X) at around 50 - 70 MB - this size values refere to a compressed image. This has not to be "Puppy" but can be e.g. Debian, or probably Fedora. A few years ago I build Sage virtual machines around 400 MB (compressed image), I estimate that today this could be around 700 - 800 MB. A few years ago there was also "make stripped" build option which should build a smaller, but full functional sage image, I don't know the present stage of this developement. The easiest approach to improve the user experience would be to write a windows GUI to communicate with the VM over its commandline parameters. So you can handle operation mode (headless mode, notebook), data transfer and lots of other things. This could take care of most user inconveniences. For the installation process I once wrote a windows installer which installed Virtualbox (if no Virtualbox or an older version was detected) together with the the Sage VM, I think it even had some menu entries to start the notebook etc. This should still work, although it is not tested on windows 8. This is the link to the sage-windows thread about this combined installer: https://groups.google.com/forum/#!topic/sage-windows/yoAcv8W5Fw0 unfortunately the download links over there don't work any more... To sum up, enduser experience of the VM approach could be improved quite easily. But whatever, everybody who is online can use the SageCloud. This should take care for most users independent of OS. Cheers emil -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] proposal: remove python spkg and use pip instead
Le 27/08/2014 18:09, Jeroen Demeyer a écrit : 1) we need to patch Python Push upstream-worthy patches upstream. Get rid of not upstream-worthy patches. It will solve *two* problems: (1) patching python (2) maintaining the patched python! Snark on #sagemath -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] proposal: remove python spkg and use pip instead
The subject of your email says "remove python spkg". That obviously cannot be done because 1) we need to patch Python 2) pip depends on Python, which would depend on pip... -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] wrongly spelled package name
On 27 August 2014 17:05, Jeroen Demeyer wrote:
> On 2014-08-27 17:50, John Cremona wrote:
>>
>> make all-sage
>> make[2]: Entering directory `/home/jec/sage/build'
>> /home/jec/sage/build/pipestatus "sage-spkg ${SAGE_SPKG_OPTS}
>> pari-2.7.1.p0 2>&1" "tee -a
>> /home/jec/sage/logs/pkgs/pari-2.7.1.p0.log"
>> Found local metadata for pari-2.7.1.p0
>> Found local sources at /home/jec/sage/upstream/pari-2.7.1.tar.gz
>> Checksum: 7edec0dfefc5d0c47a7f1c2fb1016cfe313c1652 vs
>> 6f04c75c9f42e40a41a2aa8772d7b09b940e490c
>> Invalid checksum for /home/jec/sage/upstream/pari-2.7.1.tar.gz
>> make[2]: *** [/home/jec/sage/local/var/lib/sage/installed/pari-2.7.1.p0]
>> Error 1
>
>
> Try re-downloading the tarball from
> http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.1.tar.gz
>
> (you might have an older version of that tarball with the different
> checksum)
You got it! And I had in fact found that out myself. It should not
be allowed
Your other guess was also right -- that log file was a few weeks old.
I deleted it and now make is making merrily.
Jeroen, you're a hero!
John
>
>
> --
> 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 http://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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] wrongly spelled package name
On 2014-08-27 17:50, John Cremona wrote:
make all-sage
make[2]: Entering directory `/home/jec/sage/build'
/home/jec/sage/build/pipestatus "sage-spkg ${SAGE_SPKG_OPTS}
pari-2.7.1.p0 2>&1" "tee -a
/home/jec/sage/logs/pkgs/pari-2.7.1.p0.log"
Found local metadata for pari-2.7.1.p0
Found local sources at /home/jec/sage/upstream/pari-2.7.1.tar.gz
Checksum: 7edec0dfefc5d0c47a7f1c2fb1016cfe313c1652 vs
6f04c75c9f42e40a41a2aa8772d7b09b940e490c
Invalid checksum for /home/jec/sage/upstream/pari-2.7.1.tar.gz
make[2]: *** [/home/jec/sage/local/var/lib/sage/installed/pari-2.7.1.p0] Error 1
Try re-downloading the tarball from
http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.1.tar.gz
(you might have an older version of that tarball with the different
checksum)
--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] wrongly spelled package name
On 2014-08-27 17:50, John Cremona wrote: The following package(s) may have failed to build: package: database_cremona_ellcurves how can I find a place where database_cremona_ellcurve is spelled wrongly? Most likely, you once did $ ./sage -i database_cremona_ellcurves and the log file of the failed (since the package doesn't exist) build is still there. As long as you don't explicitly delete the log file, you will keep seeing the error message about it. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] wrongly spelled package name
After merging branches (details on request) I type "make" and it
quickly fails becuse I have an optional package installed and it
tried to do something about it with the wrong name. The branch I
merged is the one at #15767, upgrading pari to 2.7.1. (Am I right
that this is not in the current development branch?).
First problem:
make all-sage
make[2]: Entering directory `/home/jec/sage/build'
/home/jec/sage/build/pipestatus "sage-spkg ${SAGE_SPKG_OPTS}
pari-2.7.1.p0 2>&1" "tee -a
/home/jec/sage/logs/pkgs/pari-2.7.1.p0.log"
Found local metadata for pari-2.7.1.p0
Found local sources at /home/jec/sage/upstream/pari-2.7.1.tar.gz
Checksum: 7edec0dfefc5d0c47a7f1c2fb1016cfe313c1652 vs
6f04c75c9f42e40a41a2aa8772d7b09b940e490c
Invalid checksum for /home/jec/sage/upstream/pari-2.7.1.tar.gz
make[2]: *** [/home/jec/sage/local/var/lib/sage/installed/pari-2.7.1.p0] Error 1
Second problem:
Error building Sage.
The following package(s) may have failed to build:
package: database_cremona_ellcurves
*** note that the package name is in fact database_cremona_ellcurve
with no final s.
So, 2 questions: (1) how come after merging the branch at #15767
which has a positive review, I get the checksum mismatch? Ans (2) how
can I find a place where database_cremona_ellcurve is spelled wrongly?
John
--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [sage-release] You don't really think that Sage has failed, do you? (a comment about it)
Thanks for posting this. That said the big "SAGE must choose" question below doesn't actually make any sense given how sage is developed... On Wednesday, August 27, 2014, kcrisman wrote: > Interesting comment on the post on Facebook. Note the comment about > payment as well. > +++ > In my university, we have been using a sagenb server for three years. We > use it in Calculus/Algebra courses for mathematicians, electrical > ingenieers, agricultural ingenieers, etc. We really use a few basic > commands. If Sage has the 1% functionality or less than Magma, Mathematica, > etc, is not a problem for us. Our main problem is that the manual and > documentation are a mess, lacking of enough examples (please, why not do > something like Mathematica?). Anothe problem is the interface, for > instance, you can not select several cells and make copy/paste (I know this > is posible with sagemathcloud). Or for instance, it is difficult to avoid > that pupils share worksheets in a final individual test. With respect to > functionality we have problems with basic graphics (some of them fixed > today, to be fair). Still having problems solving basic inequalities. > Come on guys, SAGE has A LOT of possibilities that make it for > universities a better choice than Mathematica, Maple, etc. But you should > take care of interface, manuals and help and basic functionalities. I'm > sure that many universities would pay if flexible possibilities of payment > are allowed. > In my opinión SAGE has to choose: > 1. Focus on development of more and new specialiced functionalities. In > this case, its users will be a small group of researchers that don't care > how rough or how time consuming is to make a few instructions to work > properly. Besides, it will be difficult to obtain financing, thus you can > compete only in a Little specialized part (magma, mathematica, maple, GAP > all together is too ambicious). > 2. Focus on basic functionalities on calculus and basic algebra for > teaching. They need to be improved (the power of Maxima is poor in > inequalities, integrals, numeric series... it is not enough at all). They > need also to be user friendly and easy to learn. In this case maybe you can > obtain money from universities and with that money, maybe you can work on > quaternion algebras. > > -- > 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 http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- William Stein Professor of Mathematics University of Washington http://wstein.org wst...@uw.edu -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [sage-release] You don't really think that Sage has failed, do you? (a comment about it)
Hi everyone, I have been following part of this conversation and I think there is one aspect here that most of you are missing. Sage does not chose... Sage is not a mess on purpose, but it is developed by a big number of people and people develop what they need. So if all developers are researchers, then mostly research aspects are going to be developed, not interface and basic usage. I think most sage users agree that the interface could be made better but as nerd-mathematicians, we are not the ones qualified to do it (and we don't want to cause we don't have the time). There are two ways of solving this problem: more funding and more diverse users, which both imply a better interface so it looks like an infinite loop. The efforts that William Stein put into SageMathCloud are going into the right direction to leave the loop. He said so himself, he decided to put lots of effort into non-mathematical aspects that, I suppose, do not interest him that much, because he wants to reach more users. Doing so, we can reach non-researcher users, like teachers, who might want to contribute into a better documentation / interface. And of course, if SageMathCloud becomes a viable funding source, then some developers could be hired which would help. Choosing what aspect you want to improve only comes with funding. Otherwise, you can just take whatever people develop... 2014-08-27 17:09 GMT+02:00 kcrisman : > Interesting comment on the post on Facebook. Note the comment about > payment as well. > +++ > In my university, we have been using a sagenb server for three years. We > use it in Calculus/Algebra courses for mathematicians, electrical > ingenieers, agricultural ingenieers, etc. We really use a few basic > commands. If Sage has the 1% functionality or less than Magma, Mathematica, > etc, is not a problem for us. Our main problem is that the manual and > documentation are a mess, lacking of enough examples (please, why not do > something like Mathematica?). Anothe problem is the interface, for > instance, you can not select several cells and make copy/paste (I know this > is posible with sagemathcloud). Or for instance, it is difficult to avoid > that pupils share worksheets in a final individual test. With respect to > functionality we have problems with basic graphics (some of them fixed > today, to be fair). Still having problems solving basic inequalities. > Come on guys, SAGE has A LOT of possibilities that make it for > universities a better choice than Mathematica, Maple, etc. But you should > take care of interface, manuals and help and basic functionalities. I'm > sure that many universities would pay if flexible possibilities of payment > are allowed. > In my opinión SAGE has to choose: > 1. Focus on development of more and new specialiced functionalities. In > this case, its users will be a small group of researchers that don't care > how rough or how time consuming is to make a few instructions to work > properly. Besides, it will be difficult to obtain financing, thus you can > compete only in a Little specialized part (magma, mathematica, maple, GAP > all together is too ambicious). > 2. Focus on basic functionalities on calculus and basic algebra for > teaching. They need to be improved (the power of Maxima is poor in > inequalities, integrals, numeric series... it is not enough at all). They > need also to be user friendly and easy to learn. In this case maybe you can > obtain money from universities and with that money, maybe you can work on > quaternion algebras. > > -- > 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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: issues with pushout construction?
Hi Jonas, >>> I just realized that my example was maybe a bad one. But imagine >>> the same example for a space where the base ring _does_ coerce into >>> the space. A base-changed base ring would then not coerce, so the >>> pushout construction would be used and it would return the wrong >>> space, resp. my arguments would make more sense there, no? >> >> Do you mean something like the following? Assume you have a >> construction EvenSubspace() that applies to spaces of polynomials and >> returns the subspace of all polynomials that only have even powers of >> x. This of course includes constants. Suppose you have a ring >> homomorphism A -> B and you want to do >> >> pushout(B, EvenSubspace(PolynomialRing(A, 'x'))) > > Yes. I call this (implicit) "base change" where I mean "base" in the > sense of "base of construction" (which in many cases starts as a > ring). This assumes that the base object coerces into the constructed > object. The fact that you need this last assumption may be a sign that pushout() is not the right tool to do such a base change. An alternative would be to implement the base_extend() method (for the objects you are interested in) in such a way as to repeat the construction of that object with the new base ring. >> I guess my approach would indeed eliminate the application of >> EvenSubspace() because it doesn't know that B still coerces into >> EvenSubspace(PolynomialRing(B, 'x')). > > "1.1 + x^2" would e.g. fail resp. not lie in EvenSubSpace. Yes, exactly. >> If this is the case, the criterion for eliminating a >> "coercion-reversed" construction step F probably needs to be made >> more strict: if both of the original objects still coerce into the >> result of applying F, then we do want to apply F. Does that sound >> reasonable? > > I'm not sure. I was hoping for a simple system where it is clear what > happens. But since this would probably involve a partial redesign of > the pushout construction all-together and since so many things depend > on the old system I don't see this happening any time soon. :( Ideally (in my opinion), doing pushout(X, Y) would look for the most specific common category C in which X and Y are objects, and ask that category C to return the categorical push-out of X and Y in C (as an object Z with maps X -> Z and Y -> Z, which would then be used as coercion maps). But this is tricky: if X = ZZ[[x]] and Y = FF_p[x], then you first want to deduce that C is the category of commutative ZZ[x]-algebras, and to know that the push-out is the tensor product. Then you have to implement this tensor product in a sufficiently concrete way that it returns F_p[[x]] and not some abstract tensor product object. This is definitely not doable yet. > Regarding your suggestion/fix: > I'm not sure (as mentioned the pushout construction is complex and > there are many cases). But yes, that might work: > Do a/several coercion check(s) _during_ pushout (during the while loop > starting at line 3210) if needed instead of only at the end. > > So "coercion_reversed=False" (default) would mean that we assume that > the current base coerces into construction(base) and > "coercion_reversed=False" would mean that a coercion check should be > done. > > If yes: Maybe something like "force_coercion_check" fits better? That's an interesting suggestion. I'll try thinking about it a bit more to see if this is an improvement over coercion_reversed. > Note: That would actually work in general (always doing a coercion > check) but for performance reasons it's nice to only do it when > forced... Indeed, it makes no sense to do such a check for constructions of which you know that it is always going to succeed... Peter -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] proposal: remove python spkg and use pip instead
> > > It would greatly simplify the life of package maintainer! > > Just a +1 from me to this project. When I started the whole spkg > business, the state of Python package management was a total > mess/disaster. Today with pip things are much, much better. > Total +1 based on my experience with pip vs. easy_install, spkgs, etc. The very first thing I do when downloading a new Sage is install pip and put it to work... Nathan -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [sage-release] You don't really think that Sage has failed, do you? (a comment about it)
Interesting comment on the post on Facebook. Note the comment about payment as well. +++ In my university, we have been using a sagenb server for three years. We use it in Calculus/Algebra courses for mathematicians, electrical ingenieers, agricultural ingenieers, etc. We really use a few basic commands. If Sage has the 1% functionality or less than Magma, Mathematica, etc, is not a problem for us. Our main problem is that the manual and documentation are a mess, lacking of enough examples (please, why not do something like Mathematica?). Anothe problem is the interface, for instance, you can not select several cells and make copy/paste (I know this is posible with sagemathcloud). Or for instance, it is difficult to avoid that pupils share worksheets in a final individual test. With respect to functionality we have problems with basic graphics (some of them fixed today, to be fair). Still having problems solving basic inequalities. Come on guys, SAGE has A LOT of possibilities that make it for universities a better choice than Mathematica, Maple, etc. But you should take care of interface, manuals and help and basic functionalities. I'm sure that many universities would pay if flexible possibilities of payment are allowed. In my opinión SAGE has to choose: 1. Focus on development of more and new specialiced functionalities. In this case, its users will be a small group of researchers that don't care how rough or how time consuming is to make a few instructions to work properly. Besides, it will be difficult to obtain financing, thus you can compete only in a Little specialized part (magma, mathematica, maple, GAP all together is too ambicious). 2. Focus on basic functionalities on calculus and basic algebra for teaching. They need to be improved (the power of Maxima is poor in inequalities, integrals, numeric series... it is not enough at all). They need also to be user friendly and easy to learn. In this case maybe you can obtain money from universities and with that money, maybe you can work on quaternion algebras. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Project: add hundreds of contributors to sage
On Wednesday, August 27, 2014 8:33:24 AM UTC-4, Volker Braun wrote: > > yes it is... > But it's not even in http://www.sagemath.org/doc/developer/git_trac.html Presumably the development of git trac should be pretty tightly connected to that document. We keep telling people to read it, after all. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] reddit'ers at it again discussing sage...
There is again this point cropping up in the comments: "But Sage's mission is to be a viable alternative to Mathematica" This is being discussed tangentially in another sage-devel thread, but I think it's something to be considered carefully. There is a difference between saying "it is ok for Sage to develop in a direction which makes it a viable replacement for Matlab, Maple and Mathematica" and "Sage's mission statement is to be a viable alternative to MMMs". I think it creates false expectations and ultimately disillusion in potential users. My impression as a lurker on the mailing list is that Sage is heavily oriented towards the needs of the math research community and that not much effort is being put into other areas of scientific computing that might be of interest to physicists and engineers (which are heavy users of MMM). My impression is that the Scipy-Numpy-Sympy ecosystem is a better fit than Sage, at least for numerical purposes. All of this is of course all fine and dandy, but I think it should be stated more precisely (if that is really the case and not just my impression :). Cheers, Francesco. On 27 August 2014 14:06, William A Stein wrote: > > http://www.reddit.com/r/math/comments/2eo9ku/sage_open_source_mathematics_software_you_dont/ > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > wst...@uw.edu > > -- > 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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: issues with pushout construction?
On 27.08.2014 15:06, Peter Bruin wrote: Hi Jonas, I just realized that my example was maybe a bad one. But imagine the same example for a space where the base ring _does_ coerce into the space. A base-changed base ring would then not coerce, so the pushout construction would be used and it would return the wrong space, resp. my arguments would make more sense there, no? Do you mean something like the following? Assume you have a construction EvenSubspace() that applies to spaces of polynomials and returns the subspace of all polynomials that only have even powers of x. This of course includes constants. Suppose you have a ring homomorphism A -> B and you want to do pushout(B, EvenSubspace(PolynomialRing(A, 'x'))) Yes. I call this (implicit) "base change" where I mean "base" in the sense of "base of construction" (which in many cases starts as a ring). This assumes that the base object coerces into the constructed object. I guess my approach would indeed eliminate the application of EvenSubspace() because it doesn't know that B still coerces into EvenSubspace(PolynomialRing(B, 'x')). "1.1 + x^2" would e.g. fail resp. not lie in EvenSubSpace. If this is the case, the criterion for eliminating a "coercion-reversed" construction step F probably needs to be made more strict: if both of the original objects still coerce into the result of applying F, then we do want to apply F. Does that sound reasonable? I'm not sure. I was hoping for a simple system where it is clear what happens. But since this would probably involve a partial redesign of the pushout construction all-together and since so many things depend on the old system I don't see this happening any time soon. :( Regarding your suggestion/fix: I'm not sure (as mentioned the pushout construction is complex and there are many cases). But yes, that might work: Do a/several coercion check(s) _during_ pushout (during the while loop starting at line 3210) if needed instead of only at the end. So "coercion_reversed=False" (default) would mean that we assume that the current base coerces into construction(base) and "coercion_reversed=False" would mean that a coercion check should be done. If yes: Maybe something like "force_coercion_check" fits better? Note: That would actually work in general (always doing a coercion check) but for performance reasons it's nice to only do it when forced... Best Jonas -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] failing doctest for sage/structure/sage_object.pyx
OpenSuSE 12.3 ships with tar-1.26-14.1.1.x86_64.rpm according to http://download.opensuse.org/distribution/12.3/repo/oss/suse/x86_64/ On Wednesday, August 27, 2014 2:03:42 PM UTC+1, Jakob Kroeker wrote: > > > ./sage -sh -c "tar --version" # not 'sage -sh -c "tar --version"' - > multiple installations! > tells me the same (version 1.26) > > rpm -qf /bin/tar: > tar-1.26-11.1.x86_64 > > Interesting, but the error message is not in tar >> >> > For me it _is_ in 'tar' on that machine. When I grep the string from above > I get a hit for ' /bin/tar'. > Maybe 'tar' was patched by the local admin? > > I fixed the issue by installing 'tar' v1.28 from sources user-local. > > > > Jakob > > > Am Mittwoch, 27. August 2014 10:55:24 UTC+2 schrieb Volker Braun: >> >> Interesting, but the error message is not in tar (and, grepping through >> the tar git repo, has never been in Gnu tar). So you are using some other >> tar in the sage shell? >> >> sage -sh -c "tar --version" >> >> If that doesn't bring anything up, run the doctest under strace -ff and >> see which processes are being run. >> >> >> On Tuesday, August 26, 2014 11:44:47 PM UTC+1, Jakob Kroeker wrote: >>> >>> OS: >>> openSUSE 12.3 (x86_64) >>> VERSION = 12.3 >>> CODENAME = Dartmouth >>> >>> >tar --version >>> tar (GNU tar) 1.26 >>> >>> Am Dienstag, 26. August 2014 23:11:43 UTC+2 schrieb vdelecroix: What's your tar version? (ie what does answer the command "tar --version"). Looks like you have a very strange one. And, by the way, what is the system you are interested in? Might be useful to know for debugging... Vincent 2014-08-26 22:06 UTC+02:00, Jakob Kroeker : > > Hello, > > a doctest fails on an system I'm interested in (I want to run patchbot on > that system) > > File "src/sage/structure/sage_object.pyx", line 1411, in > sage.structure.sage_object.unpickle_allFailed example: > sage.structure.sage_object.unpickle_all() # (4s on sage.math, 2011) > Expected:doctest:... DeprecationWarning: This class is replaced by > Matrix_modn_dense_float/Matrix_modn_dense_double.See > http://trac.sagemath.org/4260 for details.Successfully unpickled ... > objects.Failed to unpickle 0 objects.Got:*** The old > options style (`tar fx ...`) is highly discouraged, please use the modern > form (leading dash before options).*** The standard way (with > expanded options; you can still bundle options) for your command would be: > tar -f - -x... > > Any idea about the cause/how to fix it? > > -- > 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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] proposal: remove python spkg and use pip instead
On Wed, Aug 27, 2014 at 3:29 PM, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > Hi, > > Now that pip is an optional spkg, I think it would be a good idea to: > 1) add some word about it in the documentation > 2) use it to replace some of the optional and experimental packages > I would like more comments (especially about 2) to see whether or not > it is a good idea. If it works, we might even move the pip spkg to > standard and use it during the build process. > > Running quickly through the list of optional packages, we can remove 4 of > them: > - beautiful soup > - pyopenssl > - pyqtx > - pyzmq > which just install nicely through pip. Could we keep backward > compatibility by setting a dependency to pip spkg and replace their > install script with "pip install PACKAGE"? > > For those three ones, we need to set extra options but it works as well: > - gnuplotpy > - nzmath > - pyx (need to use PyX==0.12.1, since it is the last one compatible > with python 2) > > And two packages just fail to install through pip. > - pybtex > - sip > > It would greatly simplify the life of package maintainer! Just a +1 from me to this project. When I started the whole spkg business, the state of Python package management was a total mess/disaster. Today with pip things are much, much better. William -- William Stein Professor of Mathematics University of Washington http://wstein.org wst...@uw.edu -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] proposal: remove python spkg and use pip instead
Hi, Now that pip is an optional spkg, I think it would be a good idea to: 1) add some word about it in the documentation 2) use it to replace some of the optional and experimental packages I would like more comments (especially about 2) to see whether or not it is a good idea. If it works, we might even move the pip spkg to standard and use it during the build process. Running quickly through the list of optional packages, we can remove 4 of them: - beautiful soup - pyopenssl - pyqtx - pyzmq which just install nicely through pip. Could we keep backward compatibility by setting a dependency to pip spkg and replace their install script with "pip install PACKAGE"? For those three ones, we need to set extra options but it works as well: - gnuplotpy - nzmath - pyx (need to use PyX==0.12.1, since it is the last one compatible with python 2) And two packages just fail to install through pip. - pybtex - sip It would greatly simplify the life of package maintainer! Vincent -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: issues with pushout construction?
Hi Simon On 27.08.2014 14:46, Simon King wrote: On 2014-08-27, Jonas Jermann wrote: I was talking/thinking about the implicit call of pushout when e.g. adding two elements from different parents... ... which is exactly what coercion is about. Hence, if your functorial construction does not yield a coercion from the start object to the resulting object O, then don't use ConstructionFunctor to describe the construction, and most importantly do not let O.construction() return this non-coercing construction. Put clearly: If O.construction() returns something that is not suitable for sage.categories.pushout.pushout, then it is a bug. Ok, you confirm what I thought: When using constructions it seems to be a prerequisite that the construction argument coerces into the constructed object. How would you then define the construction of modular/cusp forms rings/spaces over some base ring if not by a functor with argument base ring? But as I mentioned I made everything work in my case, I e.g. based the construction on a Facade of the base ring to distinguish the two but I don't consider this an elegant solution. :( It is not assumed that coercions are injective. In fact, a projection (say, from a ring to a quotient ring) will usually become a coercion. So if we add an element of a subspace with an element of the ambient space we get the projection of the sum? I would argue this is not the desired behavior in many situations. If you just have a subspace, then why do you think that an arbitrary (non-canonical!) projection would suddenly come into play? Of course, if something is constructed as a sub-structure, then the inclusion map is the only candidate for a coercion. Note that a pushout does not occur in this situation. It does if you add the elements. Example adding a modular form and a cusp form (lets say over a different base ring so pushout is really called). Or modular forms of weight k inside the ring of modular forms, etc. Those are "sub" and not "quotient" and we want to be able to add them. However, if you construct something as result of a particular projection (i.e., if you don't have a *sub* space but a *quotient* space), then it is desired to use this particular (and no other) projection as a coercion map. Yes, that makes sense. Ok, it was a simplification. I just feel uncomfortable if a function (pushout(A,B)) which is supposed to return a common parent of both fails to do that. If pushout(A,B) returns a parent C so that not both A and B coerce into C, then it's a bug. Ok, good we agree on that then. It is what happens currently for some parents, namely those that violate the above mentioned prerequisite... E.g. imagine an additional base change is involved, I think then pushout construction will be involved A base change is not dealt with by a construction functor, but by setting the coercion explicitly. This occurs, for example, with the space of symmetric functions. Here, you have one space without a particular choice of basis, and then you have different realisations of the space, each with a particular choice of a basis, and mutual coercions. However, no functorial construction (hence, no pushout) is involved: sage: A = SymmetricFunctions(QQ); A Symmetric Functions over Rational Field sage: S = A.schur(); S Symmetric Functions over Rational Field in the Schur basis sage: W = A.witt(); W Symmetric Functions over Rational Field in the Witt basis sage: W.has_coerce_map_from(S) True sage: S.has_coerce_map_from(W) True sage: S.construction() sage: W.construction() sage: A.construction() "RR(1) + some element of a space whose construction is based on ZZ" ^- This calls pushout(RR, constr(ZZ)) which should return constr(RR) which is in essence an implicit base change. The code of pushout/etc seems to indicate that this is intended and I think it is used for some/many(?) spaces. That's not my field of expertise, but it sounds like one shouldn't use a sage.categories.pushout.ConstructionFunctor to describe the construction of B by A. The construction may be functorial, but there is no ConstructionFunctor... What do you mean? Quite simply: Do not over-generalise. The pushout construction is a quite interesting part of Sage's coercion system, but many (perhaps most) coercions in real-life computations do not involve pushouts. I needed to generalize it, otherwise some very basic operations just fail. :-( Also sage forces one to define constructions, otherwise common parents won't be found. In any case, I have solved those issues for my implementation. I just wanted to raise my concern about the complex/seemingly contradictory behavior of pushout+constructions. But if everything is as it should be then that's fine by me (I have a "working" implementation). Best Jonas -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving
Re: [sage-devel] failing doctest for sage/structure/sage_object.pyx
./sage -sh -c "tar --version" # not 'sage -sh -c "tar --version"' - multiple installations! tells me the same (version 1.26) rpm -qf /bin/tar: tar-1.26-11.1.x86_64 Interesting, but the error message is not in tar > > For me it _is_ in 'tar' on that machine. When I grep the string from above I get a hit for ' /bin/tar'. Maybe 'tar' was patched by the local admin? I fixed the issue by installing 'tar' v1.28 from sources user-local. Jakob Am Mittwoch, 27. August 2014 10:55:24 UTC+2 schrieb Volker Braun: > > Interesting, but the error message is not in tar (and, grepping through > the tar git repo, has never been in Gnu tar). So you are using some other > tar in the sage shell? > > sage -sh -c "tar --version" > > If that doesn't bring anything up, run the doctest under strace -ff and > see which processes are being run. > > > On Tuesday, August 26, 2014 11:44:47 PM UTC+1, Jakob Kroeker wrote: >> >> OS: >> openSUSE 12.3 (x86_64) >> VERSION = 12.3 >> CODENAME = Dartmouth >> >> >tar --version >> tar (GNU tar) 1.26 >> >> Am Dienstag, 26. August 2014 23:11:43 UTC+2 schrieb vdelecroix: >>> >>> What's your tar version? (ie what does answer the command "tar >>> --version"). Looks like you have a very strange one. >>> >>> And, by the way, what is the system you are interested in? Might be >>> useful to know for debugging... >>> >>> Vincent >>> >>> 2014-08-26 22:06 UTC+02:00, Jakob Kroeker : >>> > >>> > Hello, >>> > >>> > a doctest fails on an system I'm interested in (I want to run patchbot >>> on >>> > that system) >>> > >>> > File "src/sage/structure/sage_object.pyx", line 1411, in >>> > sage.structure.sage_object.unpickle_allFailed example: >>> > sage.structure.sage_object.unpickle_all() # (4s on sage.math, 2011) >>> > Expected:doctest:... DeprecationWarning: This class is >>> replaced by >>> > Matrix_modn_dense_float/Matrix_modn_dense_double.See >>> > http://trac.sagemath.org/4260 for details.Successfully >>> unpickled ... >>> > objects.Failed to unpickle 0 objects.Got:*** The >>> old >>> > options style (`tar fx ...`) is highly discouraged, please use the >>> modern >>> > form (leading dash before options).*** The standard way (with >>> > expanded options; you can still bundle options) for your command would >>> be: >>> > tar -f - -x... >>> > >>> > Any idea about the cause/how to fix it? >>> > >>> > -- >>> > 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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: issues with pushout construction?
Hi Jonas, > I just realized that my example was maybe a bad one. But imagine the > same example for a space where the base ring _does_ coerce into the > space. A base-changed base ring would then not coerce, so the pushout > construction would be used and it would return the wrong space, > resp. my arguments would make more sense there, no? Do you mean something like the following? Assume you have a construction EvenSubspace() that applies to spaces of polynomials and returns the subspace of all polynomials that only have even powers of x. This of course includes constants. Suppose you have a ring homomorphism A -> B and you want to do pushout(B, EvenSubspace(PolynomialRing(A, 'x'))) I guess my approach would indeed eliminate the application of EvenSubspace() because it doesn't know that B still coerces into EvenSubspace(PolynomialRing(B, 'x')). If this is the case, the criterion for eliminating a "coercion-reversed" construction step F probably needs to be made more strict: if both of the original objects still coerce into the result of applying F, then we do want to apply F. Does that sound reasonable? Peter -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: issues with pushout construction?
Hi Jonas, On 2014-08-27, Jonas Jermann wrote: > All in all the pushout construction is rather complicated (there > are many cases/situations) and when implementing new spaces > one probably (unfortunately) has to look at the source / specific > implementation of pushout in detail to ensure everything works > appropriately in all cases. That's why construction functors are so rarely used. There are only 15 of them, including the SubspaceFunctor that should better be removed. Said in different words: The pushout construction is so complicated, since its *only* use case are complicated coercions situations. In all other situations, where the construction of a new parent is not needed, "simple" tools such as .register_coercion(), .register_embedding() and ._coerce_map_from_() are fully sufficient. Best regards, Simon -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: issues with pushout construction?
Hi Peter, On 2014-08-27, Peter Bruin wrote: >> Here you have a coercion from B to A, and thus no construction functor >> or pushout construction is involved. > > At least in the general setting of submodules and linear subspaces, > there is such a "functorial" construction, namely SubspaceFunctor, and > it does get used in pushout constructions. Really? Sure, that's a bug: sage: from sage.categories.pushout import SubspaceFunctor sage: M = ZZ^3 sage: F = SubspaceFunctor([M([1,2,3]),M([4,5,6])]) sage: F(ZZ^3).coerce_map_from(ZZ^3) is None True > I encountered this when > looking at #10513, and this was the reason for opening #16507. Thank you! Best regards, Simon -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: issues with pushout construction?
Hi Jonas, On 2014-08-27, Jonas Jermann wrote: > I was talking/thinking about the implicit call of pushout when e.g. > adding two elements from different parents... ... which is exactly what coercion is about. Hence, if your functorial construction does not yield a coercion from the start object to the resulting object O, then don't use ConstructionFunctor to describe the construction, and most importantly do not let O.construction() return this non-coercing construction. Put clearly: If O.construction() returns something that is not suitable for sage.categories.pushout.pushout, then it is a bug. >> It is not assumed that coercions are injective. In fact, a projection >> (say, from a ring to a quotient ring) will usually become a coercion. > > So if we add an element of a subspace with an element of the ambient > space we get the projection of the sum? I would argue this is not the > desired behavior in many situations. If you just have a subspace, then why do you think that an arbitrary (non-canonical!) projection would suddenly come into play? Of course, if something is constructed as a sub-structure, then the inclusion map is the only candidate for a coercion. Note that a pushout does not occur in this situation. However, if you construct something as result of a particular projection (i.e., if you don't have a *sub* space but a *quotient* space), then it is desired to use this particular (and no other) projection as a coercion map. > Ok, it was a simplification. I just feel uncomfortable if a function > (pushout(A,B)) which is supposed to return a common parent of both > fails to do that. If pushout(A,B) returns a parent C so that not both A and B coerce into C, then it's a bug. > E.g. imagine an additional base change is involved, > I think then pushout construction will be involved A base change is not dealt with by a construction functor, but by setting the coercion explicitly. This occurs, for example, with the space of symmetric functions. Here, you have one space without a particular choice of basis, and then you have different realisations of the space, each with a particular choice of a basis, and mutual coercions. However, no functorial construction (hence, no pushout) is involved: sage: A = SymmetricFunctions(QQ); A Symmetric Functions over Rational Field sage: S = A.schur(); S Symmetric Functions over Rational Field in the Schur basis sage: W = A.witt(); W Symmetric Functions over Rational Field in the Witt basis sage: W.has_coerce_map_from(S) True sage: S.has_coerce_map_from(W) True sage: S.construction() sage: W.construction() sage: A.construction() >> That's not my field of expertise, but it sounds like one shouldn't use a >> sage.categories.pushout.ConstructionFunctor to describe the construction >> of B by A. The construction may be functorial, but there is no >> ConstructionFunctor... > > What do you mean? Quite simply: Do not over-generalise. The pushout construction is a quite interesting part of Sage's coercion system, but many (perhaps most) coercions in real-life computations do not involve pushouts. Cheers, Simon -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: optional packages
2014-08-27 14:26 UTC+02:00, Volker Braun : > Fixed. > > The web server directory layout was not created as it should have been. > Fixed now. Hopefully Harald's new web site organization will be better ;-) Great. Many thanks! -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: issues with pushout construction?
Hi again I just realized that my example was maybe a bad one. But imagine the same example for a space where the base ring _does_ coerce into the space. A base-changed base ring would then not coerce, so the pushout construction would be used and it would return the wrong space, resp. my arguments would make more sense there, no? Best Jonas On 27.08.2014 14:27, Jonas Jermann wrote: On 27.08.2014 14:01, Peter Bruin wrote: What if there is no coercion in either direction? E.g. (base_ring, cusp forms ring) Maybe #16507 would make this work too if the CuspForms construction were implemented as a composition: ModularForms followed by CuspidalSubspace, where CuspidalSubspace would be a special case of SubspaceFunctor (i.e. with coercion_reversed=True in the terminology of #16507)? Then pushout() would remove the application of CuspidalSubspace when merging the two constructions. I still don't see how you would distinguish the base ring from a "normal" ring. Also, how would a base change work with your modification? pushout(RR, CuspidalSubSpace(ModularForms(ZZ))) resp. pushout(Base(RR), CuspidalSubSpace(ModularForms(Base(ZZ or If I understood it would do: ZZ -> ... -> RR -> ModularForms(RR) (and stop) resp. Base(ZZ) -> ... -> Base(RR) -> ModularForms(Base(RR)) (and stop) But instead it should return CuspidalSubSpace(ModularForms(RR)). What I mean is that in some cases the pushout construction should do "almost" the same as the construction itself but with coercion reversion the behavior would be completely different (since the "construction process" stops early). But maybe I missunderstood or this can still be solved in some smart way... I should also mention that in my case I have a whole bunch of "subspace constructions": cuspidal, holomorphic, weakly holomorphic, meromorphic Additional in each case modular or quasi modular and additional subspaces of the ambient spaces... In my case I used the above analytic properties as a parameter of the functor and let "merge" decide how to merge the analytic properties... Best Jonas -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Project: add hundreds of contributors to sage
yes it is...
On Wednesday, August 27, 2014 1:26:02 PM UTC+1, kcrisman wrote:
>
> I hope no one minds my resurrecting this, but after having spent a lot of
>> time waiting for Sage to rebuild itself 3 or 4 times, I just discovered
>> this hint, and would like to suggest it make its way onto
>> http://www.sagemath.org/doc/developer/trac.html#section-review-patches,
>> and all other similar pages in the developer guide.
>>
>> If that's already in the works, then never mind me; just carry on...
>>
>> john perry
>>
>> On Saturday, May 31, 2014 8:33:14 AM UTC-5, Volker Braun wrote:
>>>
>>> I've implemented a version of this now. From the README:
>>>
>>> * Review tickets with minimal recompiling. This assumes that you are
>>> currently on the "develop" branch, that is, the latest beta. Just
>>> checking out an older ticket would most likely reset the Sage tree
>>> to an older version, so you would have to compile older versions of
>>> packages to make it work. Instead, you can create an anonymous
>>> ("detached HEAD") merge of the ticket and the develop branch::
>>>
>>> $ git trac try 12345
>>>
> Volker, is this in the current git-trac?
>
--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [sage-release] You don't really think that Sage has failed, do you? (a comment about it)
> > > Bingo, please clarify. To me, "viable alternative" means just that. > > Frankly, why did you include Matlab if you care about research > > mathematicians? > > Dima's answered this well. > > Quoting on this thread: > Hey, a large proportion of applied maths (numerical analysis, optimisation) > research is done using Matlab. > E.g. Nick Trefethen (https://people.maths.ox.ac.uk/trefethen/) > was the 1st buyer of a Matlab license: > http://blogs.mathworks.com/community/2014/07/29/a-chat-with-chebfuns-nick-trefethen/ Thanks, that is interesting. I figured those folks would go straight to C or something else more hard-core. > > Why does "viable" not include useful for all sorts of > > research problems, not just some? > > It does. I'm just giving some concrete examples that I'm familiar > with. I welcome people in other areas of mathematics with similar > functional discrepancies to share the differences between what Sage > can do and what Ma* can do. > > I guess my point is that there is stuff Sage does well and better than the other guys too. As to attracting developers for small-audience research stuff: If you value your time at $X and the (say) Magma license is $Y, then unless Y is fairly close to X or you have an externality (such as a commitment to open source for math proofs) that lowers your utility when you use Magma, probably it will just be easier to use Magma. And the research algebra community is really not THAT big - certainly not of the people who are qualified, have time to work on code, and desire to. And for areas where research stuff in Sage has been thriving, no matter how low the (say) Magma license is, if it doesn't really have support for your field, better to start from scratch - which is a lot of what we've seen. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: issues with pushout construction?
Hi Peter, On 27.08.2014 14:01, Peter Bruin wrote: Hi Jonas, What if there is no coercion in either direction? E.g. (base_ring, cusp forms ring) Maybe #16507 would make this work too if the CuspForms construction were implemented as a composition: ModularForms followed by CuspidalSubspace, where CuspidalSubspace would be a special case of SubspaceFunctor (i.e. with coercion_reversed=True in the terminology of #16507)? Then pushout() would remove the application of CuspidalSubspace when merging the two constructions. I still don't see how you would distinguish the base ring from a "normal" ring. Also, how would a base change work with your modification? pushout(RR, CuspidalSubSpace(ModularForms(ZZ))) resp. pushout(Base(RR), CuspidalSubSpace(ModularForms(Base(ZZ or If I understood it would do: ZZ -> ... -> RR -> ModularForms(RR) (and stop) resp. Base(ZZ) -> ... -> Base(RR) -> ModularForms(Base(RR)) (and stop) But instead it should return CuspidalSubSpace(ModularForms(RR)). What I mean is that in some cases the pushout construction should do "almost" the same as the construction itself but with coercion reversion the behavior would be completely different (since the "construction process" stops early). But maybe I missunderstood or this can still be solved in some smart way... I should also mention that in my case I have a whole bunch of "subspace constructions": cuspidal, holomorphic, weakly holomorphic, meromorphic Additional in each case modular or quasi modular and additional subspaces of the ambient spaces... In my case I used the above analytic properties as a parameter of the functor and let "merge" decide how to merge the analytic properties... Best Jonas -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: optional packages
Fixed. The web server directory layout was not created as it should have been. Fixed now. Hopefully Harald's new web site organization will be better ;-) On Wednesday, August 27, 2014 11:33:19 AM UTC+1, vdelecroix wrote: > > ping... same problem with 6.4.beta1. > > PS: if there is something to do I can do it, but I do not know what it is. > > 2014-08-16 9:12 UTC+02:00, Vincent Delecroix <20100.d...@gmail.com > >: > > Hello, > > > > In sage-6.3 mcqd (merged in #16083) and pip (trac #16479) should be > > optional packages... but I can not see them with "sage -optional". > > Also "sage -i mcqd" or "sage -i pip" just fail. What is the procedure > > to get them on the sagemath server? > > > > Vincent > > > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Project: add hundreds of contributors to sage
>
> I hope no one minds my resurrecting this, but after having spent a lot of
> time waiting for Sage to rebuild itself 3 or 4 times, I just discovered
> this hint, and would like to suggest it make its way onto
> http://www.sagemath.org/doc/developer/trac.html#section-review-patches,
> and all other similar pages in the developer guide.
>
> If that's already in the works, then never mind me; just carry on...
>
> john perry
>
> On Saturday, May 31, 2014 8:33:14 AM UTC-5, Volker Braun wrote:
>>
>> I've implemented a version of this now. From the README:
>>
>> * Review tickets with minimal recompiling. This assumes that you are
>> currently on the "develop" branch, that is, the latest beta. Just
>> checking out an older ticket would most likely reset the Sage tree
>> to an older version, so you would have to compile older versions of
>> packages to make it work. Instead, you can create an anonymous
>> ("detached HEAD") merge of the ticket and the develop branch::
>>
>> $ git trac try 12345
>>
>>>
>>>
Volker, is this in the current git-trac?
--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] reddit'ers at it again discussing sage...
http://www.reddit.com/r/math/comments/2eo9ku/sage_open_source_mathematics_software_you_dont/ -- William Stein Professor of Mathematics University of Washington http://wstein.org wst...@uw.edu -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: issues with pushout construction?
Hi Jonas, > What if there is no coercion in either direction? > E.g. (base_ring, cusp forms ring) Maybe #16507 would make this work too if the CuspForms construction were implemented as a composition: ModularForms followed by CuspidalSubspace, where CuspidalSubspace would be a special case of SubspaceFunctor (i.e. with coercion_reversed=True in the terminology of #16507)? Then pushout() would remove the application of CuspidalSubspace when merging the two constructions. Peter -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: issues with pushout construction?
Hi Peter On 27.08.2014 13:03, Peter Bruin wrote: Hi Jonas, When I implemented Modular forms rings/spaces for Hecke triangle groups I ran into some issues with pushout / functors / constructions (correct me if I missunderstood something): Apparently the pushout construction implicitely assumes that there exists a coercion from the "construction argument" to the "construct": Ticket #16507 should solve this (at least to some extent) in situations where there is a coercion B -> A instead of A -> B. (Here B is the object resulting from a functorial construction applied to A; this can be used if B is a submodule of A, for example.) This won't address things like (base ring, cusp forms) -> (modular forms), though. Nice! I missed this ticket. This exactly addresses one of the issues I mentioned. I hope it can handle all possible complications (e.g. base changes, embeddings, etc). What if there is no coercion in either direction? E.g. (base_ring, cusp forms ring) My solution was to use a Facade of the base ring instead of the base ring itself and let it have an embedding into the base ring. Because embeddings are checked at the very beginning of the pushout construction (and only thanks to this) everything worked out. The important part above was that the facade is _not_ constructed from the base ring (otherwise we have again the same problem). All in all the pushout construction is rather complicated (there are many cases/situations) and when implementing new spaces one probably (unfortunately) has to look at the source / specific implementation of pushout in detail to ensure everything works appropriately in all cases. :-( Best Jonas -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: issues with pushout construction?
Hi On 27.08.2014 13:21, Simon King wrote: Hi Jonas, On 2014-08-27, Jonas Jermann wrote: There is supposed to be a coercion from A and B to C=pushout(A,B). But if e.g. B is constructed from A without having a coercion from A then the pushout will fail this (also see line 3217 of pushout.py). So either one severely restricts (functorial) constructions to "coercion"-compatible ones or the pushout construction fails even though there might be a very obvious candidate for pushout(A,B). Indeed, the pushout construction and the construction functors in sage.categories.pushout are an important tool to find coercion candidates. However, they are not supposed to be used for other "categorial" pushout constructions. I was talking/thinking about the implicit call of pushout when e.g. adding two elements from different parents... To avoid some misconceptions: Some examples that come to my mind: - All kinds of "projection" / non-injective constructions It is not assumed that coercions are injective. In fact, a projection (say, from a ring to a quotient ring) will usually become a coercion. So if we add an element of a subspace with an element of the ambient space we get the projection of the sum? I would argue this is not the desired behavior in many situations. - A = some graded ring, B = some homogeneous component of A Adding elements of A and B should give an element of A Here you have a coercion from B to A, and thus no construction functor or pushout construction is involved. Ok, it was a simplification. I just feel uncomfortable if a function (pushout(A,B)) which is supposed to return a common parent of both fails to do that. E.g. imagine an additional base change is involved, I think then pushout construction will be involved and the issue arises. Or are you sure that a situation "in spirit like above" never occurs/arises? - A = some base ring, B = the ring of cusp forms over A Adding elements of A and B should give an element of the ring of modular forms over A, however if B is constructed by A, then the pushout construction will always return B to which A does not coerce. That's not my field of expertise, but it sounds like one shouldn't use a sage.categories.pushout.ConstructionFunctor to describe the construction of B by A. The construction may be functorial, but there is no ConstructionFunctor... What do you mean? Best Jonas -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: issues with pushout construction?
Hi Simon, >> - A = some graded ring, B = some homogeneous component of A >>Adding elements of A and B should give an element of A > > Here you have a coercion from B to A, and thus no construction functor > or pushout construction is involved. At least in the general setting of submodules and linear subspaces, there is such a "functorial" construction, namely SubspaceFunctor, and it does get used in pushout constructions. I encountered this when looking at #10513, and this was the reason for opening #16507. Peter -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: issues with pushout construction?
Hi Jonas, On 2014-08-27, Jonas Jermann wrote: > There is supposed to be a coercion from A and B to C=pushout(A,B). > But if e.g. B is constructed from A without having a coercion from A > then the pushout will fail this (also see line 3217 of pushout.py). > > So either one severely restricts (functorial) constructions to > "coercion"-compatible ones or the pushout construction fails > even though there might be a very obvious candidate for pushout(A,B). Indeed, the pushout construction and the construction functors in sage.categories.pushout are an important tool to find coercion candidates. However, they are not supposed to be used for other "categorial" pushout constructions. To avoid some misconceptions: > Some examples that come to my mind: > > - All kinds of "projection" / non-injective constructions It is not assumed that coercions are injective. In fact, a projection (say, from a ring to a quotient ring) will usually become a coercion. > - A = some graded ring, B = some homogeneous component of A >Adding elements of A and B should give an element of A Here you have a coercion from B to A, and thus no construction functor or pushout construction is involved. > - A = some base ring, B = the ring of cusp forms over A >Adding elements of A and B should give an element of >the ring of modular forms over A, however if B is constructed >by A, then the pushout construction will always return B >to which A does not coerce. That's not my field of expertise, but it sounds like one shouldn't use a sage.categories.pushout.ConstructionFunctor to describe the construction of B by A. The construction may be functorial, but there is no ConstructionFunctor... Best regards, Simon -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: cgal spkg?
Hi Marc, I'm copying sage-devel where more experienced people can help. On Wed, 27 Aug 2014 11:42:45 +0200 Marc Masdeu wrote: > Dear Burcin, > > I saw you had made a spkg for the CGAL libraries. I would like to > resuscitate this code and adapt it to CGAL 4.0 if possible. Do you > have the spkg around and, if so, would you mind sharing it? That was a very long time ago. Since then, Sage has switched to a different build system where the package build scripts are hosted in the main repository. There are some instructions on the new system here: http://sagemath.org/doc/developer/packaging.html FWIW, I put the old spkg here temporarily: http://erocal.org/spkg/cgal-3.5.spkg Old system is described here: http://sagemath.org/doc/developer/packaging_old_spkgs.html Cheers, Burcin -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: help tracking bug with polynomials over finite fields
Hello Vincent,
You are probably right that it is the PARI -> Sage conversion that is
causing the bug. I added the following debugging statements:
diff --git a/src/sage/rings/polynomial/polynomial_element.pyx
b/src/sage/rings/polynomial/polynomial_element.pyx
index 4fe2d5c..b0676d7 100644
--- a/src/sage/rings/polynomial/polynomial_element.pyx
+++ b/src/sage/rings/polynomial/polynomial_element.pyx
@@ -3370,7 +3370,9 @@ cdef class Polynomial(CommutativeAlgebraElement):
elif is_FiniteField(R):
v = [x._pari_("a") for x in self.list()]
f = pari(v).Polrev()
+print('f = %s' % f) # PARI polynomial
G = list(f.factor())
+print('G = %s' % G) # PARI factorisation
elif is_NumberField(R):
if R.degree() == 1:
@@ -3470,6 +3472,7 @@ cdef class Polynomial(CommutativeAlgebraElement):
exps = G[1]
R = self.parent()
F = [(R(f), int(e)) for f, e in zip(pols, exps)]
+print("F = %s" % F) # PARI factorisation converted to Sage
if unit is None:
unit = self.leading_coefficient()
The first failure I is copy-pasted below. The PARI factorisation G is
exactly the same the first time (the failure) and the second time (the
double-checking). To make it look nicer:
gp > lift(lift(Mat(G)))
%2 =
[ x + 1 1]
[x + (a^7 + a^6 + a^5 + 2*a + 1) 1]
[x + (2*a^7 + 2*a^6 + 2*a^5 + a + 1) 1]
[x^5 + x^4 + 2*x^3 + x^2 + x + 1 1]
However, the Sage factorisation F is different. In fact, it appears
that the call to R(f) used in constructing F incorrectly converts the
factor x + (2*a^7 + 2*a^6 + 2*a^5 + a + 1) into T + (2*z^3 + z + 2).
Peter
f = Mod(Mod(2, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2,
3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^8 + Mod(Mod(2, 3), Mod(1, 3)*a^8 + Mod(2,
3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^7 +
Mod(Mod(2, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 +
Mod(2, 3)*a + Mod(2, 3))*x^5 + Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 +
Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^4 + Mod(Mod(1, 3),
Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a +
Mod(2, 3))
G = [[Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2,
3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x + Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2,
3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3)), Mod(Mod(1,
3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a
+ Mod(2, 3))*x + Mod(Mod(1, 3)*a^7 + Mod(1, 3)*a^6 + Mod(1, 3)*a^5 + Mod(2,
3)*a + Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2
+ Mod(2, 3)*a + Mod(2, 3)), Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 +
Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x + Mod(Mod(2, 3)*a^7
+ Mod(2, 3)*a^6 + Mod(2, 3)*a^5 + Mod(1, 3)*a + Mod(1, 3), Mod(1, 3)*a^8 +
Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3)),
Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 +
Mod(2, 3)*a + Mod(2, 3))*x^5 + Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 +
Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^4 + Mod(Mod(2, 3),
Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a +
Mod(2, 3))*x^3 + Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 +
Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^2 + Mod(Mod(1, 3), Mod(1, 3)*a^8 +
Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x +
Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 +
Mod(2, 3)*a + Mod(2, 3))]~, [1, 1, 1, 1]~]
F = [(T + 1, 1), (T + z^7 + z^6 + z^5 + 2*z + 1, 1), (T + 2*z^3 + z + 2, 1),
(T^5 + T^4 + 2*T^3 + T^2 + T + 1, 1)]
ERROR (after 524 iterations):
polynomial : 2*T^8 + 2*T^7 + 2*T^5 + T^4 + 1
factorization: (2) * (T + 1) * (T + 2*z^3 + z...
product : 2*T^8 + (2*z^7 + 2*z^6 + 2*z^5...
f = Mod(Mod(2, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2,
3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^8 + Mod(Mod(2, 3), Mod(1, 3)*a^8 + Mod(2,
3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^7 +
Mod(Mod(2, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 +
Mod(2, 3)*a + Mod(2, 3))*x^5 + Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 +
Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x^4 + Mod(Mod(1, 3),
Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a +
Mod(2, 3))
G = [[Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2,
3)*a^2 + Mod(2, 3)*a + Mod(2, 3))*x + Mod(Mod(1, 3), Mod(1, 3)*a^8 + Mod(2,
3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a + Mod(2, 3)), Mod(Mod(1,
3), Mod(1, 3)*a^8 + Mod(2, 3)*a^5 + Mod(1, 3)*a^4 + Mod(2, 3)*a^2 + Mod(2, 3)*a
+ Mod(2, 3))*x + Mod(Mod(1, 3)*a^7 + Mod(1, 3)*a^6 + Mod(1, 3)*a^5 + Mod(2,
3)*a + Mod(1, 3), Mod
Re: [sage-devel] help tracking bug with polynomials over finite fields
I opened ticket #16885 for that problem. 2014-08-27 12:42 UTC+02:00, Vincent Delecroix <20100.delecr...@gmail.com>: > 2014-08-27 12:38 UTC+02:00, Jeroen Demeyer : >> On 2014-08-27 12:32, John Cremona wrote: >>> In my case, I think yes, since I am using 6.4.beta4 >> I assume you mean 6.4.beta1. >> >>> i.e. current >>> development branch, and surely that does include all tickets marked as >>> closed? >> That's not the case. I think "closed" means that it's in Volker's >> private develop branch and that it should be released in the next >> release (in this case, 6.4.beta2). > > Nevertheless, even with #15767 (and a "make" in $SAGE_ROOT so that the > new pari is actually used) the problem is still there. > > On a related note, it would be very cool to see on trac tickets in > which release each ticket has been/will be merged. How hard would that > be? > > Vincent > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: issues with pushout construction?
Hi Jonas, > When I implemented Modular forms rings/spaces for Hecke triangle groups > I ran into some issues with pushout / functors / constructions > (correct me if I missunderstood something): > > Apparently the pushout construction implicitely assumes that > there exists a coercion from the "construction argument" to the > "construct": Ticket #16507 should solve this (at least to some extent) in situations where there is a coercion B -> A instead of A -> B. (Here B is the object resulting from a functorial construction applied to A; this can be used if B is a submodule of A, for example.) This won't address things like (base ring, cusp forms) -> (modular forms), though. Peter -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] help tracking bug with polynomials over finite fields
2014-08-27 12:38 UTC+02:00, Jeroen Demeyer : > On 2014-08-27 12:32, John Cremona wrote: >> In my case, I think yes, since I am using 6.4.beta4 > I assume you mean 6.4.beta1. > >> i.e. current >> development branch, and surely that does include all tickets marked as >> closed? > That's not the case. I think "closed" means that it's in Volker's > private develop branch and that it should be released in the next > release (in this case, 6.4.beta2). Nevertheless, even with #15767 (and a "make" in $SAGE_ROOT so that the new pari is actually used) the problem is still there. On a related note, it would be very cool to see on trac tickets in which release each ticket has been/will be merged. How hard would that be? Vincent -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] issues with pushout construction?
Hi all When I implemented Modular forms rings/spaces for Hecke triangle groups I ran into some issues with pushout / functors / constructions (correct me if I missunderstood something): Apparently the pushout construction implicitely assumes that there exists a coercion from the "construction argument" to the "construct": There is supposed to be a coercion from A and B to C=pushout(A,B). But if e.g. B is constructed from A without having a coercion from A then the pushout will fail this (also see line 3217 of pushout.py). So either one severely restricts (functorial) constructions to "coercion"-compatible ones or the pushout construction fails even though there might be a very obvious candidate for pushout(A,B). Some examples that come to my mind: - All kinds of "projection" / non-injective constructions - A = some graded ring, B = some homogeneous component of A Adding elements of A and B should give an element of A - A = some base ring, B = the ring of cusp forms over A Adding elements of A and B should give an element of the ring of modular forms over A, however if B is constructed by A, then the pushout construction will always return B to which A does not coerce. I have found a solution for those issues with my implementation (see sage.modular.modform_hecke_triangle.functors -> BaseFacade) but I consider it "less elegant" (put mildly). But it works! I just mention this here because I felt like it might be something worthy to discuss (unless I missunderstood something). Best Jonas -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] help tracking bug with polynomials over finite fields
On 2014-08-27 12:32, John Cremona wrote: In my case, I think yes, since I am using 6.4.beta4 I assume you mean 6.4.beta1. i.e. current development branch, and surely that does include all tickets marked as closed? That's not the case. I think "closed" means that it's in Volker's private develop branch and that it should be released in the next release (in this case, 6.4.beta2). Jeroen. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] help tracking bug with polynomials over finite fields
I get this also with PARI-2.7.1: sage: test1() ERROR (after 708 iterations): polynomial : 2*T^8 + 2*T^7 + 2*T^5 + T^3 + 2*T^2 + 2 factorization: (2) * (T + 2*z^4 + z^3 + 2*z^2... product : 2*T^8 + (2*z^6 + z^4 + 2*z^2 +... calling once more p.factor().prod() gives back the polynomial!! sage: %pari /home/release/Sage/local/lib/python2.7/site-packages/IPython/core/interactiveshell.py:2126: DeprecationWarning: Use %gp instead of %pari. See http://trac.sagemath.org/6288 for details. result = fn(*args,**kwargs) --> Switching to PARI/GP interpreter <-- pari: version() [2, 7, 1] On Wednesday, August 27, 2014 11:29:00 AM UTC+1, Jeroen Demeyer wrote: > > On 2014-08-27 00:25, Vincent Delecroix wrote: > > So I suspect something is wrong in between Sage and pari about > > conversions between finite fields. > Did you try with #15767? > > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: optional packages
ping... same problem with 6.4.beta1. PS: if there is something to do I can do it, but I do not know what it is. 2014-08-16 9:12 UTC+02:00, Vincent Delecroix <20100.delecr...@gmail.com>: > Hello, > > In sage-6.3 mcqd (merged in #16083) and pip (trac #16479) should be > optional packages... but I can not see them with "sage -optional". > Also "sage -i mcqd" or "sage -i pip" just fail. What is the procedure > to get them on the sagemath server? > > Vincent > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] help tracking bug with polynomials over finite fields
On 27 August 2014 11:28, Jeroen Demeyer wrote: > On 2014-08-27 00:25, Vincent Delecroix wrote: >> >> So I suspect something is wrong in between Sage and pari about >> conversions between finite fields. > > Did you try with #15767? In my case, I think yes, since I am using 6.4.beta4, i.e. current development branch, and surely that does include all tickets marked as closed? I'm not sure the best way to tell but my SAGE_ROOT/local/lib does contain libpari-gmp.so.2.7.1 so I assume that is actually being used. John > > > -- > 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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] help tracking bug with polynomials over finite fields
On 27 August 2014 11:16, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > Hi John, > > Thanks for the feedback. > > 2014-08-27 11:30 UTC+02:00, John Cremona : >> OK, so witth the corrected script and still with unpatched 6.4.beta1, > >> with test1() I get a few error messages as predicted, for a while, but >> then all was fine for 1000, 2000, 3000 iterations (at which point I >> checked the script and saw that it would run for ever sot killed it!). > > Right, you have to kill them ;-) (I included it in the error messages > now). I have the same behavior, few errors and then it works fine. So > at least it is somehow reproducible... but nevertheless very strange! > And do you get as well the line "calling once more p.factor().prod() > gives back the polynomial!!"? Yes, every time. > >> With test2(), no problems up to 1000 iterations, after that It crashed >> when p2 was 0 (better put in a test for that too). > > Was it 1 or 1000? It was 1, sorry. > > I added a check in test2 to forbid zero polynomial and better > presentation that makes the code readable. > OK -- then I hope more people will test this. In test1() I added to the output the correct factorization (when it works OK the second time) to see if I could spot the difference. Not very informative: I see sage: test1() problem with polynomial 2*T^6 + T^5 + 2*T^3 + T got factorization (2) * T * (T + z^3 + z) * (T + 2*z^4 + z^3 + 1) * (T + 2*z^5 + z^4 + z^3 + 2) * (T + 2)^2 whose product is 2*T^6 + (z^5 + 2*z + 2)*T^5 + (2*z^5 + 2*z^4 + z^2 + 2*z + 1)*T^4 + (z^4 + z^3 + z)*T^3 + (2*z^5 + z^4 + z^3 + 2*z)*T^2 + (z^5 + 2*z^4 + z^3 + 2*z^2 + 2*z + 1)*T failed after 1182 iterations calling once more p.factor().prod() gives back the polynomial!! New factorization = (2) * T * (T + 2*z^4 + z^3 + 1) * (T + z^5 + z^3 + 1) * (T + 2*z^5 + z^4 + z^3 + 2) * (T + 2)^2 looks good after 1 iterations (etc) > Thanks > Vincent > > -- > 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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] help tracking bug with polynomials over finite fields
On 2014-08-27 00:25, Vincent Delecroix wrote: So I suspect something is wrong in between Sage and pari about conversions between finite fields. Did you try with #15767? -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] help tracking bug with polynomials over finite fields
Hi John,
Thanks for the feedback.
2014-08-27 11:30 UTC+02:00, John Cremona :
> OK, so witth the corrected script and still with unpatched 6.4.beta1,
> with test1() I get a few error messages as predicted, for a while, but
> then all was fine for 1000, 2000, 3000 iterations (at which point I
> checked the script and saw that it would run for ever sot killed it!).
Right, you have to kill them ;-) (I included it in the error messages
now). I have the same behavior, few errors and then it works fine. So
at least it is somehow reproducible... but nevertheless very strange!
And do you get as well the line "calling once more p.factor().prod()
gives back the polynomial!!"?
> With test2(), no problems up to 1000 iterations, after that It crashed
> when p2 was 0 (better put in a test for that too).
Was it 1 or 1000?
I added a check in test2 to forbid zero polynomial and better
presentation that makes the code readable.
Thanks
Vincent
--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
r"""
Tests to track a bug in polynomial rings over finite fields
In sage-6.4 (and 6.4-beta1) there is a bug with factorization of polynomials
over finite fields. This file contains two functions that try to track the bug.
They are
- test1: a somehow minimal test that shows the bug. The expected output is:
a bunch of error message complaining about factorization. Each block should
ends with the line
"calling once more p.factor().prod() gives back the polynomial!!"
after some time (around 10 or 20 error messages) the function stops to show error
message and just works fine.
- test2: a relatively similar function but that works just fine
Note: if you launch the functions test1 or test2 you have to interrupt them with
Ctrl-C as they will run forever.
If you use it, please send an e-mail at sage-devel@googlegroups.com and describe
what you get.
"""
def test1():
r"""
Test of factorization of polynomials with coefficients in GF(3). At each
iteration we build an extension of the given degree.
This test is completely wrong!
"""
R = PolynomialRing(GF(3), 'T')
while True:
# create a random polynomial of degree between 2 and 8
p1 = R.random_element(degree=(2,8))
d = p1.degree()
if d <= 2:
continue
# create an extension which contains at at least one root and convert
# the polynomial
K2 = GF(3**d, 'z')
p2 = p1.change_ring(K2)
# check that the factorization is right
check_factorization(p2,p2.factor())
def test2(degree=8):
r"""
Test factorization of polynomials of degree 8 over finite fields on a fixed
extension of degree 8.
This test seems to be fine!
"""
R = PolynomialRing(GF(3), 'T')
K2 = GF(3**degree, 'z')
N = 0
while True:
# build a polynomial of the right degree
p1 = R.random_element(degree=degree)
if p1.degree() != degree:
p1 += GF(3)._random_nonzero_element() * R.gen()**degree
# check factorization
p2 = p1.change_ring(K2)
check_factorization(p2,p2.factor())
N = 0
def check_factorization(p,fac):
r"""
Check that the factorization ``fac`` is the one of ``p``.
"""
global N
q = fac.prod()
if p != q:
print "ERROR (after {} iterations):".format(N)
print " polynomial : {}".format(p)
print " factorization: {}...".format(str(fac)[:30])
print " product : {}...".format(str(q)[:30])
r = p.factor().prod()
if r == p:
print "calling once more p.factor().prod() gives back the polynomial!!".format(p.factor().prod())
elif r == q:
pass
else:
print "calling once more p.factor() we get another answer!!"
print
N = 0
N += 1
if N%1 == 0:
print "looks good after {} iterations (you can interrupt the test with Ctrl-C or let it run for 1 new iterations)".format(N)
Re: [sage-devel] help tracking bug with polynomials over finite fields
OK, so witth the corrected script and still with unpatched 6.4.beta1,
with test1() I get a few error messages as predicted, for a while, but
then all was fine for 1000, 2000, 3000 iterations (at which point I
checked the script and saw that it would run for ever sot killed it!).
With test2(), no problems up to 1000 iterations, after that It crashed
when p2 was 0 (better put in a test for that too).
John
On 26 August 2014 23:25, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> Hello,
>
> Working on #16681, it appears that there is a problem with
> factorization of polynomials over finite fields... (despite the ticket
> name, the bug has nothing to do with the recently implemented
> algebraic closure of finite fields).
>
> * if you want to help (i.e. run the tests on your computer) *
>
> In the attached file there are two functions test1 and test2. Just
> start a fresh Sage, and do
> {{{
> sage: %runfile test_polynomials.py
> sage: test1()
> }}}
> you should get a lot of complains (let say one each 10secs/20secs).
>
> Then start an other fresh Sage and run
> {{{
> sage: %runfile test_polynomials.py
> sage: test2()
> }}}
> and you should just see message saying that everything is fine (let
> say each 2min).
>
> Please confirm me that you got the same output (and if not, tell me
> the Sage version, how did you obtain it, and what is your operating
> system).
>
> * if you want to debug *
>
> I do not exactly understand where the bug comes from since it fails
> once but not twice (calling test1() you should see a lot of ""calling
> once more p.factor().prod() gives back the polynomial!!"). The
> factorization is done through pari at lines 3370-3373 of
> sage/rings/polynomial/polynomial_element.pyx
> {{{
> elif is_FiniteField(R):
> v = [x._pari_("a") for x in self.list()]
> f = pari(v).Polrev()
> G = list(f.factor())
> }}}
> So I suspect something is wrong in between Sage and pari about
> conversions between finite fields.
>
> Please help!
> Vincent
>
> --
> 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 http://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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: How practical/useful would a native windows subset be?
I tried to port Sage to mingw once, back when it was easier (2006), and failed already at building Python. There was a huge page with hacks to maybe do it back then, but they weren't working. There's a stackoverflow question now about this problem: http://stackoverflow.com/questions/15365249/build-python-with-mingw-and-gcc " Python does not build out of the box with MinGW, let alone for Win64." and another suggests this fork of Python 3.4 that's meant to build on mingw: https://bitbucket.org/puqing/python-mingw but there are issues entitled "Build fails on mingw (msys)" down the right side of the screen... On Wed, Aug 27, 2014 at 11:05 AM, Jean-Pierre Flori wrote: > > > On Wednesday, August 27, 2014 11:00:35 AM UTC+2, Jeroen Demeyer wrote: >> >> On 2014-08-27 10:22, Jean-Pierre Flori wrote: >> > Note that cross-compiler running on linux and targetting mingw(64) have >> > been available since mingw(64) is. >> Many packages in Sage do not support cross-compiling. For example, the >> Python build toolchain does not really support cross-compiling. > > Sure, but GMP/MPIR/MPFR/FLINT do. > You can even run testsuites using Wine64 :) > > -- > 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 http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- William Stein Professor of Mathematics University of Washington http://wstein.org wst...@uw.edu -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] help tracking bug with polynomials over finite fields
Hi,
Thanks for trying. I guess I merged #16682 before doing my tests...
You can do the following modifications to the source file or just use
the new attached version.
line 16 (in test 1) add two lines
{{{
if d <= 2:
continue
}}}
(because we do not want polynomials of degree less than 2)
line 43 (in the declaration of test2)
replace
{{{
def test2():
}}}
with
{{{
def test2(degree=8):
}}}
Sorry for that,
Vincent
2014-08-27 11:03 UTC+02:00, John Cremona :
> Following your instructions exactly, with my current development
> branch being 6.4.beta1 (commit 79d9c2f) all I get is:
>
> sage: %runfile test_polynomials.py
> sage: test1()
> ---
> ValueErrorTraceback (most recent call last)
> in ()
> > 1 test1()
>
> /home/jec/sage/test_polynomials.py in test1()
> 16 # create an extension with at least one root
> 17 # and convert the polynomial
> ---> 18 K2 = GF(3**d, 'z')
> 19 p2 = p1.change_ring(K2)
> 20
>
> /home/jec/sage/local/lib/python2.7/site-packages/sage/structure/factory.so
> in sage.structure.factory.UniqueFactory.__call__
> (build/cythonized/sage/structure/factory.c:1244)()
>
> /home/jec/sage/local/lib/python2.7/site-packages/sage/rings/finite_rings/constructor.pyc
> in create_key_and_extra_args(self, order, name, modulus, names, impl,
> proof, **kwds)
> 368 order = int(order)
> 369 if order <= 1:
> --> 370 raise ValueError("the order of a finite field
> must be > 1.")
> 371
> 372 if arith.is_prime(order):
>
> ValueError: the order of a finite field must be > 1.
>
> and (in a separate run)
>
> age: %runfile test_polynomials.py
> sage: test2()
> ---
> NameError Traceback (most recent call last)
> in ()
> > 1 test2()
>
> /home/jec/sage/test_polynomials.py in test2()
> 47 """
> 48 R = PolynomialRing(GF(3), 'T')
> ---> 49 K2 = GF(3**degree, 'z')
> 50
> 51 N = 0
>
> NameError: global name 'degree' is not defined
>
> -- is your test file correct?
>
> John
>
> On 26 August 2014 23:25, Vincent Delecroix <20100.delecr...@gmail.com>
> wrote:
>> Hello,
>>
>> Working on #16681, it appears that there is a problem with
>> factorization of polynomials over finite fields... (despite the ticket
>> name, the bug has nothing to do with the recently implemented
>> algebraic closure of finite fields).
>>
>> * if you want to help (i.e. run the tests on your computer) *
>>
>> In the attached file there are two functions test1 and test2. Just
>> start a fresh Sage, and do
>> {{{
>> sage: %runfile test_polynomials.py
>> sage: test1()
>> }}}
>> you should get a lot of complains (let say one each 10secs/20secs).
>>
>> Then start an other fresh Sage and run
>> {{{
>> sage: %runfile test_polynomials.py
>> sage: test2()
>> }}}
>> and you should just see message saying that everything is fine (let
>> say each 2min).
>>
>> Please confirm me that you got the same output (and if not, tell me
>> the Sage version, how did you obtain it, and what is your operating
>> system).
>>
>> * if you want to debug *
>>
>> I do not exactly understand where the bug comes from since it fails
>> once but not twice (calling test1() you should see a lot of ""calling
>> once more p.factor().prod() gives back the polynomial!!"). The
>> factorization is done through pari at lines 3370-3373 of
>> sage/rings/polynomial/polynomial_element.pyx
>> {{{
>> elif is_FiniteField(R):
>> v = [x._pari_("a") for x in self.list()]
>> f = pari(v).Polrev()
>> G = list(f.factor())
>> }}}
>> So I suspect something is wrong in between Sage and pari about
>> conversions between finite fields.
>>
>> Please help!
>> Vincent
>>
>> --
>> 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 http://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 http://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...@goog
Re: [sage-devel] Re: How practical/useful would a native windows subset be?
On Wednesday, August 27, 2014 11:00:35 AM UTC+2, Jeroen Demeyer wrote: > > On 2014-08-27 10:22, Jean-Pierre Flori wrote: > > Note that cross-compiler running on linux and targetting mingw(64) have > > been available since mingw(64) is. > Many packages in Sage do not support cross-compiling. For example, the > Python build toolchain does not really support cross-compiling. > Sure, but GMP/MPIR/MPFR/FLINT do. You can even run testsuites using Wine64 :) -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] help tracking bug with polynomials over finite fields
Following your instructions exactly, with my current development
branch being 6.4.beta1 (commit 79d9c2f) all I get is:
sage: %runfile test_polynomials.py
sage: test1()
---
ValueErrorTraceback (most recent call last)
in ()
> 1 test1()
/home/jec/sage/test_polynomials.py in test1()
16 # create an extension with at least one root
17 # and convert the polynomial
---> 18 K2 = GF(3**d, 'z')
19 p2 = p1.change_ring(K2)
20
/home/jec/sage/local/lib/python2.7/site-packages/sage/structure/factory.so
in sage.structure.factory.UniqueFactory.__call__
(build/cythonized/sage/structure/factory.c:1244)()
/home/jec/sage/local/lib/python2.7/site-packages/sage/rings/finite_rings/constructor.pyc
in create_key_and_extra_args(self, order, name, modulus, names, impl,
proof, **kwds)
368 order = int(order)
369 if order <= 1:
--> 370 raise ValueError("the order of a finite field
must be > 1.")
371
372 if arith.is_prime(order):
ValueError: the order of a finite field must be > 1.
and (in a separate run)
age: %runfile test_polynomials.py
sage: test2()
---
NameError Traceback (most recent call last)
in ()
> 1 test2()
/home/jec/sage/test_polynomials.py in test2()
47 """
48 R = PolynomialRing(GF(3), 'T')
---> 49 K2 = GF(3**degree, 'z')
50
51 N = 0
NameError: global name 'degree' is not defined
-- is your test file correct?
John
On 26 August 2014 23:25, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> Hello,
>
> Working on #16681, it appears that there is a problem with
> factorization of polynomials over finite fields... (despite the ticket
> name, the bug has nothing to do with the recently implemented
> algebraic closure of finite fields).
>
> * if you want to help (i.e. run the tests on your computer) *
>
> In the attached file there are two functions test1 and test2. Just
> start a fresh Sage, and do
> {{{
> sage: %runfile test_polynomials.py
> sage: test1()
> }}}
> you should get a lot of complains (let say one each 10secs/20secs).
>
> Then start an other fresh Sage and run
> {{{
> sage: %runfile test_polynomials.py
> sage: test2()
> }}}
> and you should just see message saying that everything is fine (let
> say each 2min).
>
> Please confirm me that you got the same output (and if not, tell me
> the Sage version, how did you obtain it, and what is your operating
> system).
>
> * if you want to debug *
>
> I do not exactly understand where the bug comes from since it fails
> once but not twice (calling test1() you should see a lot of ""calling
> once more p.factor().prod() gives back the polynomial!!"). The
> factorization is done through pari at lines 3370-3373 of
> sage/rings/polynomial/polynomial_element.pyx
> {{{
> elif is_FiniteField(R):
> v = [x._pari_("a") for x in self.list()]
> f = pari(v).Polrev()
> G = list(f.factor())
> }}}
> So I suspect something is wrong in between Sage and pari about
> conversions between finite fields.
>
> Please help!
> Vincent
>
> --
> 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 http://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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: How practical/useful would a native windows subset be?
On 2014-08-27 10:22, Jean-Pierre Flori wrote: Note that cross-compiler running on linux and targetting mingw(64) have been available since mingw(64) is. Many packages in Sage do not support cross-compiling. For example, the Python build toolchain does not really support cross-compiling. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] failing doctest for sage/structure/sage_object.pyx
Interesting, but the error message is not in tar (and, grepping through the tar git repo, has never been in Gnu tar). So you are using some other tar in the sage shell? sage -sh -c "tar --version" If that doesn't bring anything up, run the doctest under strace -ff and see which processes are being run. On Tuesday, August 26, 2014 11:44:47 PM UTC+1, Jakob Kroeker wrote: > > OS: > openSUSE 12.3 (x86_64) > VERSION = 12.3 > CODENAME = Dartmouth > > >tar --version > tar (GNU tar) 1.26 > > Am Dienstag, 26. August 2014 23:11:43 UTC+2 schrieb vdelecroix: >> >> What's your tar version? (ie what does answer the command "tar >> --version"). Looks like you have a very strange one. >> >> And, by the way, what is the system you are interested in? Might be >> useful to know for debugging... >> >> Vincent >> >> 2014-08-26 22:06 UTC+02:00, Jakob Kroeker : >> > >> > Hello, >> > >> > a doctest fails on an system I'm interested in (I want to run patchbot >> on >> > that system) >> > >> > File "src/sage/structure/sage_object.pyx", line 1411, in >> > sage.structure.sage_object.unpickle_allFailed example: >> > sage.structure.sage_object.unpickle_all() # (4s on sage.math, 2011) >> > Expected:doctest:... DeprecationWarning: This class is replaced >> by >> > Matrix_modn_dense_float/Matrix_modn_dense_double.See >> > http://trac.sagemath.org/4260 for details.Successfully >> unpickled ... >> > objects.Failed to unpickle 0 objects.Got:*** The >> old >> > options style (`tar fx ...`) is highly discouraged, please use the >> modern >> > form (leading dash before options).*** The standard way (with >> > expanded options; you can still bundle options) for your command would >> be: >> > tar -f - -x... >> > >> > Any idea about the cause/how to fix it? >> > >> > -- >> > 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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: How practical/useful would a native windows subset be?
On Wednesday, August 27, 2014 2:13:25 AM UTC+2, Bill Hart wrote: > > I am again very interested in having Windows 64 ports of various packages. > > At the top of my list are: > > * GAP > * Singular > * Pari/GP > > Note that MinGW2 is a much better way to do this than has previously been > available. It builds packages in a tiny fraction of the time it takes to > build with MinGW. It also fixes the broken parallel make that was in MinGW. > It has a nice package manager. The compiler seems stable. It 1000% better > in every way. In my opinion, a more or less native port of various packages > to MinGW2 is quite feasible. > > Note that cross-compiler running on linux and targetting mingw(64) have been available since mingw(64) is. You even get Debian packages for them. And they are fast. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: failing doctest for sage/structure/sage_object.pyx
Hi Jakob, On 2014-08-26, Jakob Kroeker wrote: > OS: > openSUSE 12.3 (x86_64) > VERSION = 12.3 > CODENAME = Dartmouth > >>tar --version > tar (GNU tar) 1.26 Interesting. My laptop has the same OS and tar versions, but Sage just works. Cheers, Simon -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] How practical/useful would a native windows subset be?
On Wednesday, August 27, 2014, Dr. David Kirkby (Kirkby Microwave Ltd) < drkir...@kirkbymicrowave.co.uk> wrote: > >> > The download size of such a subset would be smaller than the full > version and MUCH smaller that a virtual machine image, as one doesn't need > to include a complete operating system too. > > > > That's not true. E.g., Puppy Linux is around 50MB, and is a complete > > useful operating system. In fact, I used to build the Sage VM > > (targeted at windows) using Puppy Linux years ago. > > > > -- William > > OK, but it still doesn't get around the problem one needs to install > VirtualBox, and the whole process of installing virtual machines is > really alien to a lot of Windows users. > > Personally I find installing virtual machines quite easy and useful, > but it seems to be a barrier for some at least. > > Dave You are absolutely right about that! I'm.not arguing for VM's here - just pointing out that disk space isn't a priori significantly worse because of that approach. > > -- > 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 http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- William Stein Professor of Mathematics University of Washington http://wstein.org wst...@uw.edu -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: How practical/useful would a native windows subset be?
>> > The download size of such a subset would be smaller than the full version >> > and MUCH smaller that a virtual machine image, as one doesn't need to >> > include a complete operating system too. > > That's not true. E.g., Puppy Linux is around 50MB, and is a complete > useful operating system. In fact, I used to build the Sage VM > (targeted at windows) using Puppy Linux years ago. > > -- William OK, but it still doesn't get around the problem one needs to install VirtualBox, and the whole process of installing virtual machines is really alien to a lot of Windows users. Personally I find installing virtual machines quite easy and useful, but it seems to be a barrier for some at least. Dave -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: How practical/useful would a native windows subset be?
On Wed, Aug 27, 2014 at 8:54 AM, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: > Maybe I missed it, but it did not look to me as if there was any code > published in a few years, but the website seems to have been updated. yes, you are right, i only saw "2014" on the front page, not much else. maybe it's due to what william said. is there any other "compatibility layer" with linux in windows? The "SUA" unix extension for windows servers is also deprecated. Microsoft itself points instead to either Hyper-V-it or cygwin, mingw or mingw-64bit -- h -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
