On 2014-09-11 09:42-0000 Arjen Markus wrote: > Hi Alan,
> I will get back to this. No time today to read it carefully. I see no obvious flaws in our reasoning, but the devil is in the details. Hi Arjen: Normally this is true for most computer endeavours. but for this case we don't have to get those "devilish" details absolutely correct at first. Therefore, I suggest we start with integer, parameter :: plint = 4 integer, parameter :: plunicode = 4 in bindings/f95/plflt.inc.in. Here is why. I have noted your concerns about using kind=4 in case some Fortran compiler supports more than one kind of 4-byte integer, but in fact the Intel compiler documentation <https://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/fortran-mac/GUID-F93AE784-EF45-468F-9F42-46283B47F3B3.htm> mentions that Fortran has no unsigned integer types and also mentions only c_int32_t and not c_uint32_t in conformance with that idea. Furthermore, it states c_int32_t is equivalent to 4. Also, the NAG Fortran documentation at <http://www.nag.com/nagware/np/r51_doc/iso_c_binding.html> implies you are always sure of doing the right thing with kind=4, but with kind = c_int32_t, you could get a negative result if some compiler manufacturer has not bothered to fill in the data in its table of types. So the implication is using 4 like above rather than c_int32_t is actually a safer/more universal way to specify a Fortran integer kind. If it turns out the above choice is not a good one for certain compilers, we can always add special cases for those or make some other adjustment in bindings/f95/plflt.inc.in without any further massive editing required (once I edit our bindings and examples to replace all instances of integer by integer(kind=plint). By the way, the reason I am bringing this up again now is my timeephem mini-project <https://sourceforge.net/p/timeephem/feature-requests/1/> is drawing to a close so there will be a short time (probably during the middle of this week) where it is convenient for me to work on PLplot doing the sed editing referred to above before I start working on the next timeephem mini-project <https://sourceforge.net/p/timeephem/feature-requests/2/>. Since you have kindly agreed to be the chief Windows tester for timeephem, you might also be personally interested that I am mentally planning three additional converters as well (one for the JPL binary SPICE format, two for the special ascii and binary formats used by the Russian ephemeris team) so that ultimately ephcom will be able to convert all "foreign" ascii and binary formats for planetary and time ephemerides to the native ephcom binary format that is used by that software to actually interpolate ephemeris results (planetary, solar, and lunar positions/velocities, nutation, lunar libration, and time ephemeris integrals and vectors for the Earth) with high speed and high numerical precision for any epoch within the range of epochs represented by an ephemeris. 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 __________________________ ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
