On Tue, Feb 16, 2010 at 09:15:10AM +0100, Arjen Markus wrote: > On 2010-02-16 09:07, Alan W. Irwin wrote: > > On 2010-02-15 14:10-0500 Hazen Babcock wrote: > > > >> David MacMahon wrote: > >>> Adds support for arbitrary storage of 2D user data. This is very > >>> similar to the technique employed by some existing functions (e.g. > >>> plfcont and plfshade) that use "evaluator" functions to access 2D user > >>> data that is stored in an arbtrary format. > > >> Unless anyone objects I will test & commit this change in about a week. > > > > I think we need more time than that. How about two weeks, instead? It > > concerns me there has been no discussion of this API since David sent in the > > patch. If you like it please say so! Of course, if you don't like it, say > > so as well! > > > > I want to emphasize there was consensus on list (lead by Maurice) that an > > API to handle arbitrary 2D data storage was well worth having, and I am > > certainly willing to go along with that major change. However, I think it is > > important for everyone with good C skills here (that let's me out!) to take > > a good look at the overview of this implementation to be sure this new API > > is right for our needs. My point is there is going to be a lot of work > > propagating this to all our languages, updating our standard examples in all > > languages to use the new API, and also documenting the new API. So I ask > > for a thorough review of the new API in the next two weeks by those with > > good C skills. > > > > Hazen, by all means test the patch as well to make sure the implementation > > of the new API actually builds. But you should probably hold off on > > committing until everyone competent has had a chance to review the API to > > make sure this is the 2D array handling we want to have for the forseeable > > PLplot future. > > > > Dave, I thank you for your implementation work. It takes courage to be the > > first to implement something that is going to be thoroughly (I hope) > > reviewed by others, and I thank you for that courage! > > > > I have looked at the patch and it looks like a thorough method to > achieve the goal. However, it is a rather large change as Alan indicates > and I am not sure how it influences the current API. How about adapting > a (C) example for this? This ought to give us some insight as to how > to use this much more flexible scheme and possibly how to propagate it > to the other languages.
I agree with Arjen regarding the implementation. Some general points 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. 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? 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. The test should also multi-language tests to see if not copying large amounts of data around is quicker than having lots of callbacks. 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. 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. Sorry this is rather late in the discussion! Cheers Andrew ------------------------------------------------------------------------------ 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
