Re: [sage-devel] Re: trac server running out of space again?
Hi, I don't know why -- maybe because of resources temporarily running out, but the passwd file was deleted by trac. Fortunately, I was able to restore it from a very, very recent backup. Things should work now. -- William On Tue, Mar 15, 2011 at 6:23 PM, kcrisman wrote: > > > On Mar 15, 6:42 pm, Rob Beezer wrote: >> Me too. >> >> Oops… >> Trac detected an internal error: >> ProgrammingError: could not write to hash-join temporary file: No >> space left on device >> >> Can somebody give it a kick? >> > > Please. I can't log in - it takes the login info, but rejects the > password. > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Calling callable function without arguments
Just checking that this is desired behavior. I found it useful today. sage: h(x)=2*sin(x^2) sage: h() 2*sin(x^2) In fact, the only other way I can find to access the 'output formula' of a callable symbolic expression is this: sage: SR(h) 2*sin(x^2) If someone has a problem with the first one, I thought I'd bring it up. If it's not a big deal, though, it would be nice to document it. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Degrees of permutation groups, esp. stabilizers
Perfect - thanks, Mike. I'll have a look in a bit. Rob On Mar 15, 6:40 pm, Mike Hansen wrote: > I have a more systematic fix for this in my patch at #10335. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Degrees of permutation groups, esp. stabilizers
On Wed, Mar 16, 2011 at 2:12 AM, Rob Beezer wrote:
> I can fix the stabilizer, but I am wondering if something more
> systematic is called for - consistently setting _deg in subgroup
> creation, or earlier in general group creation, and with less reliance
> on the largest moved point as a best guess. As this is perhaps
> different from the GAP philosophy (which I do not claim to know well)
> maybe there is a good reason for not being so careful? Maybe there
> are times when it is important to scrunch down the degree as happened
> above?
I have a more systematic fix for this in my patch at #10335. The
patch provides a explicit way to say on which set the group (and
subgroup) acts. If you have issues with it, I have an update to the
patch that I'm trying to push to the combinat patch server. I'm
having some issues with it authenticating; I'll post an update to this
thread when it's "live".
sage: D = DihedralGroup(4)
sage: D.domain()
{1, 2, 3, 4}
sage: S = D.stabilizer(4)
sage: S.domain()
{1, 2, 3, 4}
sage: S.degree()
4
sage: S.orbits()
[[1, 3], [2], [4]]
The patch also goes through and make sure all subgroups constructed go
through a common subgroup code path.
--Mike
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: trac server running out of space again?
On Mar 15, 6:42 pm, Rob Beezer wrote: > Me too. > > Oops… > Trac detected an internal error: > ProgrammingError: could not write to hash-join temporary file: No > space left on device > > Can somebody give it a kick? > Please. I can't log in - it takes the login info, but rejects the password. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Degrees of permutation groups, esp. stabilizers
Stabilizers of permutation groups, and most likely some other subgroups of permutation groups, do not know much about their ancestry. In the example below, all the elements of the stabilizer fix 4 by definition, and so the stabilizer considers itself a subgroup of the symmetric group on 3 symbols, as seen when it reports its degree to be 3. But then the calculation of the orbits "leaves out" the singleton orbit [4] that I would have expected to see in this scenario. sage: D = DihedralGroup(4) sage: S = D.stabilizer(4) sage: S.degree() 3 sage: sage: S.orbits() [[1, 3], [2]] Some permutation groups carry an attribute "_deg", but if it is not set, then it is inferred as the "largest moved point." This is the mechanism that explains why 4 gets bypassed above. It seems that GAP never gets too concerned about this notion of the degree of a permutation group, and the GAP command computing the orbit allows one to explicitly provide the set of points. But as called from Sage, there is no information in the stabilizer about where it came from, so simply a best guess for degree gets passed along to GAP. I can fix the stabilizer, but I am wondering if something more systematic is called for - consistently setting _deg in subgroup creation, or earlier in general group creation, and with less reliance on the largest moved point as a best guess. As this is perhaps different from the GAP philosophy (which I do not claim to know well) maybe there is a good reason for not being so careful? Maybe there are times when it is important to scrunch down the degree as happened above? Thoughts? Rob -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Differential Geometry via Sage: Parametrized Surface
I'd like to take a look at this - I have a few days of spring break left, after that it won't happen. For a somewhat complicated, revised ticket like this it helps someone like me (and the release manager) if you keep the ticket description up to date with exactly which patches (or other files, spkgs) need to be applied. By the name, I expect that "trac_10132_final_all_files_done.patch" is all I need, but this should be made completely explicit in the ticket description. -Marshall Hampton On Mar 15, 7:02 am, mikarm wrote: > The work on the module ParametrizedSurface3d has been completed (see > Ticket #10132 on the SAGE developer track server). Many thanks to > Joris Vankerschaver who made a lot of > code improvements as well as doctests. > > Using this module one can find the main invariants of a surface given > by a parametric equation in the three-dimensional Euclidean space, as > well as find the geodesics and the result of the parallel transport > along a curve (numerically). > > I would highly appreciate it if somebody could review the patch of > Ticket #10132. > > The next step I plan to do is go one dimension down and write a > similar module for curves. Also, I suppose, a some work should be done > for surfaces given implicitely. > > Mikhail Malakhaltsev -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Sage special session at AMS/MAA joint meetings in 2012?
Its pretty easy to propose a special session, its just an early deadline: this year its April 2nd, and "Late proposals will not be considered." The page is here: http://www.ams.org/meetings/national/jmm2012/2138_ssrequest Basically you email Michel Lapidus: lapi...@math.ucr.edu. -Marshall On Mar 15, 6:43 pm, David Roe wrote: > Having not been to the joint meetings, what does this involve? I will > probably make it to next year's, despite just having moved away from Boston. > David > > On Tue, Mar 15, 2011 at 18:06, William Stein wrote: > > Hi, > > > I'm curious if anybody was planning on organizing a special session on > > Sage at the 2012 AMS/MAA joint meetings in Boston, MA? > > > There *will* be an official Sage/Elliptic Curves AMS Short Course with > > speakers like Kiran Kedlaya, Noam Elkies, and me, at the 2012 meeting. > > We (the AMS short course) could "support" a special session proposal, > > which might help its chances of acceptance. > > > William > > > -- > > William Stein > > Professor of Mathematics > > University of Washington > >http://wstein.org > > > -- > > To post to this group, send an email to sage-devel@googlegroups.com > > To unsubscribe from this group, send an email to > > sage-devel+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/sage-devel > > URL:http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] Failed tests for accuracy reasons
> On 14 March 2011 16:40, Julien PUYDT wrote: > > Le 14/03/2011 14:12, David Kirkby a écrit : > >> Perhaps you can find value of n, such that gamma(n) gives an exact > >> integer result. If that happens on other CPUs too, then I suggest the > >> argument to the doctest is changed. > > > > The solution of finding a "good" integer is fragile : it will break > > anytime wind will change direction. > > > > Snark on #sage-devel > > I take your point it is "fragile". But it might well be the simplest > solution. IMHO, it is probably the best solution. > Julien said that according to IEEE 15 (or 16) digits should be precise enough. Why not test n(gamma1(float(6)),15)? Since we are looking at numerical results with a limited precision it makes sense to limit the test to the precision we are sure of. So Julien what would be the result for the above expression? Francois This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Sage special session at AMS/MAA joint meetings in 2012?
Having not been to the joint meetings, what does this involve? I will probably make it to next year's, despite just having moved away from Boston. David On Tue, Mar 15, 2011 at 18:06, William Stein wrote: > Hi, > > I'm curious if anybody was planning on organizing a special session on > Sage at the 2012 AMS/MAA joint meetings in Boston, MA? > > There *will* be an official Sage/Elliptic Curves AMS Short Course with > speakers like Kiran Kedlaya, Noam Elkies, and me, at the 2012 meeting. > We (the AMS short course) could "support" a special session proposal, > which might help its chances of acceptance. > > William > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: trac server running out of space again?
Me too. Oops… Trac detected an internal error: ProgrammingError: could not write to hash-join temporary file: No space left on device Can somebody give it a kick? Thanks, Rob On Mar 15, 2:03 pm, Francois Bissey wrote: > Hi, > > I am not able to look for tickets on trac. I am getting: > Report execution failed: could not write block 1 of temporary file: No space > left on device HINT: Perhaps out of disk space? > > Francois > > This email may be confidential and subject to legal privilege, it may > not reflect the views of the University of Canterbury, and it is not > guaranteed to be virus free. If you are not an intended recipient, > please notify the sender immediately and erase all copies of the message > and any attachments. > > Please refer tohttp://www.canterbury.ac.nz/emaildisclaimerfor more > information. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Sage special session at AMS/MAA joint meetings in 2012?
Hi, I'm curious if anybody was planning on organizing a special session on Sage at the 2012 AMS/MAA joint meetings in Boston, MA? There *will* be an official Sage/Elliptic Curves AMS Short Course with speakers like Kiran Kedlaya, Noam Elkies, and me, at the 2012 meeting. We (the AMS short course) could "support" a special session proposal, which might help its chances of acceptance. William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: trac server running out of space again?
Personally, I can't login to the sagetrac : it keeps asking my password. It might be related... Sébastien -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [ARM] Failed tests for accuracy reasons
On 14 March 2011 16:40, Julien PUYDT wrote: > Le 14/03/2011 14:12, David Kirkby a écrit : >> Perhaps you can find value of n, such that gamma(n) gives an exact >> integer result. If that happens on other CPUs too, then I suggest the >> argument to the doctest is changed. > > The solution of finding a "good" integer is fragile : it will break anytime > wind will change direction. > Snark on #sage-devel I take your point it is "fragile". But it might well be the simplest solution. IMHO, it is probably the best solution. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Inverse of permutation group elements
Hi François, > I have some questions about semantics and typographics convention in : > > 1/ Permutation > 2/ PermutationGroupElement > 3/ permutations (with lower p) > 4/ Permutations > > Suppose I don't know Sage. How can I imagine the design of each function ? > What is the first (question or) answer I must get ? > I suppose it's to know if I create a new object ? > > Permutations and PermutationGroupElement have almost the same name > but type and parent are different. First of all in my opinion 3/ should be deprecated. The same effect could be achieved using Permutations: sage: Permutations([1,1,2,2,2]).list() == permutations([1,1,2,2,2]) True The convention is that creating an object goes through a so-called constructor of a class and should be capitalized. Moreover the code says: def permutations(mset): from sage.combinat.permutation import Permutations ans = Permutations(mset) return ans.list() Maybe it is also to ensure a compatibility with M* but I think it is more confusing that anything else. 1/ vs. 4/ is the standard usage is combinatorics: Permutations() is the set of all permutations, Permutations([1,2,3,4]) is the *set* of the permutations of [1,2,3,4] whereas Permutation([1,2,3,4]) is the permutation [1,2,3,4]. This is a rather well followed usage in combinatorics: Partitions vs Partition / DyckWords vs DyckWord, BinaryTrees vs BinaryTree... etc. 1/ vs 2/ a Permutation is a combinatorial data structure which is not necessarily seen as an element of a group. It could be for example an ordering of a set. On the contrary, PermutationGroupElement is an element of a permutation Group. I hope this helps Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] trac server running out of space again?
Hi, I am not able to look for tickets on trac. I am getting: Report execution failed: could not write block 1 of temporary file: No space left on device HINT: Perhaps out of disk space? Francois This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Java study material and top interview guide
Sorry for this noise. This is removed, reported as spam, and the poster banned. This guy has been banned before (about 2-3 years ago) but just rejoined under a new email. On Tue, Mar 15, 2011 at 1:16 PM, reena wrote: > http://www.catchmany.com/tag/career-and-tecnology > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Failed tests for accuracy reasons
On 15 March 2011 17:05, Julien PUYDT wrote: > Le 14/03/2011 20:00, Robert Bradshaw a écrit : >> >> In the case of the OP's failures, that processor (or libm, libc, >> whatever) is giving us less accurate answers than anything else we've >> tested on, and I think it's worth looking into fixing the problem, or >> even adding an # optional, or as an expected failure on this platform, >> rather than weakening the examples and tests for all other platforms. > > Well, according to the debian developper I pushed the problem to, on such a > system, "long double" and "double" are the same. By "system" I assume you mean operating system and compiler. I believe the "long double" needs to be supported on the compiler, and is not in the ARM processor. The x86 CPU has an 80-bits, which is used for long-double on some systems. But not all systems have this (SPARC does not), but the compiler still supports a long double, where the number of bits is greater than on the double. I may be wrong, but I think that gcc does not handle it any different to double - which is permitted by the C standard. Although the "long double" is defined, there's no need for "long double" to use any more bits than "double". You could submit a request for enhancement to the gcc developers for long double to have more bits than double. They do it for the SPARC processor, and many other processors. In fact, on some CPUs it is actually. > And the result is then accurate enough, since we see 13 decimal digits after > the point, and there are 3 before ; that makes 16 good decimal digits. > > According to http://en.wikipedia.org/wiki/IEEE_754-2008, double precision > gives 15.95 decimal digits... Yes, its sage: log(2^53,10).n() 15.9545897701910 as there are 53 bits in the significand >> It reminds me a bit of all the correction we had to do because the >> literal floating point value for e is not correctly compiled on >> Solaris. It's one thing to have "numerical noise" in a lengthy >> computation involving lots of floating point arithmetic, it's another >> to give non-integral values for gamma(n) for small, integral n. > > Well, as far as I know, the result of computing $\Gamma(n)$ for a small > integral $n$ is mathematically an integer, It's true for any positive integer. > but the computer function does > get to the value by a lengthy computation involving lots of floating point > arithmetic... so the issue isn't that clear! True. I don't think there's a lot we can do -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Java study material and top interview guide
http://www.catchmany.com/tag/career-and-tecnology -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Failed tests for accuracy reasons
Le 14/03/2011 20:00, Robert Bradshaw a écrit : In the case of the OP's failures, that processor (or libm, libc, whatever) is giving us less accurate answers than anything else we've tested on, and I think it's worth looking into fixing the problem, or even adding an # optional, or as an expected failure on this platform, rather than weakening the examples and tests for all other platforms. Well, according to the debian developper I pushed the problem to, on such a system, "long double" and "double" are the same. And the result is then accurate enough, since we see 13 decimal digits after the point, and there are 3 before ; that makes 16 good decimal digits. According to http://en.wikipedia.org/wiki/IEEE_754-2008, double precision gives 15.95 decimal digits... It reminds me a bit of all the correction we had to do because the literal floating point value for e is not correctly compiled on Solaris. It's one thing to have "numerical noise" in a lengthy computation involving lots of floating point arithmetic, it's another to give non-integral values for gamma(n) for small, integral n. Well, as far as I know, the result of computing $\Gamma(n)$ for a small integral $n$ is mathematically an integer, but the computer function does get to the value by a lengthy computation involving lots of floating point arithmetic... so the issue isn't that clear! Snark on #sage-devel -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: evaluation of polynomials in several variables
> > No I am against changing this. For two reasons, when working with > > polynomials in variable names liks "k", "p". It is not always easy to > > remember which was the first and which was the second variable. Then > > it is very handy to pass keywords for evaluation - but still to expect > > a base_ring element. > > +1 (but where is the second reason?) Well, given that my message got posted three times, there are 3 reasons already :) The other (which I forgot to include in the end) is that it would probably imply a lot of changes throughout the full sage code and many people might be used to the syntax. > > Instead I think we should check that all variables are evaluated. This > > would be consistent with the call f(2,3) which screams when the number > > of variables is not correct. Even better, we could check if the result > > is really a ring element after substitution, which is easy to do. E.g. > > I would allow > > f = x*(x+y) > > f(x=0) > > but not > > f(x=1) > > I don't like this approach. I would allow both f(x=0) and f(x=1), in > both cases returning a univariate polynomial. Mathematically I fully agreee with you. I would expect an element of R[x,y]/(x) = R[x,y]/(x-1) = R[y] in both cases. But if we want to stick to the principle that the type should be the same for all returned answers, we would have to do f.subs() gives back an element of the parent of f and f(..) gives back an element of the base-ring of f and hence it would only be allowed to be used in case the evaluation really yields an element in there. My suggestion above is based on the fact that it is very easy to check if the result is in the base_ring. Maybe it is just as easy to check if the length of the keywords is equal to the number of variables. Chris. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Differential Geometry via Sage: Parametrized Surface
The work on the module ParametrizedSurface3d has been completed (see Ticket #10132 on the SAGE developer track server). Many thanks to Joris Vankerschaver who made a lot of code improvements as well as doctests. Using this module one can find the main invariants of a surface given by a parametric equation in the three-dimensional Euclidean space, as well as find the geodesics and the result of the parallel transport along a curve (numerically). I would highly appreciate it if somebody could review the patch of Ticket #10132. The next step I plan to do is go one dimension down and write a similar module for curves. Also, I suppose, a some work should be done for surfaces given implicitely. Mikhail Malakhaltsev -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Removal of scipy_sandbox
Hi, I have created a ticket (trac #10936) to remove scipy_sandox from sage. Back in the day of trac #1430 it contained experimental parts waiting to be integrated in scipy. Time has passed and now scipy_sandbox has been discontinued for a while upstream and one part it provided is now in scipy proper and the other is in matplotlib. So I propose we remove scipy_sandbox from sage by sage-5.0 or earlier if the release manager wants to take it in sage-4.7. The ticket includes the needed patches to sage. A note about the arpack patch. Historically in sage-on-gentoo we have carried a different patch that is much more minimalistic. However it turns out that this patch is not future proof and won't work with scipy-0.9.0 (on which I am working as well see trac #10887) the arpack patch in #10936 should be scipy-0.8.0 and scipy-0.9.0 proof. Francois This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: evaluation of polynomials in several variables
Hi Chris, On 14 Mrz., 23:31, chris wuthrich wrote: > I hope we agree that evaluation (meaning evaluation of all variables > by some elements in a ring) should yield an element of the ring. I > don't mind if subs should give back a polynomial in all cases. > > [Aside: Strangely this is not the case for symbolic expressions. I am > sure there must have been a discussion on this and I missed it. E.g. > f(x) = sin(x) > f(1.).floor() > does not work.] Well, f(1.) is in fact contained in the base ring of the parent of f, so everything is formally fine: sage: f.parent() Callable function ring with arguments (x,) sage: f.parent().base_ring() Symbolic Ring sage: f(1.).parent() Symbolic Ring > No I am against changing this. For two reasons, when working with > polynomials in variable names liks "k", "p". It is not always easy to > remember which was the first and which was the second variable. Then > it is very handy to pass keywords for evaluation - but still to expect > a base_ring element. +1 (but where is the second reason?) > Instead I think we should check that all variables are evaluated. This > would be consistent with the call f(2,3) which screams when the number > of variables is not correct. Even better, we could check if the result > is really a ring element after substitution, which is easy to do. E.g. > I would allow > f = x*(x+y) > f(x=0) > but not > f(x=1) I don't like this approach. I would allow both f(x=0) and f(x=1), in both cases returning a univariate polynomial. Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: evaluation of polynomials in several variables
Hi Robert, On 14 Mrz., 23:29, Robert Bradshaw wrote: > > Yes, but the fact that f(2,3) has a different parent than f(x=2,y=3) > > has a high probability of being troublesome. > > Given f in R[x,y], I think f(x=a, y=b) should do exactly the same > thing as f(a,b). The parent should be the same as R.base_ring()(0) + a > + b. +1. I think that f.__call__(*args,**kwds) of a polynomial f in variables x,y,z should behave like a Python function of signature f(x,y,z,**kwds). In particular, f(1,2,z=3, foo='bar') should do exactly the same as f(1,2,3,foo='bar'). Note that currently the situation is not very consistent. On the one hand, we already have the behaviour that you wish: sage: R. = ZZ[] sage: P. = QQ[] sage: f = x+y sage: parent(f(a,b)) Multivariate Polynomial Ring in a, b over Rational Field sage: parent(f(x=a,y=b)) Multivariate Polynomial Ring in a, b over Rational Field sage: parent(f(1,b)) Multivariate Polynomial Ring in a, b over Rational Field But on the other hand, we have the inconsistency that started this thread: sage: parent(f(x=1,y=2)) Multivariate Polynomial Ring in x, y over Integer Ring sage: parent(f(1,2)) Integer Ring > The difficult case is what to do for f(x=5). Should that be the same > as f(x=5, y=y) or a univariate polynomial? I tend to believe that if you evaluate k variables of a polynomial with n variables then the result should be a polynomial with n-k variables. That having said, I wonder whether one should really make a special case for k==n: Should the result be an element of the base ring, or should it actually be a polynomial in zero variables? Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
