On Fri, Oct 10, 2008 at 2:33 PM, Maurice LeBrun <[EMAIL PROTECTED]> wrote: > On Friday, October 10, 2008 at 09:10:59 (-0400) Hezekiah M. Carty writes: > > On Fri, Oct 10, 2008 at 12:09 AM, Maurice LeBrun <[EMAIL PROTECTED]> wrote: > > > > What do you think of this as a compromise? Nothing has to be > > > > propagated to other language bindings, and the plgvpw functionality > > > > becomes (I think) more intuitive. > > > > > > I have to admit to being a little bothered by this change. The plP_gvpw > > > private function is a good way to shield internal workings from this > change, > > > but begs the larger question: what should plgvpw() actually return? I > can see > > > three classes of opinion on the topic: > > > > > > 1. plgvpw() MUST return exactly what I specified in plwind() > > > 2. plgvpw() MUST return exactly what the plot library's actually using > > > 3. either is "good enough" > > > > > > There are good arguments for both 1 & 2. (2) is what we're using now, > moving > > > to (1) is the proposal. The people in category (1) could reverse the > delta > > > easily enough, as long as it was documented & didn't change. The people > in > > > category (2) could do the same, on old code that's long since been > forgotten > > > about. The vast majority in (3) will never notice. > > > > > > As a user, I'm in category (3), and don't *really* care either way. But > be > > > aware you are introducing a change that has the potential to change > existing > > > code behavior. > > > > Maurice, > > > > Thank you for your feedback on this. > > > > My extra argument for position (1) is that, for some viewport > > dimensions, the delta is not cleanly reversible due to floating point > > rounding errors. Adding the delta to get the (2) case does not have > > this floating point rounding problem so the values for (2) are always > > retrievable if the values from (1) are still available. > > Ah.. right. OK, seems a good enough reason to proceed with (1). > > > The proposal is certainly a change to plgvpw's prior behavior. But > > being able to retrieve the case (1) information from PLplot is, I > > think, quite important as it relieves the user from having to track > > this information which leaves less for the user to keep track of on > > their own, and hopefully less room for user error. It will also make > > adding new PLplot-related functions (such as legends or interactions > > with external Cairo surfaces) much cleaner since these functions can > > retrieve the user-provided information directly from PLplot. > > > > If it is too close to the 5.9.1 release to consider a change like > > this, perhaps it could be reconsidered after 5.9.1 is released? > > Maybe better to do it now, so that the issue is still fresh in case any issues > arise.
Sounds good to me. If this is acceptable to the rest of the core PLplot devs then I am quite happy. Please let me know when/if the commit hits and I will test it further. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
