From: Alan G I. <ai...@am...> - 2008-07-20 19:52:55
|
It is probably too late for this change but ... The name of pyx.graph.data.function has always bugged me. 1. A class by that name really should take a python function as an argument. 2. The string argument that the current class takes instead is really an expression that specifies that values of a function y(x). It is probably too late to rename it (e.g., to ``functiondef``) but perhaps it could *also* accept a Python function? (Using a Python function what I usually want, and I would like not to be forced to know anything about the context.) Cheers, Alan Isaac |
From: Michael S. <m-s...@us...> - 2008-07-21 09:21:35
|
On 20.07.08, Alan G Isaac wrote: > It is probably too late for this change but ... > > The name of pyx.graph.data.function has always bugged me. > > 1. A class by that name really should take a python function > as an argument. Why? Applying your logic to the discussion we had about pyx.graph.data.points and pyx.graph.data.values would mean that both should be called "pyx.graph.data.list". Note that the name pyx.graph.data.function describes the _meaning_ of the plotting type (as differencing it from discrete data) and not the _data_type_ which it takes. > 2. The string argument that the current class takes instead > is really an expression that specifies that values of a > function y(x). > > It is probably too late to rename it (e.g., to ``functiondef``) "functiondef" is not to my liking. It resembles too much the definition of a function, which is not what it does. > but perhaps it could *also* accept a Python function? > (Using a Python function what I usually want, and I would > like not to be forced to know anything about the context.) Note that the expression string does more than just providing any function. It also indicates how to use it. I use for example things like "y(x) = f(x)" "x(y) = f(y)" "y2(x) = g(x)" How would you propose to add these functionality to the case where you give a function object? Of course, one could add more string parameters to indicate where the function evaluates y, y2 or even x, but does that simplify anything? Michael |
From: Alan G I. <ai...@am...> - 2008-07-24 21:33:18
|
>> perhaps it could also accept a Python function? (Using >> a Python function what I usually want, and I would like >> not to be forced to know anything about the context.) On Mon, 21 Jul 2008, Michael SCHINDLER apparently wrote: > Note that the expression string does more than just providing any > function. It also indicates how to use it. I use for example things > like > "y(x) = f(x)" > "x(y) = f(y)" > "y2(x) = g(x)" > How would you propose to add these functionality to the case where > you give a function object? Of course, one could add more string > parameters to indicate where the function evaluates y, y2 or even x, > but does that simplify anything? OK, I am probably not understanding what you mean here by "how to use it". What functionality are you getting? Autosetting of columnnames? If so, I would add a parameter with ['x','y'] as the default. If you meant something else, I am not understanding. Alan |
From: Joerg L. <jo...@us...> - 2008-07-28 14:35:28
|
Hello Alan, On 24.07.08, Alan G Isaac wrote: > OK, I am probably not understanding what you mean here by > "how to use it". What functionality are you getting? > Autosetting of columnnames? If so, I would add a parameter > with ['x','y'] as the default. If you meant something else, > I am not understanding. Yes, I guess that is what Michael meant. But I have to say that sometimes it would really be useful to use Python functions directly, in particular since this would allow you to use closures. Consequently, such an interface would also not need the "context" argument! Whether simply passing columnnames as a list or a more explicit interface would be preferable is not so clear to me, though. I think I would prefer a clearer signature like pyx.graph.data.python_func(f, "x", "y") with the last two arguments being the default values. Btw, there are also use cases with tuples, which also have to be considered. André, what is your opinion on this issue? Cheers, Jörg |
From: Alan G I. <ai...@am...> - 2008-07-28 16:22:43
|
On Mon, 28 Jul 2008, Joerg Lehmann apparently wrote: > I have to say that sometimes it would really be useful to > use Python functions directly, in particular since this > would allow you to use closures. Consequently, such an > interface would also not need the "context" argument! Yes, being able to ignore context is a convenience I have been stressing. I do not care much about the name, of course, but would like ``pyfunc`` or possibly ``pyfunction`` better, if this will be a new data type. Cheers, Alan |