1 | initial version |
This is quite puzzling; if you update f
to the following, test3
now raises the runtime error (probably test2
too). It seems that the condition x > .5
is being evaluated while x
is still a variable instead of a number . . .
def f(x,y,t):
if x not in RR:
raise RuntimeError("checking x too soon")
if x > .5:
return(sin(pi*x)*sin(pi*y))
else:
return(sin(pi*x)*sin(pi*y)*e^(-t))
I also noticed that the plot3d
function seems to just call parametric_plot3d
in the end, so maybe working with parametric_plot3d
directly could help focus too.
2 | No.2 Revision |
This is quite puzzling; if you update f
to the following, test3
now raises the runtime error (probably test2
too). It seems that the condition x > .5
is being evaluated while x
is still a variable instead of a number . . .
def f(x,y,t):
if x not in RR:
raise RuntimeError("checking x too soon")
if x > .5:
return(sin(pi*x)*sin(pi*y))
else:
return(sin(pi*x)*sin(pi*y)*e^(-t))
I also noticed that the plot3d
function seems to just call parametric_plot3d
in the end, so maybe working with parametric_plot3d
directly could help focus too.
At this stage I guess I'm inclined to suggest that you define a full-blown class to handle making these plots -- then the value of t
can be an attribute of the class, as well as the appropriate function of x,y and the appropriate plot. If namespace issues are part of the problem, then making each frame a new instance of some general class will, I think, help to avoid them.