On 2007-12-28 12:13+0100 Arjen Markus wrote: > Andrew Ross wrote: > >> >> >>> Ah yes. I should have looked more closely at this. Was there a reason >>> you didn't do this for the plvect / plcont functions in the F95 >>> bindings? I'm not sure I would advocate changing this now as we already >>> have plvect / plcont implemented, although with different arguments to >>> their C counterparts. Perhaps you could think about this? >>> >>> Andrew >>> >>> >>> > With respect to the matter of providing a transformation function to > plcont() and plvect(): > I have looked at the current API and have considered possible solutions > to make the > F77 and F95 versions more like the C counterparts. > > The problem is not passing a function name - that is easy and has been > around in Fortran > for many decades. The real problem is passing arbitrary data to the > function, as Fortran > (up to F2003, that is) has no equivalent for C's void pointers (void *data). > > I can see a number of solutions, none of them very appealing: > > - For F77 we would be stuck with a single argument, for instance an > array holding all the > required data. That is awkward, if you need to combine integers and > reals. It can be done > though. > - For F95 the type system allows you to gather all information into a > derived type (equivalent > in C: a struct), but then the compiler will complain that the argument > has to be of the right type. > You could get around it via the transfer() function, but that requires > quite some understanding > on the user's side. > Another way would be to keep the plcont() and plvect() routines (or > specially named versions > of them) out of the PLplot module. Some compilers might still complain > though: you would > be passing derived types to routines that essentially are expected to > have a F77-compatible > interface. > > Alternatives: > - For F95 define a suitable derived type that can be expected to be > useful for most applications. > That way we would have an interface that makes the compiler happy. > - For F77 and F95, let the function itself take care of the data that it > needs. In F77 you could > use a COMMON block, in F95 you could use module data. > > I hesitate to go ahead and implement either one of these solutions, > though the two alternatives > give the best and most robust solutions (though not the most general). > > Does anyone feel strongly about extending the Fortran API in this way or > shall we leave it > as it is as far as these functions are concerned?
Hi Arjen: If you have not done so already, you might want to look at what our Fortran bindings do for plcont, plshade, and plshades. We have special fortran API in all those cases because of the problems (I assume) of passing arbitrary data for the call back function like is possible with C. Come to think of it, though, none of these solutions are very satisfying. I recently had a similar problem with FreeEOS where I was writing a generalized BFGS minimization routine to work properly for a huge variety of different functions to be minimized with a large variety of argument lists. The solution was to use reverse communication, a Fortran engineering technique invented to just solve this problem. With this technique the generalized routine completely avoids using a callback function. Instead it communicates with the outside world with a all-purpose integer or character-string switch which tells the calling routine please call me again with such-and-such requested data (function value, gradient value, or whatever depending on the switch) supplied for this independent variable (or variables). Then the calling routine calls any routine it likes with the supplied independent variables and feeds back the requested results to the generalized routine (say plcont) which then does something with those results (such as plotting them). Reverse communication is a common technique used for many Fortran numerical libraries (see results of a google search for the two terms fortran and "reverse communication"). It worked well for my BFGS minimization problem, and I think it may be the answer to our fortran troubles with plcont, plshade, plshades, and plvect. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
