Bonjour Monsieur, je suis nouveau avec le logiciel sage, actuellement j'essaye d'installer la version sage-4.8 sur Ubuntu 12.04 mais j'y arrive pas, s'il vous plait aider moi à faire cette installation. merci.
2012/5/15 <sage-support@googlegroups.com> > Today's Topic Summary > > Group: http://groups.google.com/group/sage-support/topics > > - Making a copy of a > MixedIntegerLinearProgram<#137513d7e049c617_group_thread_0>[9 Updates] > - Integration issue <#137513d7e049c617_group_thread_1> [7 Updates] > - Application/Use of Sage in IT company or > Industries<#137513d7e049c617_group_thread_2>[1 Update] > - Group action <#137513d7e049c617_group_thread_3> [8 Updates] > > Making a copy of a > MixedIntegerLinearProgram<http://groups.google.com/group/sage-support/t/b84fede6c3081915> > > Emil <emi...@gmail.com> May 15 01:32AM +0100 > > I would like to solve a large number of very similar linear programs. > More specifically I would like to be able to > > 1) Create a MixedIntegerLinearProgram, and add some constraints. > 2) Keep this MILP somewhere. > 3) (Repeated many times) Take a copy of the saved MILP, add a few more > constraints specific to this problem instance, and solve it. > > The difficulty I have is that I am unclear how to add new constraints > that include previous variables. Suppose I do > > lp = MixedIntegerLinearProgram(maximization=True) > x = lp.new_variable() > > Then I do: > > nlp = copy(lp) > x = nlp.new_variable() > > The variable 'x' now seems to contain different variables. So I cannot > add any constraints that use the existing variables. Or is there some > way to do this? Thanks, > > Emil > > > > > Nathann Cohen <nathann.co...@gmail.com> May 14 11:51PM -0700 > > Hellooooooo Emil !!! > > Well, I just tried something and it ended upi crashing Sage, so I can > just > advise you to create all your variables in the first LP from the > start, > *then* to copy the MixedIntegerLinearProgram object. Of course it is a > bad > answer :-) > > John Perry was the one who needed this copy() feature for MILP and he > was > doing things similar to the ones you attempt. As I only had integer > programs in mind when I wrote this class (hence hard problems to > solve. > hence the times it takes to generate the LP is totally small compared > to > the rest) I am totally ready to admit that it is not very suited to > such > computations. Dima mentionned recently that we may create some > "LinearProgram" class at some point which would be thought *for* this > type > of problems, but I would fint it hard to write it myself considering > that > that would not be a user of it.... Hence no clue of what should be > possible > or not with it :-) > > Nathann > > > > > Nathann Cohen <nathann.co...@gmail.com> May 15 12:00AM -0700 > > By the way, could I ask you what lead you to create and solve many LP > ? I > mean, what are you solving which requires you to do that ? ^^; > > Nathann > > > > > Emil <emi...@gmail.com> May 15 11:47AM +0100 > > Hi Nathann, > > Thanks for writing the MILP class - it works very well. Now, I can do: > > x = lp.new_variable() > > Is there any way to do something like > > x = lp.get_existing_variables() > > ? > > I'm working on some graph theoretic stuff: I'm solving two LPs for > each graph, for as many graphs as I can. - Emil. > > > > > > > > john_perry_usm <john.pe...@usm.edu> May 15 05:38AM -0700 > > On Monday, May 14, 2012 7:32:25 PM UTC-5, Emil wrote: > > > The variable 'x' now seems to contain different variables. So I > cannot > > add any constraints that use the existing variables. Or is there > some > > way to do this? Thanks, > > x *should* contain different variables, for two reasons. First, nlp > already > has a variable (a copy of the one you created for lp), so if you ask > nlp to > create a new variable for it, it won't return the variable lp created > earlier. > > Second, after copying lp to nlp, you might want to change some > variables in > one from real to integer, or vice-versa. > > Also, I don't think Sage has ever let you create variables & add > constraints that way. I don't know why, but if I want a variable with > a > compact notation, I've found MILP lets you do it this way: > > sage: x, y = lp[0], lp[1] > > but NOT > > sage: x, y = lp.new_variable(), lp.new_variable() > > You'll get variables alright, but you can't add constraints using the > second. The first works fine. > > To add constraints, I usually do the following: > > sage: lp = MixedIntegerLinearProgram(maximization=False) > sage: lp.add_constraint(2*lp[0] + 3*lp[1] <= 1) > sage: nlp = copy(lp) > sage: nlp.add_constraint(3*lp[0] - 2*lp[1] <= 1) > > Or, if you like, use x, y, etc., defining them as I did above (the > FIRST > way). > > regards > john perry > > > > > Emil <emi...@gmail.com> May 15 02:47PM +0100 > > >I've found MILP lets you do it this way: > > > sage: x, y = lp[0], lp[1] > > Ahh! Thanks, this is what I need. (Is this documented anywhere?) - Emil > > > > > Emil <emi...@gmail.com> May 15 03:03PM +0100 > > Next issue is that the Gurobi backend doesn't support the copy: > > AttributeError: 'sage.numerical.backends.gurobi_backend.GurobiBacke' > object has no attribute 'copy' > > Any idea how much work this would be to do? > > (I can now do what I wanted to do before, at least with GLPK.) > > Emil > > > > > Nathann Cohen <nathann.co...@gmail.com> May 15 04:21PM +0200 > > Hellooooooo !! > > > Next issue is that the Gurobi backend doesn't support the copy: > > Oops ^^; > > > Any idea how much work this would be to do? > > Oh, it's usually quite straightforward to implement such things. > Usually the feature already exists in the solver's C api, and all the > work that needs to be done is to expose it in Sage :-) > > Nathann > > > > > Emil <emi...@gmail.com> May 15 04:51PM +0100 > > > Oh, it's usually quite straightforward to implement such things. > > Usually the feature already exists in the solver's C api, and all the > > work that needs to be done is to expose it in Sage :-) > > Any chance you could make a patch? :) (I'd volunteer myself, but I > would probably mess it up!) > > Emil > > > > Integration > issue<http://groups.google.com/group/sage-support/t/f83cda8a89f756b0> > > JamesHDavenport <j.h.davenp...@bath.ac.uk> May 14 01:37PM -0700 > > It may be "branch cut strangeness", but if so it is very strange. The > integrand is clearly well-behaved, and the integral, > while in terms of the incomplete gamma function, seems to be off the > usual > branch cut (negative real axis). > > On Monday, 14 May 2012 15:35:01 UTC+1, Robert Dodier wrote: > > > > > Robert Dodier <robert.dod...@gmail.com> May 15 06:31AM > > > integrand is clearly well-behaved, and the integral, > > while in terms of the incomplete gamma function, seems to be off the > usual > > branch cut (negative real axis). > > Try domain:complex before calling integrate; that changes the result to > what I think is expected. > > I guess (emphasis on guess) that the problem originates not from > gamma_incomplete itself but from terms of the form (-1)^(1/n) which are > the result of simplifying or evaluating gamma_incomplete. Sorry I can't > be more helpful. > > best, > > Robert Dodier > > > > > Keshav Kini <keshav.k...@gmail.com> May 15 02:36PM +0800 > > > This works for me: > > > sage: numerical_integral(x*cos(x^3), 0, 0.5) > > (0.1247560409610376, 1.3850702913602309e-15) > > Interesting... > > > sage: numerical_integral(x*cos(x^3), 0, 0.5) > (0.1247560409610376, 1.3850702913602309e-15) > sage: (x*cos(x^3))(0) > /opt/sage-5.0.rc1/local/lib/python2.7/site-packages/IPython/iplib.py:2260: > DeprecationWarning: Substitution using function-call syntax and unnamed > arguments is deprecated and will be removed from a future release of Sage; > you can use named arguments instead, like EXPR(x=..., y=...) > exec code_obj in self.user_global_ns, self.user_ns > 0 > > Why does numerical_integral() not trigger the deprecation warning? > > -Keshav > > ---- > Join us in #sagemath on irc.freenode.net ! > > > > > kcrisman <kcris...@gmail.com> May 15 06:58AM -0700 > > > > branch cut (negative real axis). > > > Try domain:complex before calling integrate; that changes the result > to > > what I think is expected. > > (%i5) display2d:false; > > (%o5) false > (%i6) integrate(x*cos(x^3),x); > > (%o6) (gamma_incomplete(2/3,%i*x^3)+gamma_incomplete(2/3,-%i*x^3))/6 > (%i7) domain:complex; > > (%o7) complex > (%i8) integrate(x*cos(x^3),x); > > (%o8) ((sqrt(3)*%i-1)*gamma_incomplete(2/3,%i*x^3) > +(-sqrt(3)*%i-1)*gamma_incomplete(2/3,-%i*x^3)) > *(x^3)^(1/3) > /(12*x) > > But the *definite* integral in both cases is wrong. Any ideas? > > (%i1) display2d:false; > > (%o1) false > (%i2) integrate(x*cos(x^3),x,0,1/2); > > (%o2) > gamma_incomplete(2/3,%i/8)/6+gamma_incomplete(2/3,-%i/8)/6-gamma(2/3)/3 > (%i3) domain:complex; > > (%o3) complex > (%i4) integrate(x*cos(x^3),x,0,1/2); > > (%o4) > gamma_incomplete(2/3,%i/8)/6+gamma_incomplete(2/3,-%i/8)/6-gamma(2/3)/3 > > > I guess (emphasis on guess) that the problem originates not from > > gamma_incomplete itself but from terms of the form (-1)^(1/n) which > are > > the result of simplifying or evaluating gamma_incomplete. Sorry I > can't > > be more helpful. > > I don't see any of those up here, though, and the gamma_incomplete > evaluation is correct (gives the same via W|A, Sage = Pari in my > version, > mpmath, and Maxima). I think that Maxima is somehow using the "real" > antiderivative, if that makes sense - is that possible, Robert? > > > > > kcrisman <kcris...@gmail.com> May 15 07:02AM -0700 > > On Tuesday, May 15, 2012 2:36:34 AM UTC-4, Keshav Kini wrote: > > exec code_obj in self.user_global_ns, self.user_ns > > 0 > > > Why does numerical_integral() not trigger the deprecation warning? > > The same reason that plot and integral don't, because we're not > "calling" > them in the same way. It makes sense to integrate symbolic expressions > and > to plot them. It's true that we need to unify our integration command > syntax (see http://trac.sagemath.org/sage_trac/ticket/7763). > > - kcrisman > > > > > Robert Dodier <robert.dod...@gmail.com> May 15 03:04PM > > > (%i4) integrate(x*cos(x^3),x,0,1/2); > > > (%o4) > > > gamma_incomplete(2/3,%i/8)/6+gamma_incomplete(2/3,-%i/8)/6-gamma(2/3)/3 > > Hmm. I get a different result. I am using the current Git version. > > domain : complex; > integrate (x*cos(x^3), x, 0, 1/2); > => > %i*gamma_incomplete(2/3,%i/8)/(4*sqrt(3)) > > -gamma_incomplete(2/3,%i/8)/12-%i*gamma_incomplete(2/3,-%i/8)/(4*sqrt(3)) > -gamma_incomplete(2/3,-%i/8)/12+gamma(2/3)/6 > expand (float (%)); > => .1247560409610377 > > That's gratifying, but the problem, as I'm sure you know, is that the > user won't know they have to change a global variable. > > > evaluation is correct (gives the same via W|A, Sage = Pari in my > version, > > mpmath, and Maxima). I think that Maxima is somehow using the "real" > > antiderivative, if that makes sense - is that possible, Robert? > > It seems plausible, but I don't know the integration code very well. > > best > > Robert Dodier > > > > > kcrisman <kcris...@gmail.com> May 15 08:50AM -0700 > > > > > (%o4) > > > > gamma_incomplete(2/3,%i/8)/6+gamma_incomplete(2/3,-%i/8)/6-gamma(2/3)/3 > > > Hmm. I get a different result. I am using the current Git version. > > Great, I didn't realize some code had changed - I get this same thing > below > in 5.27.0. > > > > > => .1247560409610377 > > > That's gratifying, but the problem, as I'm sure you know, is that > the > > user won't know they have to change a global variable. > > If all integrals still work with domain:complex, we could conceivably > set > this in the integration code. However, we *already* set > `domain:complex` > in the startup code for the "calculus" copy of Maxima for exactly this > reason... so I guess that this would be fixed by upgrading Maxima? > > > > > > Application/Use of Sage in IT company or > Industries<http://groups.google.com/group/sage-support/t/ef382dc5bd402f9a> > > Dima Pasechnik <dimp...@gmail.com> May 15 06:09AM -0700 > > On Sunday, 13 May 2012 19:36:13 UTC+2, Robert Miller wrote: > > Sage in prototyping things. In fact I've actually ported some of the > Python > > 2.7 code we have to be compatible with 2.6 so that I can import our > > libraries in a Sage environment. > > quid.com would neither confirm nor deny they use Sage :-) > > > > instead we are installing the pieces that we need individually (and > again > > Sage was a big help as we consulted it a few times to fix > > compilation/linking issues that had already been solved in the Sage > distro). > > yeah, sysadmins tend to be PITAs. They have to justify their > existence, so > they want to spend 10 times more time and effort to install and > maintain a > part of Sage rather than using Sage as it is :-) > They even think that easy_install and pip and debian always work... > > > > Group action<http://groups.google.com/group/sage-support/t/1d7d107d78303b9b> > > David Joyner <wdjoy...@gmail.com> May 14 04:55PM -0400 > > > orbits of my vertices, but I would like to compute the orbit of a Set > > of vertices, that is all sets of the form "gg * my_set for gg in ag". > > > Is there any way to achieve it with Sage ? > > The short answer is yes, if you use GAP. The problem is that I don't > know the syntax for group actions in GAP well enough to give you a > beter answer quickly. If you post a specific question to GAP support, > I think > it would be answered immediately. > > > > > > > Dima Pasechnik <dimp...@gmail.com> May 14 04:02PM -0700 > > On Monday, 14 May 2012 16:57:40 UTC+2, Nathann Cohen wrote: > > orbits of my vertices, but I would like to compute the orbit of a > Set > > of vertices, that is all sets of the form "gg * my_set for gg in > ag". > > > Is there any way to achieve it with Sage ? > > Well, you can call GAP, e.g. as follows: > > sage: gap("Orbit("+str(ag._gap_())+",[1,2,7],OnSets);") > [ [ 1, 2, 7 ], [ 1, 2, 3 ], [ 1, 6, 9 ], [ 2, 3, 4 ], [ 3, 4, 10 ], > [ 1, 6, 8 ], [ 3, 4, 8 ], [ 4, 9, 10 ], [ 4, 7, 9 ], [ 5, 8, 10 ], > [ 2, 5, 7 ], [ 5, 6, 8 ], [ 3, 5, 8 ], [ 4, 6, 9 ], [ 5, 7, 10 ], > [ 5, 7, 9 ], [ 6, 7, 9 ], [ 3, 6, 8 ], [ 1, 6, 10 ], [ 2, 7, 9 ], > [ 1, 2, 10 ], [ 2, 3, 8 ], [ 6, 8, 9 ], [ 1, 5, 10 ], [ 2, 3, 7 ], > [ 1, 4, 10 ], [ 5, 7, 8 ], [ 3, 4, 9 ], [ 4, 5, 10 ], [ 1, 2, 6 ] ] > sage: > > > > > > > Dima Pasechnik <dimp...@gmail.com> May 14 04:04PM -0700 > > On Tuesday, 15 May 2012 01:02:46 UTC+2, Dima Pasechnik wrote: > > [ 1, 2, 10 ], [ 2, 3, 8 ], [ 6, 8, 9 ], [ 1, 5, 10 ], [ 2, 3, 7 ], > > [ 1, 4, 10 ], [ 5, 7, 8 ], [ 3, 4, 9 ], [ 4, 5, 10 ], [ 1, 2, 6 ] ] > > sage: > > PS. it should not be hard to expand the ag.orbit method to incorporate > the > action type... > > > > > > > > Emil <emi...@gmail.com> May 15 02:02AM +0100 > > One thing to watch out for is that the generators returned by > automorphism_group contain symbols that may not be the actual vertices. I > realised this once after several frustrating hours of bizarre results from > my program. I'm not sure if this is still the case in recent versions. > > Emil > > > > > > Nathann Cohen <nathann.co...@gmail.com> May 15 08:20AM +0200 > > > automorphism_group contain symbols that may not be the actual > vertices. I > > realised this once after several frustrating hours of bizarre > results from > > my program. I'm not sure if this is still the case in recent > versions. > > Yep. I wasted 30 minutes easily on that one too. Actually the elements > are always 1...n regardless of the graph's labelling (which often > starts at 0). That's a shame. > > Nathann > > > > > Mike Hansen <mhan...@gmail.com> May 14 11:31PM -0700 > > > > Yep. I wasted 30 minutes easily on that one too. Actually the > elements > > are always 1...n regardless of the graph's labelling (which often > > starts at 0). That's a shame. > > This is because permutation groups used to not support arbitrary > domains. Since they do now, it should be easy to return an > automorphism group that actually acts on the vertices. > > --Mike > > > > > Nathann Cohen <nathann.co...@gmail.com> May 15 09:54AM +0200 > > > [ 5, 7, 9 ], [ 6, 7, 9 ], [ 3, 6, 8 ], [ 1, 6, 10 ], [ 2, 7, 9 ], > > [ 1, 2, 10 ], [ 2, 3, 8 ], [ 6, 8, 9 ], [ 1, 5, 10 ], [ 2, 3, 7 ], > > [ 1, 4, 10 ], [ 5, 7, 8 ], [ 3, 4, 9 ], [ 4, 5, 10 ], [ 1, 2, 6 ] ] > > THaaaaaaaank you Dima !! I finally got it to work thanks to you.... > Too me some time to find out that Gap would return a totally weird > error message if the list you give as an argument is not sorted, and I > guess most of the time it takes to run the computation is devoted to > translating Gap object to Sage ones afterwards, but.... It works !! > ;-)))) > > (But Gap definitely has the worst syntax ever) > > Nathann > > > > > Dima Pasechnik <dimp...@gmail.com> May 15 02:19AM -0700 > > On Tuesday, 15 May 2012 09:54:15 UTC+2, Nathann Cohen wrote: > > Too me some time to find out that Gap would return a totally weird > > error message if the list you give as an argument is not sorted, and > I > > guess most of the time it takes to run the computation is devoted to > > IMHO most of the time is spent on IPC, via pexpect... > > > > > > You received this message because you are subscribed to the Google Group > sage-support. > You can post via email <sage-support@googlegroups.com>. > To unsubscribe from this group, > send<sage-support+unsubscr...@googlegroups.com>an empty message. > For more options, > visit<http://groups.google.com/group/sage-support/topics>this group. > > -- > To post to this group, send email to sage-support@googlegroups.com > To unsubscribe from this group, send email to > sage-support+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-support > URL: http://www.sagemath.org > -- --------------------------------------------------------- *Mohamed Lamine DIALLO* *Ingénieur Informaticien* *Responsable Informatique* *AIMS-Sénégal /www.aims-senegal.sn <http://www.aims-senegal.sn>* *Tél: 77 655 3928 / 70 103 4960* --------------------------------------------------------- -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
