[sage-support] if I input 1.1, why is it real not rational?
I would like to understand Sage behaviour better. I just found out that Sage is different from Pari when it comes to user input of values: sage: Ei(1.1).n(100) 2.1673782795634028985887198360 sage: Ei(11/10).n(100) 2.1673782795634028235837873423 while in Pari: ? sin(1.1) %1 = 0.89120736006143533995180257787170353832 ? sin(11/10) %2 = 0.89120736006143533995180257787170353832 What could be the reason to interpret the user input 1.1 as real with precision of 53 bits instead of short way of specfying 11/10? Programming convenience? If you say well then the user should say 11/10 if she means it, this could be said as well with RealField(1.1), so what is the reason for this convention? Regards, -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] if I input 1.1, why is it real not rational?
Hello. I do not think that is really a convention, but it is very logical because 1.1 can also be a float result given by Python. But floats and decimals are not the same due to the ways operators act on them. Christophe BAL Le 28 mars 2014 10:34, Ralf Stephan gtrw...@gmail.com a écrit : I would like to understand Sage behaviour better. I just found out that Sage is different from Pari when it comes to user input of values: sage: Ei(1.1).n(100) 2.1673782795634028985887198360 sage: Ei(11/10).n(100) 2.1673782795634028235837873423 while in Pari: ? sin(1.1) %1 = 0.89120736006143533995180257787170353832 ? sin(11/10) %2 = 0.89120736006143533995180257787170353832 What could be the reason to interpret the user input 1.1 as real with precision of 53 bits instead of short way of specfying 11/10? Programming convenience? If you say well then the user should say 11/10 if she means it, this could be said as well with RealField(1.1), so what is the reason for this convention? Regards, -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] using s_integral_points to get the rank of an elliptic curve
Thank you very much for your explanation and the kind help. With best regards, Petra Tadic On Thursday, March 27, 2014 9:08:26 PM UTC+1, John Cremona wrote: On 27 March 2014 18:04, pau...@gmail.com javascript: wrote: Thank you very much for your kind help. It is a honor to get the question answered by you. Does the MAGMA command SIntegralPoints miss points also? You would have to ask the Magma people about that, but the implementations are entirely independent. When we (I and a couple of Masters students) first implemented integral and S-integral points in Sage (over Q only) in 2008, we did find points which Magma missed, but since then both implementations have had improvements, to the extent that Steve Donnelly (Magma) now uses a lot of tricks which are not published. It is taking me longer than I expected to review a long-lived patch on the trac server which translates an implementation by another student of mine of integral points over number fields (not S-integral points yet) from its original Magma form to Sage; there are some good reasons for this, as some of the published formulas are wrong! Your enquiry gives me motivation to get back to that project which has been lying neglected since term started in January! John With best regards, Petra Tadic On Thursday, March 27, 2014 6:21:24 PM UTC+1, John Cremona wrote: If the rank is successfully computed then it will be cached so calling E.rank() afterwards will just retriueve the value with no further computing. ALternatively, compute the rank first, then the S-integral points computation will need not re-do it. I should tell you , though, that there are examples where some S-integral points are missed and it is a rather long-delayed project of mine to correct that; I am first working on the (separate) integral points code, and after that will look again at the S-integral points. So you should probably not rely on the outpus to prove any theorems just yet. John On 27 March 2014 17:06, pau...@gmail.com wrote: I am using the command s_integral points for a lot of elliptic curves for calculating S-integral points of elliptic curves over Q. I know that the command s_integral_points in it's calculation calculates also the rank of the elliptic curve in question but doesn't output the result. How can I get the value of the rank without calculating it separatly again with another command for the rank. So I'd like to get the rank and the S-integral points all at once with the one s_integral_points command. Thank you for the help. -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support...@googlegroups.com. To post to this group, send email to sage-s...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support...@googlegroups.com javascript:. To post to this group, send email to sage-s...@googlegroups.comjavascript:. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: if I input 1.1, why is it real not rational?
On Friday, March 28, 2014 10:34:55 AM UTC+1, Ralf Stephan wrote: I would like to understand Sage behaviour better. I just found out that Sage is different from Pari when it comes to user input of values: sage: Ei(1.1).n(100) 2.1673782795634028985887198360 sage: Ei(11/10).n(100) 2.1673782795634028235837873423 while in Pari: ? sin(1.1) %1 = 0.89120736006143533995180257787170353832 ? sin(11/10) %2 = 0.89120736006143533995180257787170353832 What could be the reason to interpret the user input 1.1 as real with precision of 53 bits instead of short way of specfying 11/10? Programming convenience? If you say well then the user should say 11/10 if she means it, this could be said as well with RealField(1.1), so what is the reason for this convention? Regards, -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] if I input 1.1, why is it real not rational?
On Friday, March 28, 2014 10:39:10 AM UTC+1, projetmbc wrote: I do not think that is really a convention, but it is very logical because 1.1 can also be a float result given by Python. But floats and decimals are not the same due to the ways operators act on them. But then it would be more logical to mark the output 1.1 as coming from a float, ideally giving the precision. But this would clutter the output of floats. So it is a convention. -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] if I input 1.1, why is it real not rational?
Your last comment is good. Maybe you can use Decimal(1.1) to avoid confusion. Le 28 mars 2014 10:57, Ralf Stephan gtrw...@gmail.com a écrit : On Friday, March 28, 2014 10:39:10 AM UTC+1, projetmbc wrote: I do not think that is really a convention, but it is very logical because 1.1 can also be a float result given by Python. But floats and decimals are not the same due to the ways operators act on them. But then it would be more logical to mark the output 1.1 as coming from a float, ideally giving the precision. But this would clutter the output of floats. So it is a convention. -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: graph.trace_faces() gives me inconsistent results
Oh, I forgot : it is indeed weird that faces may not exist in your version of Sage even though trace_faces is already deprecated,but everything seems to be fine in Sage 6.2.beta5. Sorry for that, I don't know where it comes from, but it will be fixed if you update your install :-) Nathann On 28 March 2014 15:08, Nathann Cohen nathann.co...@gmail.com wrote: Hello ! for a simple graph, trace_faces() gives the expected answer for the faces of a planar graph That's a good news :-D the face that should exist between just nodes 3,4 and 5 is not found, it's replaced with a face around nodes 1,2,3,4,5. Any ideas what is wrong, or other ways of getting an accurate list of the faces in a planar graph? What makes you think that the faces returned by Sage are wrong ? A planar graph can have different planar embeddings, and so different sets of faces. If you call .show() with a specific position for the vertices, this may result in a planar graph and you may see some faces defined, but there is no reason why .trace_faces() should return the faces using the positions you defined earlier for the plot ! In the documentation, .trace_faces() tells you that it can either find the embedding by itself, or use an embedding argument. In you case you did not define the embedding, so trace_faces() finds its own. As, just before, you called .is_planar(set_embedding=True), the embedding used by traces_faces() is the one that has been found by is_planar. But as you did not give to is_planar() the position of your vertices (and it does not accept positions of vertices as an input anyway),then is computes its own embedding. That's all. So unless you think that the faces returned by Sage do not correspond to a planar embedding, technically Sage makes no error. Now, if you want Sage to work with the position of the vertices you used for the plot, what you should do is write a short function which transforms (x,y) positions for the vertices into a combinatorial embedding. Then, you will be able to call .set_embedding() with that embedding, and then trace_faces() will give you the result that you expect, i.e. the faces defined by your embedding. And if you do that, please contribute to Sage by submitting your code, as I guess this would definitely be useful to others :-) Good luuuck ! Nathann I'm using 'Sage Version 5.13, Release Date: 2013-12-15' I realize that trace_faces has been deprecated to just faces() per this discussion: http://trac.sagemath.org/ticket/15551 but when I run S.faces() I get the error AttributeError: 'Graph' object has no attribute 'faces' -- You received this message because you are subscribed to a topic in the Google Groups sage-support group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-support/X8hc0AlTCB8/unsubscribe. To unsubscribe from this group and all its topics, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: graph.trace_faces() gives me inconsistent results
Hello ! for a simple graph, trace_faces() gives the expected answer for the faces of a planar graph That's a good news :-D the face that should exist between just nodes 3,4 and 5 is not found, it's replaced with a face around nodes 1,2,3,4,5. Any ideas what is wrong, or other ways of getting an accurate list of the faces in a planar graph? What makes you think that the faces returned by Sage are wrong ? A planar graph can have different planar embeddings, and so different sets of faces. If you call .show() with a specific position for the vertices, this may result in a planar graph and you may see some faces defined, but there is no reason why .trace_faces() should return the faces using the positions you defined earlier for the plot ! In the documentation, .trace_faces() tells you that it can either find the embedding by itself, or use an embedding argument. In you case you did not define the embedding, so trace_faces() finds its own. As, just before, you called .is_planar(set_embedding=True), the embedding used by traces_faces() is the one that has been found by is_planar. But as you did not give to is_planar() the position of your vertices (and it does not accept positions of vertices as an input anyway),then is computes its own embedding. That's all. So unless you think that the faces returned by Sage do not correspond to a planar embedding, technically Sage makes no error. Now, if you want Sage to work with the position of the vertices you used for the plot, what you should do is write a short function which transforms (x,y) positions for the vertices into a combinatorial embedding. Then, you will be able to call .set_embedding() with that embedding, and then trace_faces() will give you the result that you expect, i.e. the faces defined by your embedding. And if you do that, please contribute to Sage by submitting your code, as I guess this would definitely be useful to others :-) Good luuuck ! Nathann I'm using 'Sage Version 5.13, Release Date: 2013-12-15' I realize that trace_faces has been deprecated to just faces() per this discussion: http://trac.sagemath.org/ticket/15551 but when I run S.faces() I get the error AttributeError: 'Graph' object has no attribute 'faces' -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: graph.trace_faces() gives me inconsistent results
Nathann,
Thanks for your help! I'm fairly new to both Sage and graph theory, but I
understand the difference you point out, and it looks like the trace faces
function is giving me accurate faces for some valid planar embedding- just
not the one I thought it was working on. I spoke with a colleague
yesterday, and he helped come up with a solution. He tried to post his
results on this board, but I'm not seeing it, so I'm copy/pasting his
solution here. This is not the most efficient solution, but I've tested
in on a variety of real planar graphs, and it does work.
Ethans answer:
the problem is not their algorithm for finding faces, but the embedding.
The embedding should be a clockwise ordering of nodes, but if you look,
node 3's neighbors list in the embedding (s_emb[3]) is not clockwise. If
you reorder the nodes, it seems to work. See below.
import numpy
def reorder_embedding(emb, locs):
new_emb = {}
for i,neighbors in emb.iteritems():
def angle(b):
dx = locs[b][0] - locs[i][0]
dy = locs[b][1] - locs[i][1]
return numpy.arctan2(dx,dy)
reorder_neighbors = sorted(neighbors, key=angle)
new_emb[i] = reorder_neighbors
return new_emb
S = Graph(lat)
S.show(vertex_size = 600, pos = nodes_dict)
S.is_planar(set_embedding = True)
s_emb = S.get_embedding()
s_emb_r = reorder_embedding(s_emb, nodes_dict)
print SAGE embedding:, s_emb
print Reordered:, s_emb_r
faces = S.trace_faces(s_emb)
print SAGE faces:, faces
faces_r = S.trace_faces(s_emb_r)
print Reordered:, faces_r
--
You received this message because you are subscribed to the Google Groups
sage-support group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: if I input 1.1, why is it real not rational?
On Friday, March 28, 2014 2:34:55 AM UTC-7, Ralf Stephan wrote: while in Pari: ? sin(1.1) %1 = 0.89120736006143533995180257787170353832 ? sin(11/10) %2 = 0.89120736006143533995180257787170353832 Pari works with multiprecision by default, so you're getting more digits here: ? precision(1.1) %18 = 38 ? 10.0^39+1.0-10.0^39 %23 = 0.E1 so you're working with more precision than you might expect (this is on a 64-bit machine. The defaults on 32 bit are different) Furthermore, pari will increase number of digits it keeps track of under some conditions: ? precision(1.0+10^60) %24 = 115 It's certainly not the case that 1.1 is some kind of decimal or rational in pari: ? type(1.1) %25 = t_REAL and t_REAL is a binary float type (see docs). -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: if I input 1.1, why is it real not rational?
I think that Ralf's point is the following print (4.001^2).n(300) print ((4001/1000)^2).n(300) 16.0080013699597073136828839778900146484375 16.00800100 print sqrt(4.001).n(300) print sqrt(4001/1000).n(300) 2.00024998437695300523841979156713932752609252929687500 2.00024998437695281987761450010498155779765165614814745039069047372837143657067970643422267 which has nothing to do with Pari, but rather that we have the convention of once in a given precision, always there. Note the suspicious powers of 5 showing up (i.e. negative powers of 2) which presumably have nothing to do with the actual answer. At http://trac.sagemath.org/ticket/16025 he suggests raising a warning - I don't know if that is right, but it would be interesting to discuss whether this is user error or a bug or some third option. - kcrisman -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: graph.trace_faces() gives me inconsistent results
Christa,
The problem is not with the code, but your expectations of it (which
may be valid, but that would be a feature request and not a bug). You
expect the code to look at your planar position dictionary, and gin up
an embedding from that. That is not a bad idea, and possibly a good
feature to request.
What is actually happening is that you are asking the code to make a
new embedding, and compute the faces from that embedding. It is not
the same embedding as the one you want. If you gave it a 3-connected
planar graph, of course, the embedding (hence faces) would be unique
(up to orientation)... but your graph is not 3-connected.
To see the embedding those faces correspond to, try
S.is_planar(set_embedding = True, set_pos=True)
S.show()
Regards,
Tom
On Fri, Mar 28, 2014 at 9:24 AM, Christa Brelsford
christa.brelsf...@gmail.com wrote:
Nathann,
Thanks for your help! I'm fairly new to both Sage and graph theory, but I
understand the difference you point out, and it looks like the trace faces
function is giving me accurate faces for some valid planar embedding- just
not the one I thought it was working on. I spoke with a colleague
yesterday, and he helped come up with a solution. He tried to post his
results on this board, but I'm not seeing it, so I'm copy/pasting his
solution here. This is not the most efficient solution, but I've tested in
on a variety of real planar graphs, and it does work.
Ethans answer:
the problem is not their algorithm for finding faces, but the embedding.
The embedding should be a clockwise ordering of nodes, but if you look, node
3's neighbors list in the embedding (s_emb[3]) is not clockwise. If you
reorder the nodes, it seems to work. See below.
import numpy
def reorder_embedding(emb, locs):
new_emb = {}
for i,neighbors in emb.iteritems():
def angle(b):
dx = locs[b][0] - locs[i][0]
dy = locs[b][1] - locs[i][1]
return numpy.arctan2(dx,dy)
reorder_neighbors = sorted(neighbors, key=angle)
new_emb[i] = reorder_neighbors
return new_emb
S = Graph(lat)
S.show(vertex_size = 600, pos = nodes_dict)
S.is_planar(set_embedding = True)
s_emb = S.get_embedding()
s_emb_r = reorder_embedding(s_emb, nodes_dict)
print SAGE embedding:, s_emb
print Reordered:, s_emb_r
faces = S.trace_faces(s_emb)
print SAGE faces:, faces
faces_r = S.trace_faces(s_emb_r)
print Reordered:, faces_r
--
You received this message because you are subscribed to the Google Groups
sage-support group.
To unsubscribe from this group and stop receiving emails from it, send an
email to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
sage-support group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
[sage-support] Fwd: sage bug
-- Forwarded message -- From: aperry ape...@math.harvard.edu Date: Fri, Mar 28, 2014 at 5:25 PM Subject: sage bug To: wst...@uw.edu Hi, I'd like to report a bug in sage. There seems to be a problem with the functions that check whether two quadratic forms over Z are equivalent. Here is a sample of code that doesn't work correctly: Q1 = QuadraticForm(ZZ, 3, [-4,6*2,-2*2,-10,3*2,2]) Q2 = QuadraticForm(ZZ,3,[-14,9*2,34*2, -6, -21*2, -82]) Q3 = QuadraticForm(ZZ,3,[-14,9*2,34*2, -6, -21*2, -822]) [Q1.hasse_invariant(p) for p in prime_range(300)] [Q2.hasse_invariant(p) for p in prime_range(300)] [Q3.hasse_invariant(p) for p in prime_range(300)] Q1.is_globally_equivalent__souvigner(Q2) Q1.is_globally_equivalent__souvigner(Q3) Q1.is_globally_equivalent_to(Q2) Q1.is_globally_equivalent_to(Q3) Output: [-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1] [-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1] [1, -1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1] True True Error in lines 9-9 Traceback (most recent call last): File /projects/2d4ad217-a078-4d67-9d8b-0bf2c928d95d/.sagemathcloud/sage_server.py, line 733, in execute exec compile(block+'\n', '', 'single') in namespace, locals File , line 1, in module File /usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/quadratic_forms/quadratic_form__equivalence_testing.py, line 177, in is_globally_equivalent_to raise ValueError, not a definite form in QuadraticForm.is_globally_equivalent_to() ValueError: not a definite form in QuadraticForm.is_globally_equivalent_to() Some comments: 1. As the computation of the Hasse invariants show, Q1 and Q2 are equivalent over the rationals (you can check they have the same signature too), but Q3 is not equivalent to Q1. 2. Yet is_globally_equivalent__souvigner says that all of the forms are equivalent over Z, which is false. It seems that this function always returns true. 3. is_globally_equivalent_to should work for indefinite forms (such as Q1 and Q2), but it gives an error message saying something about the forms not being definite. 4. What I originally wanted to compute with this was the actual matrix conjugating Q1 to Q2 over Z (I do believe they are equivalent over Z). Sage should return this matrix with say Q1.is_globally_equivalent__souvigner(Q2, True), but this crashes. Thanks for any help with this, Alex -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] sage notebook in other browser
My default browser is firefox when i type *$ sage -notebook *it opens in firefox. Is there a way to specify other browser like *chromium-browser* -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] sage notebook in other browser
On Fri, 28 Mar 2014, Prakash Dey wrote: Is there a way to specify other browser like *chromium-browser* Should need only setting SAGE_BROWSER. See http://www.sagemath.org/doc/faq/faq-usage.html#how-do-i-get-started -- Jori Mäntysalo -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: sage notebook in other browser
Thank You Very much. Now I will be able to make a unity launcher for sage. -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
