> The code leaves a lot to be desired. For example, now that we have > fast_callable, with CDF support, we should be using that. Actually, > we're using the helper function setup_for_eval_on_grid (to normalize > the boundaries) and then ignoring the returned function, so this > check is completely useless.
Yes, that would be very good. Would that be hard to implement (for someone who didn't write fast_callable or fast_float, that is, as they are busy enough :) )? > > As for being a function of one or two variables, it's unclear what > the best approach is to take here. Clearly we want to allow plotting > complex functions of a complex variable, but the alternative is > useful too. For functions, the number (and names) of the arguments > they take is explicit, but for expressions like sin(z) or x+y+i it's > not as obvious. Does the x in plot3d(x+1, ...) stand for the real > part of the complex argument, or the entire thing? Or perhaps the > bounds should be complex numbers defining the rectangle, like The current notation is fine for now. The problem is that my plot3d was in fact a real-valued function, and my complex_plot function was a nice complex-valued one, but they both went boom. The remark about input was just an aside, sorry for obscuring the main point. - kcrisman --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
