Hi, Andrew, Thanks for your review and thoughtful comments! Here are some replies.
On Feb 22, 2010, at 6:42 , Andrew Ross wrote: > 1) Using structures of function pointers in C is clearly the way to > implement this, but it might give us headaches for some languages > where > either function pointers or structures are not available. I thought about this point and hoped to alleviate any problems by not exposing the actual structures themselves. Instead I provide functions that return pointers to said structures. Languages that do not support function pointers or structures should at least be able to map the "pointer to structure" return values of these functions to integers. > 2) There are quite a few callback functions implemented. In most cases > we only need a get / set, although I can see that having the other > operators is (slightly) more efficient in that only one call is > required. > Does this make a noticeable difference? Even for functions that require only set or get, I chose to pass in a pointer to the structure to keep the API consistent. Functions that accept a pointer to a "plf2ops" structure yet use only one function pointer from that structure can simply declare a local function pointer and initialize it from the desired member of the structure. > 3) Talking of efficiency, I worry that this introduces a large > additional > level of complexity for a rather specialist set of cases where odd > data > storage methods are used. I am slightly relieved by David's comments, > but I would like to have a thorough comparison of the time difference. > This should include a "large data" case as well where timings might be > more important. The lena image might be one suitable case. As I said earlier, I share this concern. My 100x test was done using the Lena image, but I agree that further analysis would be reassuring (or not as the case may be). > The test > should also multi-language tests to see if not copying large amounts > of data around is quicker than having lots of callbacks. Sounds like a good idea. I think copying/transposing data will lose out because either it requires dynamic allocation in the bindings or puts the onus of copying/transposing the data onto the user. > 4) It terms of applications there are two big uses I can see > a) To simplify the langauge bindings (which is mostly hidden from the > user). > b) To allow the user to use odd data storage methods more > efficiently. I > can think of some interesting uses here like plotting a subset or > subsample of an array. It would be nice to include examples of > this. > This is potentially a much more generally useful outcome of this > from > a user point of view. I completely agree with these points. As I mentioned in an earlier email, I think 4b is a reason to consider implementing something similar for 1D data (e.g. to allow plotting of a single column of a 2D array)! > 5) Given the current mishmash of methods for dealing with 2-d arrays > then I would like to see this implemented consistently for all > functions which take 2-d data. Of course we need to ensure backwards > compatibility, but we should ensure the "new" interface is right from > the start. I tried to make API of new functions as consistent as possible. If you see any places where consistency could be improved, please let me know. The patch under discussion should maintain 100% backwards compatibility; any case where it doesn't is a bug! To maintain backwards compatibility, I did not modify the API of any existing functions. This includes functions, such as plfcont, that already accept a pointer to an "evaluator" function. Those functions are admittedly in an "in between" state. Perhaps new "plf2ops" variants of these functions could be created and the existing forms deprecated. > Sorry this is rather late in the discussion! IMHO, your content more than makes up for any delay! Thanks again, Dave ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
