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?
asked Dec 13 '11burningbright
33 ● 6
Well, debugging will be laborious I think. But instead of print statements I think
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.
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.
posted Dec 14 '11burningbright
33 ● 6
Can 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.
posted Dec 14 '11Volker Braun
2666 ● 9 ● 24 ● 59
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).
posted Sep 18 '12burningbright
33 ● 6
Asked: Dec 13 '11
Seen: 240 times
Last updated: Sep 18 '12
powered by ASKBOT version 0.7.22
Copyright Sage, 2010. Some rights reserved under creative commons license.