Re: [Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

[Joao C. <jc...@fe...>]

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