2020-04-29 15:43:16 +0200 | received badge | ● Notable Question (source) |

2017-06-29 20:46:54 +0200 | received badge | ● Popular Question (source) |

2016-11-14 23:28:40 +0200 | received badge | ● Famous Question (source) |

2015-08-07 00:23:37 +0200 | received badge | ● Notable Question (source) |

2014-12-30 08:30:27 +0200 | commented question | notebook and init.sage Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "_sage_input_5.py", line 10, in <module>
exec compile(u'open("___code___.py","w").write("# - File "/tmp/tmpNZTIvb/___code___.py", line 3, in <module> exec compile(u"attach('CartesianCoord.sage')" + '\n', '', 'single') File "", line 1, in <module> File "sage/misc/lazy_import.pyx", line 358, in sage.misc.lazy_import.LazyImport.__call__ (build/cythonized/sage/misc/lazy_import.c:3230) File "/home/sage/sage-6.4.1/local/lib/python2.7/site-packages/sage/misc/attached_files.py", line 344, in attach load(filename, globals(), attach=True) File "/home/sage/sage-6.4.1/local/lib/python2.7/site-packages/sage/misc/preparser.py", line 1792, in load exec(code, globals) File "/home/sage/.sage/temp/ubuntu/3303/CartesianCoord.sageaIwXL1.py", line 5, in <module> var ... (more) |

2014-12-30 08:29:55 +0200 | commented question | notebook and init.sage I'm really sorry about the large delays in my replies. First, I used load_attach_path because I thought it was necessary for attach to know where to find files. I did not start using it because of the cited issue. So, I have a cell and it contains: load_attach_path('/home/sage/Documents/SageProjects/OrthogonalCoordinates') attach('CartesianCoord.sage') CartesianCoord.sage is in the directory named in the load_attach_path, and it contains: var('q_1,q_2,q_3,x_1,x_2,x_3') and evaluation results in an error message I will post in another comment, because there isn't enough space left in this comment. |

2014-12-07 09:28:26 +0200 | commented question | notebook and init.sage As far as "properly" is concerned, I'm not sure I ever did use it properly. I just wanted to reuse sage code and the load_attach_path/attach seemed to work just fine. I never tried or used the capability of sage to keep track of changes to attached files and re-execute, as it seems it should be able to do. Using load_attach_path/load works (tried at your suggestion, thank you) so I'm fine. I was using attach in the first place because I did not know better. |

2014-10-18 18:48:44 +0200 | received badge | ● Scholar (source) |

2014-10-18 18:38:16 +0200 | received badge | ● Commentator |

2014-10-18 18:38:16 +0200 | commented answer | Attaching files in notebook has not worked since 5.10 It doesn't look like load works either. The error is different ("name 'Integer' is not defined" as opposed to "name 'var' is not defined"), but the end result is the same. Oh, wait. It does work. I had an "attach" inside the file I had changed to "load". It worked after I changed the embedded "attach" to "load". |

2014-09-22 14:34:16 +0200 | received badge | ● Student (source) |

2014-09-21 07:15:46 +0200 | asked a question | Attaching files in notebook has not worked since 5.10 This has been reported in http://trac.sagemath.org/ticket/15308. But it doesn't look like fixing it is a very high priority for anyone that knows what they are doing - unfortunately I don't have a clue. There is a comment that a workaround might be: "Your problem seems to be that init.sage is evaluated before Sage is started. A workaround might be to use a .py file starting with from sage.all import *" Can anyone help with telling me how to make use of this suggestion? |

2013-11-12 19:19:51 +0200 | received badge | ● Popular Question (source) |

2013-10-20 00:12:16 +0200 | commented question | notebook and init.sage I have a problem that may be related. I use load_attach_path followed by attach. I get the error "NameError: name 'var' is not defined" from within the attached file. I am using Ubuntu 12.04 x64 and using the Sage notebook. This worked in 5.10 and stopped working in 5.11. |

2013-09-13 16:18:36 +0200 | received badge | ● Famous Question (source) |

2013-02-06 22:18:43 +0200 | received badge | ● Notable Question (source) |

2012-12-29 21:05:27 +0200 | commented answer | Failure to install database_gap in sage 5.5 Great! That worked. Thanks! |

2012-12-29 15:33:48 +0200 | asked a question | Failure to install database_gap in sage 5.5 And the question is, of course, does anybody know why and what I might be able to do to fix it. This is sage version 5.5, built from source on ubuntu server x64 12.10. After the build finished, I successfully installed openssl and pyopenssl. But database_gap installation failed. As an additional note, I also tried the same thing with sage 5.5 on ubuntu desktop x64 10.04 with similar results. I tried to install database_gap, as advised by the build from source readme, using the command: And I got the results: |

2012-11-11 12:14:05 +0200 | received badge | ● Popular Question (source) |

2012-02-26 03:30:52 +0200 | commented answer | square root No, I guess. If x=-1, which is a complex number, x^2 is still 1, and sqrt(1) is 1. The problem is that, no matter what, there are multiple solutions for sqrt(x^2). And sometimes, x just isn't equal to sqrt(x^2). |

2012-02-26 03:22:58 +0200 | commented answer | square root The real numbers are not closed under square root. sqrt(-1) is not a real number. But sqrt(-1) is a valid complex number. For some real numbers x, x=sqrt(x^2), is not true. But for all complex numbers x, x=sqrt(x^2) IS true. Isn't it? |

2012-02-26 02:58:26 +0200 | commented answer | square root "Yes. If it is real. But if we are dealing in the complex numbers, it would work, would it not? That's why I was wondering if there was a way I could make it so x_1, x_2 and x_3 were complex variables. But I didn't ask so well." (comment should precede above) |

2012-02-26 02:09:35 +0200 | commented answer | square root Great! And for me, it would be a good idea to finish it off with: forget(x_1>0) so the end result can be used without the constraint. Feels a bit like cheating, avoiding the things that make you safe. But, that's what I was asking for! Thanks! |

2012-02-26 01:39:34 +0200 | commented answer | square root That is better. I don't suppose you know how to get rid of the last square root; i.e. x_1 instead of sqrt(x_1^2)? |

2012-02-26 00:57:32 +0200 | asked a question | square root I am continually running into the problem where square roots defeat any attempt to simplify an expression. For example: should simplify to x_1. I understand the reason sage hesitates to simplify a square root. But being unable to force the issue is starting to render sage almost completely useless. Does anybody know how to get sage to simplify these types of expressions? simplify_radical does not work. The closest I can come is to square the expression first, then simplify and take the square root. That still does not get rid of the final square root. I wonder if making the expression complex might work, and if so, how might I do that? |

2011-04-10 05:05:12 +0200 | commented answer | Composite function Thank you for the alternative. For the moment it looks like non-lambda functions work well. I'm not well versed in python and I'd like to make things look as much like mathematical notation as possible. Also, it seems using other properties (methods, functions?) like jacobian and derivative is more straight forward if lambda functions are avoided. |

2011-04-09 20:08:29 +0200 | commented answer | Composite function Great! And very quick, thank you. I suppose I would have known that if I knew something about python? Or is * a sage operator of some sort? |

2011-04-09 20:06:00 +0200 | received badge | ● Supporter (source) |

2011-04-09 19:35:42 +0200 | received badge | ● Editor (source) |

2011-04-09 19:32:57 +0200 | asked a question | Composite function If I define: var('x,y,z,t') g(t) = (t, t^2, t^3) f(x,y,z) = (2 Is there a way for me to define the composite f(g(t)) without going through: f(g(t)[0],g(t)[1],g(t)[2]) or something equally ugly? |

Copyright Sage, 2010. Some rights reserved under creative commons license. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.