Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2002-11-06 18:03:56
|
After this next release is out the door I hope to make some substantial changes in how we call our current 3D routines, plot3d, plmesh, plsurf3d, plcont, plshade, and plshades. Currently we have a nonuniform mixture of API's for the way we pass 3D information to our 3D routines. For example, many routines don't worry about a defined region and plcont and plshade(s) have a generalized method of passing z, x, y which allows using arbitrary methods (e.g., pltr0, pltr1, pltr2, etc.) of evaluating the data while the rest of the routines (plot3d, plmesh, plsurf3d) don't use a generalized method of passing 3D information so their capabilities are much more limited as a result. This lack of a generalized method of passing 3D information to plot3d, plmesh, and plsurf3d has become a real problem for my own research work. Typically my z arrays are defined with either fixed nx and ny a function of x index or fixed ny with nx a function of y index. It should not be a problem for me to define more pltr variations that will handle these cases, but the lack of a generalized method of passing information to plot3d, plmesh, and plsurf3d also needs to be addressed as well. One unavoidable issue is whether we are willing to go through the necessary API changes to get these problems fixed. My own view is changes in API are permissible so long as there is a compelling reason. In the present case a common API rather than the present non-uniform API for passing 3D information to our 3D routines is IMO already a compelling enough reason for change. To be more specific the nx, ny issue above a compelling reason. For years gnuplot has had the facility of allowing ny to be a function of x index or nx be a function of y index for all 3D routines, and PLplot has suffered in comparison. I was willing to accept this PLplot limitation in 1995 because gnuplot axis labelling sucked in the 3D case, but that does not have to mean we must accept this PLplot limitation indefinitely. I should also emphasize if we do decide to change to a common 3D information passing API, that we give a strong warning to our users. I suggest the best way to make such a strong warning is a special release of PLplot with just the 3D information passing API change. I would be happy to do that once the present release is out the door and we have implemented the API change. What I would like to encourage now is discussion of what the ideal 3D information passing API should be with the discussion unconstrained by any 3D passing API decisions we have made in the past. My C skills (such as they are) have been solely developed by looking at code in PLplot so it is hard for me to think outside that box in a creative way. However, I believe the current 3D argument lists are way too cluttered with z, nx, ny, and x and y index range limits. Surely all that stuff could be made part of the general struct that is needed in any case to pass the 3D information to the 3D routine? It should also be kept in mind that in general either nx is a function of y index or ny is a function of x index. Maurice, I know you have thought quite a bit about the problem of passing 3D information to our 3D routines in the past and also the corresponding problem for the 3D defined region information so I am hoping you will open the discussion on what you think that ideal API should be. I am also hoping that your vision will be so compelling that your post will also effectively close the ideal API discussion....;-) Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
|
From: Maurice L. <mj...@ga...> - 2002-11-09 10:22:35
|
Alan W. Irwin writes:
> After this next release is out the door I hope to make some substantial
> changes in how we call our current 3D routines, plot3d, plmesh, plsurf3d,
> plcont, plshade, and plshades.
>
> Currently we have a nonuniform mixture of API's for the way we pass 3D
> information to our 3D routines. For example, many routines don't worry about
> a defined region and plcont and plshade(s) have a generalized method of
> passing z, x, y which allows using arbitrary methods (e.g., pltr0, pltr1,
> pltr2, etc.) of evaluating the data while the rest of the routines (plot3d,
> plmesh, plsurf3d) don't use a generalized method of passing 3D information
> so their capabilities are much more limited as a result.
>
> This lack of a generalized method of passing 3D information to plot3d,
> plmesh, and plsurf3d has become a real problem for my own research work.
> Typically my z arrays are defined with either fixed nx and ny a function of
> x index or fixed ny with nx a function of y index. It should not be a
> problem for me to define more pltr variations that will handle these cases,
> but the lack of a generalized method of passing information to plot3d,
> plmesh, and plsurf3d also needs to be addressed as well.
I personally don't use surface plotting very often, as the data I deal with
tends to be a tad too noisy for it to be useful. So I never got around to
generalizing these.
As for what an "uber-API" for these would look like, we can look at the API
for the fattest plcont/plshade plot calls we have and go from there. For
contours:
plfcont(PLFLT (*f2eval) (PLINT, PLINT, PLPointer),
PLPointer f2eval_data,
PLINT nx, PLINT ny, PLINT kx, PLINT lx,
PLINT ky, PLINT ly, PLFLT *clevel, PLINT nlevel,
void (*pltr) (PLFLT, PLFLT, PLFLT *, PLFLT *, PLPointer),
PLPointer pltr_data);
and for shades:
plshade_int(PLFLT (*f2eval) (PLINT, PLINT, PLPointer),
PLPointer f2eval_data,
PLFLT (*c2eval) (PLINT, PLINT, PLPointer),
PLPointer c2eval_data,
PLINT (*defined) (PLFLT, PLFLT),
PLFLT missing_min, PLFLT missing_max,
PLINT nx, PLINT ny,
PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax,
PLFLT shade_min, PLFLT shade_max,
PLINT sh_cmap, PLFLT sh_color, PLINT sh_width,
PLINT min_color, PLINT min_width,
PLINT max_color, PLINT max_width,
void (*fill) (PLINT, PLFLT *, PLFLT *), PLINT rectangular,
void (*pltr) (PLFLT, PLFLT, PLFLT *, PLFLT *, PLPointer),
PLPointer pltr_data);
(gulp). The shade plotter has the exclusion region that the contour plotter
is missing, so if that capability were added to the contourer the two could
share that in common. Possibly with the (*defined) argument changed to:
void (*defined) (PLFLT, PLFLT, PLINT *, PLPointer),
PLPointer defined_data);
as I mentioned some time back (but never got around to doing it).
'Course the real trick is to define simpler front-ends that do the job at hand
80%-95% of the time. So plshades() is a step in the right direction. Also
the kx, lx, ky, ly args in the contour plotter are rarely exercised so I'd
personally leave them out of a simpler general-purpose API (they were there in
plplot 2.6 and I left them in). The way I look at it is: as long as you can
get at the "fat" API in C, someone facing a special need can always code up a
special interface routine for whatever binding they employ.
I also firmly believe that preserving the existing API should be a priority,
except when dealing with relatively newly-added calls for which some period
of flux is to be expected. People use different versions of plplot on
different machines; you don't want them to be *too* afraid to upgrade.
--
Maurice LeBrun mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)
|
|
From: Maurice L. <mj...@ga...> - 2002-11-09 10:30:09
|
p.s. as far as allowing a nx(j) or ny(i) dependence, I have no idea. Never thought about it before, and after a quick look at the code I'm not hopeful that there's an easy way to support it. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Alan W. I. <ir...@be...> - 2002-11-09 17:10:34
|
On Sat, 9 Nov 2002, Maurice LeBrun wrote: > p.s. as far as allowing a nx(j) or ny(i) dependence, I have no idea. Never > thought about it before, and after a quick look at the code I'm not hopeful > that there's an easy way to support it. I haven't looked at the code in detail, but I am just going on the documentation here. All pltr2 seems to do is interpolate (with boundary checks). So shouldn't it be straightforward to make variations on pltr2 that accept and use a PLPointer which includes either the nx(j) information or ny(i) information? I realize that such variations are not all that needs to be done by a long shot, but if these fundamental bits are possible, then I think the rest should be straightforward for all 3D API's that currently reference an interpolater such as pltr2. Alan |
|
From: Maurice L. <mj...@ga...> - 2002-11-10 01:13:28
|
Alan W. Irwin writes: > On Sat, 9 Nov 2002, Maurice LeBrun wrote: > > > p.s. as far as allowing a nx(j) or ny(i) dependence, I have no idea. Never > > thought about it before, and after a quick look at the code I'm not hopeful > > that there's an easy way to support it. > > I haven't looked at the code in detail, but I am just going on the > documentation here. All pltr2 seems to do is interpolate (with boundary > checks). So shouldn't it be straightforward to make variations on pltr2 > that accept and use a PLPointer which includes either the nx(j) information > or ny(i) information? I realize that such variations are not all that needs > to be done by a long shot, but if these fundamental bits are possible, then > I think the rest should be straightforward for all 3D API's that currently > reference an interpolater such as pltr2. I don't think this belongs in pltr(), because it is called so deep in the loop. You need something that can influence the control structure, so we're probably talking about function arguments e.g. (*fnx)(j) & (*fny)(i), for which the default is to return a constant (nx & ny, respectively). The bigger problem is reordering the loops in order to support *both* nx(j) and ny(i) -- the varying one needs to be in the inner loop of course. So in general you'll need two versions of each plotter. One of those will have the loop order swapped from what it is now, which means lots of logic changes in the interior of the loop (go look). An additional complication is that the shade & contour plotters use different loop ordering already. I haven't looked at the 3d plotters. Looks like an awful lot of work. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Alan W. I. <ir...@be...> - 2002-11-10 15:54:49
|
On Sat, 9 Nov 2002, Maurice LeBrun wrote: > Alan W. Irwin writes: > > I haven't looked at the code in detail, but I am just going on the > > documentation here. All pltr2 seems to do is interpolate (with boundary > > checks). So shouldn't it be straightforward to make variations on pltr2 > > that accept and use a PLPointer which includes either the nx(j) information > > or ny(i) information? I realize that such variations are not all that needs > > to be done by a long shot, but if these fundamental bits are possible, then > > I think the rest should be straightforward for all 3D API's that currently > > reference an interpolater such as pltr2. > > I don't think this belongs in pltr(), because it is called so deep in the > loop. You need something that can influence the control structure, so we're > probably talking about function arguments e.g. (*fnx)(j) & (*fny)(i), for > which the default is to return a constant (nx & ny, respectively). > > The bigger problem is reordering the loops in order to support *both* nx(j) > and ny(i) -- the varying one needs to be in the inner loop of course. So in > general you'll need two versions of each plotter. One of those will have the > loop order swapped from what it is now, which means lots of logic changes in > the interior of the loop (go look). An additional complication is that the > shade & contour plotters use different loop ordering already. I haven't > looked at the 3d plotters. > > Looks like an awful lot of work. In my own case, the nx(y) and ny(x) limits are monotonic so my data can be transformed from one form to the other. Thus, I would need only one choice implemented which would greatly simplify the change. OTOH, this would introduce a certain lack of generality which would disappoint other users with irregularly defined regions which cannot be transformed from the nx(y) form to the ny(x) form. Perhaps the other idea of filling out the undefined region of the rectangle with constant z(i,j), x(i,j), and y(i,j) from the last point on the boundary would work instead. Naively, I would think the contourer, shader, and other 3D routines would just keep hammering at the boundary values as it swept through i,j of the extended region and thus produce acceptable results. Alan |
|
From: Alan W. I. <ir...@be...> - 2002-11-09 17:09:54
|
On Sat, 9 Nov 2002, Maurice LeBrun wrote: > Alan W. Irwin writes: > > Currently we have a nonuniform mixture of API's for the way we pass 3D > > information to our 3D routines. > As for what an "uber-API" for these would look like, we can look at the API > for the fattest plcont/plshade plot calls we have and go from there. > [...](gulp). The shade plotter has the exclusion region that the contour plotter > is missing, so if that capability were added to the contourer the two could > share that in common. Possibly with the (*defined) argument changed to: > > void (*defined) (PLFLT, PLFLT, PLINT *, PLPointer), > PLPointer defined_data); > > as I mentioned some time back (but never got around to doing it). Thanks for these suggestions. > 'Course the real trick is to define simpler front-ends that do the job at hand 80%-95% of the time. So plshades() is a step in the right direction. Also the kx, lx, ky, ly args in the contour plotter are rarely exercised so I'd personally leave them out of a simpler general-purpose API (they were there in plplot 2.6 and I left them in). I never use those kx, lx, ky, ly limits so I also wouldn't mind personally if they went. > > I also firmly believe that preserving the existing API should be a priority, > except when dealing with relatively newly-added calls for which some period > of flux is to be expected. People use different versions of plplot on > different machines; you don't want them to be *too* afraid to upgrade. I understand your concerns here, but OTOH we shouldn't be afraid to change if there are compelling reasons to do so and we give plenty of warning to our users. Moving to a uniform API for passing 3D information to our 3D routines may already be compelling enough reason, but let's clinch the deal by making it the best API we can think of. So after the next release I will think hard about your suggestions, and also the nx(iy) or ny(ix) problem (see next post) to see what I can come up with. Alan |
|
From: Joao C. <jc...@fe...> - 2002-11-09 19:36:25
|
On Saturday 09 November 2002 17:09, Alan W. Irwin wrote: > On Sat, 9 Nov 2002, Maurice LeBrun wrote: > > Alan W. Irwin writes: > > > Currently we have a nonuniform mixture of API's for the way we pas= s 3D > > > information to our 3D routines. > > > > As for what an "uber-API" for these would look like, we can look at t= he > > API for the fattest plcont/plshade plot calls we have and go from the= re. > > > > [...](gulp). The shade plotter has the exclusion region that the con= tour > > plotter is missing, so if that capability were added to the contourer= the > > two could share that in common. Possibly with the (*defined) argumen= t > > changed to: > > > > void (*defined) (PLFLT, PLFLT, PLINT *, PLPointer), > > PLPointer defined_data); > > > > as I mentioned some time back (but never got around to doing it). As a matter of fact I prefer to have the possibility to exclude regions u= sing=20 data instead of using a function, as seldon we have such function but we=20 might have the data where the data is invalid (say nan/inf/nd -- the ieee= =20 standard does not define "nd", not defined, some software uses one of the= =20 possible nan values to specify non-valid data). > Thanks for these suggestions. > > > 'Course the real trick is to define simpler front-ends that do the jo= b at > > hand 80%-95% of the time. So plshades() is a step in the right directi= on. > Also the kx, lx, ky, ly args in the contour plotter are rarely exercise= d so > I'd personally leave them out of a simpler general-purpose API (they we= re > there in plplot 2.6 and I left them in). > > I never use those kx, lx, ky, ly limits so I also wouldn't mind persona= lly > if they went. > > > I also firmly believe that preserving the existing API should be a > > priority, I agree. plshades() is a good direction. Dont' remove/redefine old API=20 entries, instead we must provide new/easier to use API entries. With time, we can even put a plwarn() in the old API, saying that they ca= n be=20 replaced with the new one, and will eventually be removed. > except when dealing with relatively newly-added calls for which > > some period of flux is to be expected. People use different versions= of > > plplot on different machines; you don't want them to be *too* afraid = to > > upgrade. > > I understand your concerns here, but OTOH we shouldn't be afraid to cha= nge > if there are compelling reasons to do so and we give plenty of warning = to > our users. warnings is not enought, if users have a big amount of software they must= =20 rewrite. Remember, the Pentium 4 still executes instructions for the now = more=20 then 10 years old i8086! Joao > Moving to a uniform API for passing 3D information to our 3D > routines may already be compelling enough reason, but let's clinch the = deal > by making it the best API we can think of. > > So after the next release I will think hard about your suggestions, and > also the nx(iy) or ny(ix) problem (see next post) to see what I can com= e up > with. > > Alan > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
|
From: Alan W. I. <ir...@be...> - 2002-11-10 01:59:30
|
On Sat, 9 Nov 2002, Joao Cardoso wrote: > I agree. plshades() is a good direction. Dont' remove/redefine old API entries, instead we must provide new/easier to use API entries. With time, we can even put a plwarn() in the old API, saying that they can be replaced with the new one, and will eventually be removed. Some proliferation of API like this at the C level is probably worth it. But the interfaces also have a role that can be played. For example, in my user-friendly python interface, I define a lot of different simplified API's for plcont, plshade, and plshades without having to use different names. It is extremely easy to do this in python because it is an object-oriented language. Since C++, java, tcl (via itcl), and even perl have OO, then it should be easy to translate what I have done in python to those other languages as well. > > I understand your concerns here, but OTOH we shouldn't be afraid to change > > if there are compelling reasons to do so and we give plenty of warning to > > our users. > > warnings is not enought, if users have a big amount of software they must > rewrite. They also have the option of sticking with an old stable version such as PLplot-5.1.0 so "must" is too strong a statement. The exact same debate often rages for the Linux kernel with e.g., binary module makers such as the nvidia video card company wanting no change. But Linus refuses to be constrained by such arguments and suggests those who want the old stable kernel API should stick with that old stable kernel version. The result is an evolving kernel that remains a lot cleaner and easier to maintain than it otherwise would. However, that said I do appreciate the concern expressed by you and Maurice so *when the time comes* we should also discuss the option of adding a whole new set of plplot 3D calls named the same way as the old-fashioned calls but with a trailing "u" in the name standing for uniform 3d API. But let's bring up this "add API" versus "change API" discussion again only if/when this becomes relevant. For example, I am only interested in making this change if the new API contains the possibility of nx(y) or ny(x) for *all* of our 3D calls. That's the "killer app" feature for me. This capability has long been a standard feature of gnuplot. It is needed for my equation of state data at low temperatures and high densities where no equation of state results can be calculated. Right now for PLplot I am forced to extend the data into this forbidden zone using a constant value, but the results look fairly ugly and are a bad advertisement for PLplot. Come to think of it, right now I guess it would be possible to extend the x(ix,iy) and y(ix,iy) arrays with constant values as well. I haven't tried this, but it might give a nice looking result for plcont, plshade, and plshades with the pltr2 interpolator (which deals well with x(ix,iy) and y(ix,iy)) passed as an argument. But if that worked, I would also need a new API for plot3d, plmesh, and plsurf3d to allow them to accept a pltr pointer and use it properly inside. Of course that possibility is part of the "best API" discussion that I hope we continue to have. Alan |
|
From: Maurice L. <mj...@ga...> - 2002-11-10 02:42:27
|
Alan W. Irwin writes: > Some proliferation of API like this at the C level is probably worth it. But > the interfaces also have a role that can be played. For example, in my > user-friendly python interface, I define a lot of different simplified API's > for plcont, plshade, and plshades without having to use different names. It > is extremely easy to do this in python because it is an object-oriented > language. Since C++, java, tcl (via itcl), and even perl have OO, then it > should be easy to translate what I have done in python to those other > languages as well. Alas, but iTcl doesn't support method overloading by number of arguments (or type, naturally, as Tcl's typeless). The best you can do is use default args. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X