ASKSAGE: Sage Q&A Forum - RSS feedhttps://ask.sagemath.org/questions/Q&A Forum for SageenCopyright Sage, 2010. Some rights reserved under creative commons license.Tue, 18 Sep 2012 21:15:01 +0200another "how to debug" issuehttps://ask.sagemath.org/question/8550/another-how-to-debug-issue/I primarily use Sage for numerical computation, working with numpy, scipy, gsl, R, etc. as well as my own interfaces to external software. Symbolic computing won't do much good on the types of problems I'm working on. I use Sage to have access to a wider variety of plotting options, as well as the wrappers and glue code. If it were possible, I would turn off symbolic computing completely as unnecessary overhead.
I've recently discovered that when running program 1 (say aaa.sage) followed by program 2 (bbb.sage), I get the not unusual error
TypeError: unable to simplify to float approximation
So I know I just need a float() somewhere to convert a symbolic value. If I exit Sage and start again, each program runs fine alone. It's only when the one is executed after the other that the error occurs. (I assume there's a way to clear the workspace without exiting, but I can't currently find it in the documentation).
The problem is Sage does not say where the error occurs. We've all seen the standard generic error pointing to:
exec(preparse_file(open(fpath).read()) + "\n", globals)
I now have large files of developed code and don't know how to find the offending line without laborious use of print statements. Any suggestions?
Tue, 13 Dec 2011 15:38:50 +0100https://ask.sagemath.org/question/8550/another-how-to-debug-issue/Comment by DSM for <p>I primarily use Sage for numerical computation, working with numpy, scipy, gsl, R, etc. as well as my own interfaces to external software. Symbolic computing won't do much good on the types of problems I'm working on. I use Sage to have access to a wider variety of plotting options, as well as the wrappers and glue code. If it were possible, I would turn off symbolic computing completely as unnecessary overhead. </p>
<p>I've recently discovered that when running program 1 (say aaa.sage) followed by program 2 (bbb.sage), I get the not unusual error
TypeError: unable to simplify to float approximation</p>
<p>So I know I just need a float() somewhere to convert a symbolic value. If I exit Sage and start again, each program runs fine alone. It's only when the one is executed after the other that the error occurs. (I assume there's a way to clear the workspace without exiting, but I can't currently find it in the documentation).</p>
<p>The problem is Sage does not say where the error occurs. We've all seen the standard generic error pointing to:
exec(preparse_file(open(fpath).read()) + "\n", globals)</p>
<p>I now have large files of developed code and don't know how to find the offending line without laborious use of print statements. Any suggestions?</p>
https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?comment=20714#post-id-20714To clear the defined variables, you can call "reset()". Could you add a reset() before running bbb to see what happens? (Hmm. On second thought, my first guess about what's going on -- variables leaking -- would produce the opposite symptom, namely that it would appear to work when run together but not when run separately.)Tue, 13 Dec 2011 15:50:56 +0100https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?comment=20714#post-id-20714Answer by niles for <p>I primarily use Sage for numerical computation, working with numpy, scipy, gsl, R, etc. as well as my own interfaces to external software. Symbolic computing won't do much good on the types of problems I'm working on. I use Sage to have access to a wider variety of plotting options, as well as the wrappers and glue code. If it were possible, I would turn off symbolic computing completely as unnecessary overhead. </p>
<p>I've recently discovered that when running program 1 (say aaa.sage) followed by program 2 (bbb.sage), I get the not unusual error
TypeError: unable to simplify to float approximation</p>
<p>So I know I just need a float() somewhere to convert a symbolic value. If I exit Sage and start again, each program runs fine alone. It's only when the one is executed after the other that the error occurs. (I assume there's a way to clear the workspace without exiting, but I can't currently find it in the documentation).</p>
<p>The problem is Sage does not say where the error occurs. We've all seen the standard generic error pointing to:
exec(preparse_file(open(fpath).read()) + "\n", globals)</p>
<p>I now have large files of developed code and don't know how to find the offending line without laborious use of print statements. Any suggestions?</p>
https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?answer=12059#post-id-12059Oh, I just remembered [`trace`](http://www.sagemath.org/doc/reference/sage/misc/trace.html#sage.misc.trace.trace) too -- type 's' to step through each line of a command execution using the python debugger `pdb`.Wed, 14 Dec 2011 09:13:10 +0100https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?answer=12059#post-id-12059Answer by burningbright for <p>I primarily use Sage for numerical computation, working with numpy, scipy, gsl, R, etc. as well as my own interfaces to external software. Symbolic computing won't do much good on the types of problems I'm working on. I use Sage to have access to a wider variety of plotting options, as well as the wrappers and glue code. If it were possible, I would turn off symbolic computing completely as unnecessary overhead. </p>
<p>I've recently discovered that when running program 1 (say aaa.sage) followed by program 2 (bbb.sage), I get the not unusual error
TypeError: unable to simplify to float approximation</p>
<p>So I know I just need a float() somewhere to convert a symbolic value. If I exit Sage and start again, each program runs fine alone. It's only when the one is executed after the other that the error occurs. (I assume there's a way to clear the workspace without exiting, but I can't currently find it in the documentation).</p>
<p>The problem is Sage does not say where the error occurs. We've all seen the standard generic error pointing to:
exec(preparse_file(open(fpath).read()) + "\n", globals)</p>
<p>I now have large files of developed code and don't know how to find the offending line without laborious use of print statements. Any suggestions?</p>
https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?answer=13010#post-id-13010Good advice.
Using %debug after the bug occurs does not help, still can't get any more information. Have not tried a trace.
Another approach I will try is to use ipython's "who" and look for a variable name used in both files.
Thanks to all.Wed, 14 Dec 2011 10:39:36 +0100https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?answer=13010#post-id-13010Answer by niles for <p>I primarily use Sage for numerical computation, working with numpy, scipy, gsl, R, etc. as well as my own interfaces to external software. Symbolic computing won't do much good on the types of problems I'm working on. I use Sage to have access to a wider variety of plotting options, as well as the wrappers and glue code. If it were possible, I would turn off symbolic computing completely as unnecessary overhead. </p>
<p>I've recently discovered that when running program 1 (say aaa.sage) followed by program 2 (bbb.sage), I get the not unusual error
TypeError: unable to simplify to float approximation</p>
<p>So I know I just need a float() somewhere to convert a symbolic value. If I exit Sage and start again, each program runs fine alone. It's only when the one is executed after the other that the error occurs. (I assume there's a way to clear the workspace without exiting, but I can't currently find it in the documentation).</p>
<p>The problem is Sage does not say where the error occurs. We've all seen the standard generic error pointing to:
exec(preparse_file(open(fpath).read()) + "\n", globals)</p>
<p>I now have large files of developed code and don't know how to find the offending line without laborious use of print statements. Any suggestions?</p>
https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?answer=13007#post-id-13007Well, debugging will be laborious I think. But instead of print statements I think [`verbose`](http://www.sagemath.org/doc/reference/sage/misc/misc.html#sage.misc.misc.verbose) is at least a little easier.
* First, it automatically prints the name of the function it's embedded in; you can narrow in on the bug pretty quickly by just putting `verbose('working..')` in some key places (of course, something even more informative would be better).
* Second, it's off by default -- you turn it on with `set_verbose(n)`. So you can insert a bunch of `verbose` statements instead of print statements, turn verbose on to see what's happening, and then turn it back off when you don't want to see anymore.
There's also some "level" functionality, which I don't quite understand but has to do with function calls within function calls within ... The purpose, I guess, is to avoid being overloaded with the verbose output of sub sub sub routines.Wed, 14 Dec 2011 09:08:32 +0100https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?answer=13007#post-id-13007Answer by burningbright for <p>I primarily use Sage for numerical computation, working with numpy, scipy, gsl, R, etc. as well as my own interfaces to external software. Symbolic computing won't do much good on the types of problems I'm working on. I use Sage to have access to a wider variety of plotting options, as well as the wrappers and glue code. If it were possible, I would turn off symbolic computing completely as unnecessary overhead. </p>
<p>I've recently discovered that when running program 1 (say aaa.sage) followed by program 2 (bbb.sage), I get the not unusual error
TypeError: unable to simplify to float approximation</p>
<p>So I know I just need a float() somewhere to convert a symbolic value. If I exit Sage and start again, each program runs fine alone. It's only when the one is executed after the other that the error occurs. (I assume there's a way to clear the workspace without exiting, but I can't currently find it in the documentation).</p>
<p>The problem is Sage does not say where the error occurs. We've all seen the standard generic error pointing to:
exec(preparse_file(open(fpath).read()) + "\n", globals)</p>
<p>I now have large files of developed code and don't know how to find the offending line without laborious use of print statements. Any suggestions?</p>
https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?answer=14044#post-id-14044These days, my solution is just to write code under sage in pure python (.py), not .sage files, and avoid the obfuscation of the Sage pre-processor. This way my code is always immediately exportable out of the sage environment (with import statements as necessary).Tue, 18 Sep 2012 14:25:37 +0200https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?answer=14044#post-id-14044Comment by kcrisman for <p>These days, my solution is just to write code under sage in pure python (.py), not .sage files, and avoid the obfuscation of the Sage pre-processor. This way my code is always immediately exportable out of the sage environment (with import statements as necessary).</p>
https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?comment=19046#post-id-19046You could also conceivably use the `from sage.all import *` - would that turn on preparsing? That is, if you needed something Sage-specific; sometimes less is more, perhaps that's so in your case.Tue, 18 Sep 2012 21:15:01 +0200https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?comment=19046#post-id-19046Answer by Volker Braun for <p>I primarily use Sage for numerical computation, working with numpy, scipy, gsl, R, etc. as well as my own interfaces to external software. Symbolic computing won't do much good on the types of problems I'm working on. I use Sage to have access to a wider variety of plotting options, as well as the wrappers and glue code. If it were possible, I would turn off symbolic computing completely as unnecessary overhead. </p>
<p>I've recently discovered that when running program 1 (say aaa.sage) followed by program 2 (bbb.sage), I get the not unusual error
TypeError: unable to simplify to float approximation</p>
<p>So I know I just need a float() somewhere to convert a symbolic value. If I exit Sage and start again, each program runs fine alone. It's only when the one is executed after the other that the error occurs. (I assume there's a way to clear the workspace without exiting, but I can't currently find it in the documentation).</p>
<p>The problem is Sage does not say where the error occurs. We've all seen the standard generic error pointing to:
exec(preparse_file(open(fpath).read()) + "\n", globals)</p>
<p>I now have large files of developed code and don't know how to find the offending line without laborious use of print statements. Any suggestions?</p>
https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?answer=13011#post-id-13011Can you post the whole traceback? I've never seen a traceback that doesn't include the line where it happens.
It seems like you are hurting because you rely on global variables. The real solution is not to track down the offending global variable, but to write code that doesn't use global variables. Its simple, just create objects that encapsulate your data.Wed, 14 Dec 2011 11:54:11 +0100https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?answer=13011#post-id-13011Comment by jdc for <p>Can you post the whole traceback? I've never seen a traceback that doesn't include the line where it happens. </p>
<p>It seems like you are hurting because you rely on global variables. The real solution is not to track down the offending global variable, but to write code that doesn't use global variables. Its simple, just create objects that encapsulate your data.</p>
https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?comment=20710#post-id-20710Could you give a short example of what you mean, Volker? Like a before-and-after?Wed, 14 Dec 2011 12:11:46 +0100https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?comment=20710#post-id-20710Comment by burningbright for <p>Can you post the whole traceback? I've never seen a traceback that doesn't include the line where it happens. </p>
<p>It seems like you are hurting because you rely on global variables. The real solution is not to track down the offending global variable, but to write code that doesn't use global variables. Its simple, just create objects that encapsulate your data.</p>
https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?comment=20708#post-id-20708Yes, avoiding the global namespace in even my highest level code files would solve the problem of interference from the workspace. I do try to use modular code and classes as much as possible, but currently there's still a lot of junk in my main routine, which is then treated like global variables when other code is subsequently called. Something to thing about. Variable isolation would help with other common code development bugs, such as forgetting to initialize a variable in code because it runs using a pre-existing variable in the workspace.Wed, 14 Dec 2011 17:29:38 +0100https://ask.sagemath.org/question/8550/another-how-to-debug-issue/?comment=20708#post-id-20708