# Revision history [back]

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.

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.