From: Alan W. I. <ir...@be...> - 2012-10-21 07:21:44
Attachments:
CMakeLists.txt
config.h.cmake
|
I used ndiff (a really useful fuzzy diff) to analyze the differences between the C and Python results. If you are interested in using that application yourself, you can download, verify, and signature check it using wget ftp://ftp.math.utah.edu/pub/misc/ndiff-2.00.tar.gz wget ftp://ftp.math.utah.edu/pub/misc/ndiff-2.00.tar.gz.sig gpg --verify ndiff-2.00.tar.gz.sig Furthermore, after unpacking copy the two attached files (constituting a new CMake-based build system for ndiff I just implemented in the last hour) into the top of the ndiff-2.00 source tree then build it using mkdir build_dir cmake ../ndiff-2.0.0 make This creates the newly compiled ndiff executable in the separate build tree which is really all you need. This build system for ndiff should work on Unix without issues, but I will leave it to Arjen to try it out in the Windows case, if he is interested in a fuzzy diff which ignores small relative or absolute numerical differences between the two files. The command for INDEX in 03 04 05 06 08 09 11 12 14a 15 16 17 18 19 20 21 22 23 25 \ 26 27 29 33; do echo "index = $INDEX"; \ /home/software/ndiff/build_dir/ndiff -relerr 1.e-03 x${INDEX}c.psc \ x${INDEX}p.psc ; done |less showed relatively few (just examples 17, 19, 20, 22, 25, and 29) of those C-Python PostScript differences were numerically significant. Furthermore, when I checked those visually, the only really large difference was the 3rd page of example 19 which was completely messed up in the Python version for some reason. The example 23 stdout difference was 1c1 < For example 23 prior to page 12 the FCI is 0x80000000 --- > For example 23 prior to page 12 the FCI is 0x80000000L which is a trivial although it would be nice to get rid of this difference. In sum, aside from the 3rd page of example 19, python on Wine seems to be working well. Arjen, do you get similar Python results (small relative differences but no large ones other than page 3 of example 19) on Windows? 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 __________________________ |
From: Andrew R. <and...@us...> - 2012-10-22 20:04:20
|
Alan, Thanks for the testing. I have briefly looked at ndiff in the past. Useful for this kind of thing! I seem to recall that the python issues are partly a 32-bit / 64-bit issue. I think that on my old 32 bit system (no longer in use) I used to see some non-significant differences with the python examples. In particular the issue in the standard error with example 23 is due to this. Python integers as signed 32 bit integers on a 32-bit system. The FCI variables are 32-bit unsigned, so have to be stored in a long integer on a 32-bit python system, hence the L tagged on the end. I failed to find an easy way to get rid of this, but that doesn't mean there isn't one. No problem on 64-bit systems. Andrew On Sun, Oct 21, 2012 at 12:21:36AM -0700, Alan Irwin wrote: > I used ndiff (a really useful fuzzy diff) to analyze the differences > between the C and Python results. > > If you are interested in using that application yourself, you > can download, verify, and signature check it > using > > wget ftp://ftp.math.utah.edu/pub/misc/ndiff-2.00.tar.gz > wget ftp://ftp.math.utah.edu/pub/misc/ndiff-2.00.tar.gz.sig > gpg --verify ndiff-2.00.tar.gz.sig > > Furthermore, after unpacking copy the two attached files (constituting > a new CMake-based build system for ndiff I just implemented in the > last hour) into the top of the ndiff-2.00 source tree then build it > using > > mkdir build_dir > cmake ../ndiff-2.0.0 > make > > This creates the newly compiled ndiff executable in the separate build > tree which is really all you need. This build system for ndiff should > work on Unix without issues, but I will leave it to Arjen to try it > out in the Windows case, if he is interested in a fuzzy diff which > ignores small relative or absolute numerical differences between the > two files. > > The command > > for INDEX in 03 04 05 06 08 09 11 12 14a 15 16 17 18 19 20 21 22 23 25 \ > 26 27 29 33; do echo "index = $INDEX"; \ > /home/software/ndiff/build_dir/ndiff -relerr 1.e-03 x${INDEX}c.psc \ > x${INDEX}p.psc ; done |less > > showed relatively few (just examples 17, 19, 20, 22, 25, and 29) of > those C-Python PostScript differences were numerically significant. > Furthermore, when I checked > those visually, the only really large difference was the 3rd page > of example 19 which was completely messed up in the Python version > for some reason. The example 23 stdout difference was > > 1c1 > < For example 23 prior to page 12 the FCI is 0x80000000 > --- > >For example 23 prior to page 12 the FCI is 0x80000000L > > which is a trivial although it would be nice to get > rid of this difference. > > In sum, aside from the 3rd page of example 19, python on Wine seems to > be working well. Arjen, do you get similar Python results (small > relative differences but no large ones other than page 3 of > example 19) on Windows? > > 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 > __________________________ > # The autoconf-based build of ndiff is beginning to break down so this > # is the start of the implementation of an equivalent build system > # using CMake. This is just a first proof-of-concept attempt to build > # ndiff and not even bother to test or install it. But at least the > # build appears to work and so does the resulting ndiff executable. > > # Top-level CMakeLists.txt boilerplate. > project(ndiff C) > cmake_minimum_required(VERSION 2.8.2 FATAL_ERROR) > > # Configure everything in config.h which must have > # specific values of 1 or 0 > > set(HAVE_LONG_DOUBLE 0) > find_file(HAVE_CTYPE_H ctype.h) > if(HAVE_CTYPE_H) > set(HAVE_CTYPE_H 1) > else(HAVE_CTYPE_H) > set(HAVE_CTYPE_H 0) > endif(HAVE_CTYPE_H) > > find_file(HAVE_LIMITS_H limits.h) > if(HAVE_LIMITS_H) > set(HAVE_LIMITS_H 1) > else(HAVE_LIMITS_H) > set(HAVE_LIMITS_H 0) > endif(HAVE_LIMITS_H) > > find_file(HAVE_STDDEF_H stddef.h) > if(HAVE_STDDEF_H) > set(HAVE_STDDEF_H 1) > else(HAVE_STDDEF_H) > set(HAVE_STDDEF_H 0) > endif(HAVE_STDDEF_H) > > find_file(HAVE_STDIO_H stdio.h) > if(HAVE_STDIO_H) > set(HAVE_STDIO_H 1) > else(HAVE_STDIO_H) > set(HAVE_STDIO_H 0) > endif(HAVE_STDIO_H) > > find_file(HAVE_STDLIB_H stdlib.h) > if(HAVE_STDLIB_H) > set(HAVE_STDLIB_H 1) > else(HAVE_STDLIB_H) > set(HAVE_STDLIB_H 0) > endif(HAVE_STDLIB_H) > > find_file(HAVE_STRING_H string.h) > if(HAVE_STRING_H) > set(HAVE_STRING_H 1) > else(HAVE_STRING_H) > set(HAVE_STRING_H 0) > endif(HAVE_STRING_H) > > # Code uses HAVE_GMP rather than the expected HAVE_GMP_H > find_file(HAVE_GMP gmp.h) > if(HAVE_GMP) > set(HAVE_GMP 1) > else(HAVE_GMP) > set(HAVE_GMP 0) > endif(HAVE_GMP) > > configure_file( > ${CMAKE_CURRENT_SOURCE_DIR}/config.h.cmake > ${CMAKE_CURRENT_BINARY_DIR}/config.h > @ONLY > ) > > # Build the ndiff executable: > include_directories( > ${CMAKE_CURRENT_SOURCE_DIR} > ${CMAKE_CURRENT_BINARY_DIR} > ) > > set(ndiff_SRC > ndiff.c > store.c > awklib.c > regexp/regexp.c > regexp/regerror.c > ) > > add_executable(ndiff ${ndiff_SRC}) > > # That wasn't so hard, was it? > // Note that ndiff code uses old-fashioned #defines with values > // which must be either true or false, rather than the #ifdef style. > > // Define if the `long double' type works. > #define HAVE_LONG_DOUBLE @HAVE_LONG_DOUBLE@ > > // Define to `unsigned' if <sys/types.h> doesn't define. > // #define size_t > > // Define if you have the ANSI C header files. > //#define STDC_HEADERS @STDC_HEADERS@ > > // Define if you have the <ctype.h> header file. > #define HAVE_CTYPE_H @HAVE_CTYPE_H@ > > // Define if you have the <limits.h> header file. > #define HAVE_LIMITS_H @HAVE_LIMITS_H@ > > // Define if you have the <stddef.h> header file. > #define HAVE_STDDEF_H @HAVE_STDDEF_H@ > > // Define if you have the <stdio.h> header file. > #define HAVE_STDIO_H @HAVE_STDIO_H@ > > // Define if you have the <stdlib.h> header file. > #define HAVE_STDLIB_H @HAVE_STDLIB_H@ > > // Define if you have the <string.h> header file. > #define HAVE_STRING_H @HAVE_STRING_H@ > > // Define if have the <gmp.h> header file. > #define HAVE_GMP @HAVE_GMP@ > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2012-10-22 23:24:55
|
Hi Andrew: One of my recent posts to PLplot-devel included a rudimentary but still useful CMake-based build system for ndiff. I have now (revision 12250) made that available in external/ndiff along with instructions on how to use it. I encourage you to expand that build system if you have additional needs (e.g., installation which should take basically 10 minutes to add). I often wondered why nobody packaged ndiff for Debian, but I suspect the problem is lack of installation relocatability for the current aged and bit-rotted build system. I think you get installation relocability automatically with the new CMake-based build system (using the DESTDIR variable in the make command) so if you happened to be interested in packaging ndiff for Debian, this CMake-based build system would be a useful first step toward that goal. 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 __________________________ |
From: Andrew R. <and...@us...> - 2012-10-25 17:46:33
|
On Mon, Oct 22, 2012 at 04:24:48PM -0700, Alan Irwin wrote: > Hi Andrew: > > One of my recent posts to PLplot-devel included a rudimentary but > still useful CMake-based build system for ndiff. I have now (revision > 12250) made that available in external/ndiff along with instructions > on how to use it. I encourage you to expand that build system if you > have additional needs (e.g., installation which should take basically > 10 minutes to add). > > I often wondered why nobody packaged ndiff for Debian, but I suspect > the problem is lack of installation relocatability for the current > aged and bit-rotted build system. I think you get installation > relocability automatically with the new CMake-based build system > (using the DESTDIR variable in the make command) so if you happened to > be interested in packaging ndiff for Debian, this CMake-based build > system would be a useful first step toward that goal. Alan, As you may have noticed I've updated your work to properly install the binary + man page, as well as linking against the gmp library properly if that is detected. I think a half decent implementation should still check for the long double support as well implementing the tests. Andrew |
From: Alan W. I. <ir...@be...> - 2012-10-25 19:00:14
|
On 2012-10-25 18:46+0100 Andrew Ross wrote: > On Mon, Oct 22, 2012 at 04:24:48PM -0700, Alan Irwin wrote: >> Hi Andrew: >> >> One of my recent posts to PLplot-devel included a rudimentary but >> still useful CMake-based build system for ndiff. I have now (revision >> 12250) made that available in external/ndiff along with instructions >> on how to use it. I encourage you to expand that build system if you >> have additional needs (e.g., installation which should take basically >> 10 minutes to add). >> >> I often wondered why nobody packaged ndiff for Debian, but I suspect >> the problem is lack of installation relocatability for the current >> aged and bit-rotted build system. I think you get installation >> relocability automatically with the new CMake-based build system >> (using the DESTDIR variable in the make command) so if you happened to >> be interested in packaging ndiff for Debian, this CMake-based build >> system would be a useful first step toward that goal. > > Alan, > > As you may have noticed I've updated your work to properly install the > binary + man page, as well as linking against the gmp library properly if > that is detected. Hi Andrew: Thanks for those useful additions. > I think a half decent implementation should still check > for the long double support as well implementing the tests. Agreed. I will take a look at both of those now since they would be useful in their own right for PLplot developers and also if you decide to package up the result for Debian. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2012-11-01 10:26:42
|
On 2012-10-25 12:00-0700 Alan W. Irwin wrote: > On 2012-10-25 18:46+0100 Andrew Ross wrote: > >> On Mon, Oct 22, 2012 at 04:24:48PM -0700, Alan Irwin wrote: >>> Hi Andrew: >>> >>> One of my recent posts to PLplot-devel included a rudimentary but >>> still useful CMake-based build system for ndiff. I have now (revision >>> 12250) made that available in external/ndiff along with instructions >>> on how to use it. I encourage you to expand that build system if you >>> have additional needs (e.g., installation which should take basically >>> 10 minutes to add). >>> >>> I often wondered why nobody packaged ndiff for Debian, but I suspect >>> the problem is lack of installation relocatability for the current >>> aged and bit-rotted build system. I think you get installation >>> relocability automatically with the new CMake-based build system >>> (using the DESTDIR variable in the make command) so if you happened to >>> be interested in packaging ndiff for Debian, this CMake-based build >>> system would be a useful first step toward that goal. >> >> Alan, >> >> As you may have noticed I've updated your work to properly install the >> binary + man page, as well as linking against the gmp library properly if >> that is detected. > > Hi Andrew: > > Thanks for those useful additions. > >> I think a half decent implementation should still check >> for the long double support as well implementing the tests. > > Agreed. I will take a look at both of those now since they would be > useful in their own right for PLplot developers and also if you > decide to package up the result for Debian. Hi Andrew: I have just (revision 12265) finished implementing the requested test system. It works perfectly on Linux for the present hard-coded set(HAVE_LONG_DOUBLE 0), and works well (but not perfectly for a possible reason discussed in the commit message) on MinGW/MSYS/Wine. It might also produce perfect test results on Windows (only with MinGW+MSYS since MSYS is needed for the tests) for the reasons I indicated in the commit message. The above paragraph was all about the set(HAVE_LONG_DOUBLE 0) case. As expected (because Intel long double is 80-bits rather than 128-bits) if you change the CMakeLists.txt file to use set(HAVE_LONG_DOUBLE 1), some tests fail since the ndiff results are being compared with ndiff results determined in 2000 with a ndiff version that had access to 128-bit floating point. Some code changes to ndiff.c (I think you would have to use the gcc extension type __float128) would presumably get around this problem, but then you would be stuck with software emulation of 128-bit floating-point arithmetic operations which would likely make ndiff much slower. So I recommend you don't go there. The present test system will likely produce perfect results for the case (which I didn't bother to try) when the gmp library is installed on Linux. I have run out of time for anything more, but if you are keen to really polish it further, then tests for whether LONG DOUBLE, size_t, and STDC_HEADERS exist on the platform could be implemented in CMakeLists.txt and config.h.cmake modified accordingly. Also, the original build system allowed the user to force HAVE_LONG_DOUBLE and HAVE_GMP (presumably followed by tests to make sure those were available) so cmake command-line options for such forcing options might be worth implementing as well. As usual for a new build system, MinGW + MSYS tests are especially requested on Windows to verify my good Wine results. (Note the previous request for such tests was for shapelib. This request is for ndiff which is an extremely useful tool for figuring out what is going on with any PostScript differences you run into on any platform. just go to cmake/external/ndiff/README.ndiff and follow directions there to test it.) 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 __________________________ |