Thanks for the matplotlib recipe! I just had the same problem with
plot_vector_field not accepting coordinate functions of two arguments.
I went ahead and created an issue:
http://trac.sagemath.org/sage_trac/ticket/2381
- Eric
On Feb 17, 10:19 am, Hector Villafuerte [EMAIL PROTECTED] wrote:
OK, thanks. I am happy to report I downloaded the source successfully
using wget and compiled it in about 5 hours (AMD Athlon XP1800 - 1.5
GHz)
Chris
On Mar 3, 3:10 pm, Carlo Hamalainen [EMAIL PROTECTED]
wrote:
On Mon, Mar 3, 2008 at 8:01 PM, Chris S. [EMAIL PROTECTED] wrote:
As William
SAGE includes CVXOPT, which might include it in future releases.
We're in
the process of making simple interfaces to the ILP solvers in GLPK and
MOSEK,
and we have considered lpsolve also. The default solvers in CVXOPT
does
not handle integer constraints.
On Mar 4, 8:25 pm, Reckoner [EMAIL
Jason: wow, that was quick. I'll try out the plot_vector_field patch
as soon as I figure out how to test patches etc
I ended up using Hector's example and some things from the matplotlib
documentation for my assignment. A notable improvement is using
axis('tight'), which solves the window
Playing with splines for other reasons, I found what I beat down to the
following snippet (see attached)
*v = [] # Will hold points
step = 0.5 # Fineness of my approximation
for x in srange(0, 2*pi, step): # Fill parameter *v* with points
On Thu, Feb 28, 2008 at 9:36 AM, Kate [EMAIL PROTECTED] wrote:
What gives with the following session below?
More specifically, what happens to the file docstring
when the file has a .sage extension?
There is a bug in the .sage -- .py conversion process that
your example below illustrates.
Maybe I'm missing something, but what is your question?
--Mike
On Tue, Mar 4, 2008 at 12:00 PM, dean moore [EMAIL PROTECTED] wrote:
Playing with splines for other reasons, I found what I beat down to the
following snippet (see attached)
v = [] # Will hold points
When I used *step = 0.095*, I have 64 frames, close enough to the wikipedia
image's
of 66.
But resultant animation is choppy, where wikipedia's is fairly smooth.
I tinkered with a spline to smooth out a different curve, but it ran
fantastically slow, -- something
about too many points? -- so
