Hi Alan,
I like that idea of providing a dual set of interfaces very much :). Yes, I
will take that responsibility. The details may need some iteration but at first
sight this looks good!
Regards,
Arjen
> -----Original Message-----
> From: Alan W. Irwin [mailto:[email protected]]
> Sent: Wednesday, October 15, 2014 6:52 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Fortran 95 changes in progress
>
> On 2014-10-15 08:07-0000 Arjen Markus wrote:
>
> > Hi Alan,
> >
> >
> >
> > I see some idiomatic problems with the current solution. For instance these
> > lines
> from x01.f90:
> >
> >
> > - x = xoff + xscale * arange(1_plint,size(x)+1) / real(size(x),plflt)
> > + x = xoff + xscale * arange(1_plint,size(x,kind=plint)+1) /
> > + real(size(x,kind=plint),plflt)
> > y = yoff + yscale * x ** 2_plint
> >
> >
> > The line to compute x first casts the size of x to a plint kind of integer
> > and then to a
> plflt kind of real.
> > The second argument in arange however uses +1 instead of +1_plint.
> > According to
> the rules of promotion that would result in either a plint or a default
> integer,
> depending on the range of both integer types.
> >
> >> From test_plf95demolib.f90:
> >
> >
> > + do i = 1_plint,size(start,kind=plint)
> >
> > Here we see a perfectly ordinary loop that has been transformed to use plint
> instead of default integers.
> >
> > What is troubling me, now that I see the result, is that the burden is now
> > put on the
> Fortran programmer, rather than on the interface. For the real variables we
> have no
> choice: the programmer may have either single- or double-precision built into
> the
> library and the plflt kind helps to distinguish them. In case of plint
> however the choice
> is dictated by the combination of the Fortran and C compilers.
> >
> > Instead of putting the kind in the user code, we can also put it in the
> > interface:
> >
> > call pladv( 0 ):
> >
> > interface pladv
> > module procedure pladv
> > end interface
> >
> > subroutine pladv_f( sub )
> > integer :: sub ! default integer
> >
> > call c_pladv( int(sub,kind=plint) ) end subroutine
> >
> > That way our examples and user code will not be affected. It is slightly
> > more work
> and less automateable though.
>
> Hi Arjen:
>
> I think the present result is a perfect example of making what seems to be a
> reasonable change only to realize once you see a practical example, that it
> was all a
> bad idea. :-(
>
> In other words, I definitely like your idea of "do everything with the
> interface" since it
> avoids a lot of "integer clutter" in the examples (and for the applications
> and libraries
> our users are writing). And I think a further implication is that there must
> be an
> additional interface change so that plint is defined privately in our
> interface and not
> accessible to users.
>
> In reviewing how we got to the present (badly cluttered) integer state, I
> realized we
> were trying to simply copy for integers what was done with the plflt type and
> plunicode type. So I think it is a no-brainer to extend your interface idea
> to the
> plunicode type as well.
>
> But beyond that no-brainer, I would like to extend your "do everything with
> the
> interface" idea further to deal with real arguments as well.
>
> Here is an example of what I think we should do.
>
> interface plcol1
> module procedure plcol14
> module procedure plcol18
> end interface
>
> contains
>
> subroutine plcol14( col )
> use plplot_types
> implicit none
> real(kind=4) :: col
> call c_plcol1( real(col,kind=c_plflt) ) end subroutine plcol14
>
> subroutine plcol18( col )
> use plplot_types
> implicit none
> real(kind=8) :: col
> call c_plcol1( real(col,kind=c_plflt) ) end subroutine plcol18
>
> This idea gives users the choice of calling plplot routines with all
> real(kind=4) arguments or all real(kind=8) arguments, and our interface sorts
> out the
> differences with function overloading. (Note, I am using short-hand here for
> the kind
> arguments, and I realize from what you have said before, that you would
> probably
> want to specify the two different real precisions in a more general way than
> 4 and 8.)
>
> If we adopt this way of handling real arguments, then this means we completely
> divorce the real precision users choose in their own code that calls routines
> in the
> Fortran binding of PLplot from the actual real precision used in our core C
> library. I
> think that is the ideal way to handle these floating-point precision
> questions. We
> could also reserve kind=plflt to describe the Fortran precision (as in our
> examples
> now, and also in current users applications), and introduce (as above) a
> private
> kind=c_plflt to describe the C precision. A further implication, then, is
> plflt would not
> appear in our interface at all, and instead would be defined as a convenience
> to
> users in the plf95demolib module.
>
> This, of course, is a completely new idea inspired by yours. Please let me
> know
> what you think of it (especially if you realize there are implications I
> haven't thought of
> yet.)
>
> With regard to the implementation of your idea for kind=plint, removing all
> the
> kind=plint, _plint, etc., changes from the examples can be completely
> automated with
> sed so I am willing to take responsibility for that. And my public kind=plflt
> and private
> kind=c_plflt extension of your idea essentially requires no changes to the
> examples
> (except to "use plf95demolib" to get access to the plflt definition.)
>
> The interface changes are going to require some substantial hand-editing work
> both
> for your idea and my extension of your idea, and I need to take a break from
> PLplot
> activity for quite a while (to work exclusively on timeephem except for my
> activities
> surrounding the next PLplot release). So will you take responsibility for
> editing those
> interface changes? (And assuming you say yes, let me know if you can finish
> those
> interface changes by early December or whether you need an extension of that
> tentative release deadline until
> January.)
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project
> (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi
> project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the
> Linux Brochure
> Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
