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 __________________________ ------------------------------------------------------------------------------ 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
