From: Andre Wobst <wobsta@us...>  20050126 09:59:23

Hi, On 25.01.05, Joerg Lehmann wrote: > > 3) Extend the function syntax to be "y(x)=sin(x)". > > pro: I kind of like that idea ... ;) > > con: It's a little unpythonic. At least we could easily make a > > smooth transition with a deprication warning on the old way of > > writing for several releases. > > Nice idea! Concerning the nonPythonic syntax: y = sin(x) is also not > the Python way of defining a function. And remember: Explicit is better > than implicit. You're right. "y = sin(x)" wasn't pythonic either. With "y(x) = sin(x)" we could think of removing the mathtree completely. We'll not need to find out anything about the variables on the right side. (To not yet question the existance of the mathtree, its definitely the way to go. I kind of like the idea of getting rid of the mathtree (at least in the function concept ... it still will be very usefull for fitting) since I want to get rid of the floatsonly concept in data/function/etc.handling. By that we could better support time axis (i.e. time data structures) and  even more important  it's also the crucial aspect to get rid of the splitaxis in favor of a slightly modified version of the baraxis (i.e. using tuples of an int and a float to access a specific part within a split axis ... and the modification should basically be limited to the painter) ... > > Probably, there are a lot of other solutions. Note also, that in the > > paramfunction you need to specify the variable parameter. But I think > > we sould leave that (and don't do anything like variant 3 for a > > parametric function) ... > > Maybe yes, x(t), y(t) = cos(t), sin(t) looks a bit clumsy. But > still... I would not bother too much. Currently the paramfunction needs three mandatory parameters to get enough information about the parameter of the parametric function (``t'' in the example above). We do have a minimum and maximum as well. Since the parametric function is a "nicetohave" feature, but its always easy to construct it from graph.data.list as well, I would not bother too much ... > > PS: You could stroke a horizontal line by > > g.stroke(g.xgridpath(<value>)) where g is a graph instance. But > > this doesn't help out of this design problem we have ... > > No, this is definitely not the solution. Sure it is a solution for something. But you're right: its not exactly a solution to the question raised. ;) André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 