From: Alan W. I. <ir...@be...> - 2008-06-27 20:36:02
|
The 2.6.0 issues: I have just now (revision 8497) put in a bug fix recommended by Brad King (both for branches/test_cmake/test_ada and trunk) which solves all 2.6.0 issues for a static build of the Ada libraries. However, there are remaining 2.6.0 rpath issues for the build tree that do not occur for 2.4.8. Those issues currently screw up the 2.6.0 ctest of the Ada examples (unless LD_LIBRARY_PATH is set to work around them), but do not affect the install-tree tests of Ada. General Ada issues occurring for both 2.4.8 and 2.6.0: (1) Example 19 generates the following run-time error message: raised STORAGE_ERROR : stack overflow (or erroneous memory access) This is for both the thick and thin 19th examples built on Linux with gnatmake (installed with the Debian testing 4.1.2-8 version of gnat-4.1): Jerry, I hope you also see that STORAGE_ERROR on Mac OS X so that you can debug it locally rather than remotely through me. Because of this error I had to temporarily remove example 19 from plplot_test/test_ada.sh.cmake and examples/ada/Makefile.examples.in. (2) examples 2, 5, 12, 16, and 18 give different results than the corresponding C examples. Perhaps there are enough of these differences now so that Jerry can spot the reason(s) for them. Ultimately, we want no differences between the Ada and C results for the standard examples. General example 21 problem for all front ends: Example 21 also gives different Ada and C results, but this is a general issue with example 21 for all front-ends because of differences in the external random-number generators being used and in their execution times. We need a volunteer to step forward to change example 21 in C so that it uses a simple random number generator that is internal to the example (perhaps something extremely simple but reasonably effective if you pick a "good" seed such as the middle square method described at http://en.wikipedia.org/wiki/Middle-square_method) and also so that execution times are not made part of PLplot labels. Once these changes were propagated to the rest of the front ends, this should hopefully make example 21 results uniform for all front-ends. 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 __________________________ |
From: Werner S. <sm...@ia...> - 2008-06-27 20:56:03
|
Hi Alan, > We need a volunteer to step forward to change example 21 in C so that it > uses a simple random number generator that is internal to the example > (perhaps something extremely simple but reasonably effective if you pick a > "good" seed such as the middle square method described at > http://en.wikipedia.org/wiki/Middle-square_method) and also so that > execution times are not made part of PLplot labels. Once these changes were > propagated to the rest of the front ends, this should hopefully make example > 21 results uniform for all front-ends. Coincidently, I was thinking about a RNG provided by the PLplot library. If nobody uses it except our example 21, no problem, since the code of RNGs is rather short, so no harm done here, and maybe some users find it useful though. A very good one (passed the diehard test), although maybe not good enough for encryption (don't think that will be a problem :), is the Mersenne Twister RNG http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html There is a C implementation available and the code is completely free. We could write a PLplot interface to this RNG, and then make the changes to all bindings. I volunteer to do that (that is the RNG interface, not all changes to the bindings), but only in two weeks, since I'm away for one week now. Regards, Werner > > 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 > __________________________ > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Arjen M. <arj...@wl...> - 2008-06-30 06:42:35
|
Werner Smekal wrote: >Hi Alan, > > > >>We need a volunteer to step forward to change example 21 in C so that it >>uses a simple random number generator that is internal to the example >>(perhaps something extremely simple but reasonably effective if you pick a >>"good" seed such as the middle square method described at >>http://en.wikipedia.org/wiki/Middle-square_method) and also so that >>execution times are not made part of PLplot labels. Once these changes were >>propagated to the rest of the front ends, this should hopefully make example >>21 results uniform for all front-ends. >> >> > >Coincidently, I was thinking about a RNG provided by the PLplot library. > If nobody uses it except our example 21, no problem, since the code of >RNGs is rather short, so no harm done here, and maybe some users find it >useful though. A very good one (passed the diehard test), although maybe >not good enough for encryption (don't think that will be a problem :), >is the Mersenne Twister RNG > >http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html > >There is a C implementation available and the code is completely free. >We could write a PLplot interface to this RNG, and then make the changes >to all bindings. I volunteer to do that (that is the RNG interface, not >all changes to the bindings), but only in two weeks, since I'm away for >one week now. > > I do not want to sound too critical, but do we need the Mersenne twister? It is a very nice thing, but wouldn't a linear congruential one do? We are not looking for the ultimate in PRNGs, are we? :) Here is a PRNG I picked up from Tcl (8.4): /* * Generate the random number using the linear congruential * generator defined by the following recurrence: * seed = ( IA * seed ) mod IM * where IA is 16807 and IM is (2^31) - 1. The recurrence maps * a seed in the range [1, IM - 1] to a new seed in that same range. * The recurrence maps IM to 0, and maps 0 back to 0, so those two * values must not be allowed as initial values of seed. * * In order to avoid potential problems with integer overflow, the * recurrence is implemented in terms of additional constants * IQ and IR such that * IM = IA*IQ + IR * None of the operations in the implementation overflows a 32-bit * signed integer, and the C type long is guaranteed to be at least * 32 bits wide. * * For more details on how this algorithm works, refer to the following * papers: * * S.K. Park & K.W. Miller, "Random number generators: good ones * are hard to find," Comm ACM 31(10):1192-1201, Oct 1988 * * W.H. Press & S.A. Teukolsky, "Portable random number * generators," Computers in Physics 6(5):522-524, Sep/Oct 1992. */ #define RAND_IA 16807 #define RAND_IM 2147483647 #define RAND_IQ 127773 #define RAND_IR 2836 #define RAND_MASK 123459876 tmp = iPtr->randSeed/RAND_IQ; iPtr->randSeed = RAND_IA*(iPtr->randSeed - tmp*RAND_IQ) - RAND_IR*tmp; if (iPtr->randSeed < 0) { iPtr->randSeed += RAND_IM; } (This is under BSD license) Regards, Arjen |
From: Jerry <lan...@qw...> - 2008-06-27 23:35:05
|
On Jun 27, 2008, at 1:35 PM, Alan W. Irwin wrote: > The 2.6.0 issues: > > I have just now (revision 8497) put in a bug fix recommended by > Brad King > (both for branches/test_cmake/test_ada and trunk) which solves all > 2.6.0 > issues for a static build of the Ada libraries. However, there are > remaining 2.6.0 rpath issues for the build tree that do not occur > for 2.4.8. > Those issues currently screw up the 2.6.0 ctest of the Ada examples > (unless > LD_LIBRARY_PATH is set to work around them), but do not affect the > install-tree tests of Ada. > > General Ada issues occurring for both 2.4.8 and 2.6.0: > > (1) Example 19 generates the following run-time error message: > > raised STORAGE_ERROR : stack overflow (or erroneous memory access) > > This is for both the thick and thin 19th examples built on Linux > with gnatmake > (installed with the Debian testing 4.1.2-8 version of gnat-4.1): > > Jerry, I hope you also see that STORAGE_ERROR on Mac OS X so > that you can debug it locally rather than remotely through me. Unfortunately, both of these examples 19 run fine for me--no errors or exceptions are reported and the PS files are generated OK. I'm running GNAT 4.3. Googling the entire error line above gives 13 results, some from bugzilla for Ada. I don't know how to make sense of of the discussions but I wonder if it was a problem for GNAT 4.1 on x86. I'm open to suggestions on what I can try at this end. Jerry > > Because of this error I had to temporarily remove example 19 from > plplot_test/test_ada.sh.cmake and examples/ada/Makefile.examples.in. > > (2) examples 2, 5, 12, 16, and 18 give different results than the > corresponding C examples. Perhaps there are enough of these > differences > now so that Jerry can spot the reason(s) for them. Ultimately, we > want > no differences between the Ada and C results for the standard > examples. I'll look at these examples again--maybe after I finish off 29 and 30. I recall that some things were being drawn in the wrong colors. One of the examples in the teens (16?) was giving a badly distorted contour plot and I temporarily punted on it, so I'll revisit that as well. > > General example 21 problem for all front ends: > > Example 21 also gives different Ada and C results, but this is a > general > issue with example 21 for all front-ends because of differences in the > external random-number generators being used and in their execution > times. > > We need a volunteer to step forward to change example 21 in C so > that it > uses a simple random number generator that is internal to the example > (perhaps something extremely simple but reasonably effective if you > pick a > "good" seed such as the middle square method described at > http://en.wikipedia.org/wiki/Middle-square_method) and also so that > execution times are not made part of PLplot labels. Once these > changes were > propagated to the rest of the front ends, this should hopefully > make example > 21 results uniform for all front-ends. > > Alan > |
From: Alan W. I. <ir...@be...> - 2008-06-28 00:11:31
|
On 2008-06-27 13:35-0700 Alan W. Irwin wrote: > The 2.6.0 issues: > > I have just now (revision 8497) put in a bug fix recommended by Brad King > (both for branches/test_cmake/test_ada and trunk) which solves all 2.6.0 > issues for a static build of the Ada libraries. However, there are > remaining 2.6.0 rpath issues for the build tree that do not occur for 2.4.8. > Those issues currently screw up the 2.6.0 ctest of the Ada examples (unless > LD_LIBRARY_PATH is set to work around them), but do not affect the > install-tree tests of Ada. With some additional help from Brad King I have now fixed this issue so that I can now build, ctest, and install-tree test PLPlot with -DENABLE_ada=ON for either CMake 2.4.8 or 2.6.0 without any 2.6.0-specific problems. The test_ada branch (which has a simple, self-contained project to test CMake Ada support) also works for 2.4.8 and 2.6.0 with the default static Ada library build or with the shared Ada library build that can be configured using the -DBUILD_SHARED_LIBS=ON option. Andrew (Debian) and Orion (Fedora) please go ahead and try Ada for your respective distro packaging efforts again. I think there will be a high probability that it works. The Ada language support has been the only cmake-2.6.0 issue for the PLplot build system that anybody has discovered so far. Since that is now fixed, I hope to bump our minimum version of cmake to 2.6.0 in the not-too-distant future to simplify our build system. Therefore, I urge all developers here to use CMake-2.6.0 from now on to make sure we are not caught by surprise by any other issue when we bump the CMake minimum version. Also, please routinely specify -DENABLE_ada=ON for your builds so that we find Ada build problems sooner rather than later. Jerry has been working hard at implementing a lot of the standard examples in Ada. Once those give the same results as the corresponding C examples (which should lend a lot of confidence to the Ada interface implementation), then we will set -DENABLE_ada=ON by default. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2008-06-28 00:33:32
|
On 2008-06-27 22:56+0200 Werner Smekal wrote: > Hi Alan, > >> We need a volunteer to step forward to change example 21 in C so that it >> uses a simple random number generator that is internal to the example >> (perhaps something extremely simple but reasonably effective if you pick a >> "good" seed such as the middle square method described at >> http://en.wikipedia.org/wiki/Middle-square_method) and also so that >> execution times are not made part of PLplot labels. Once these changes >> were >> propagated to the rest of the front ends, this should hopefully make >> example >> 21 results uniform for all front-ends. > > Coincidently, I was thinking about a RNG provided by the PLplot library. If > nobody uses it except our example 21, no problem, since the code of RNGs is > rather short, so no harm done here, and maybe some users find it useful > though. A very good one (passed the diehard test), although maybe not good > enough for encryption (don't think that will be a problem :), is the Mersenne > Twister RNG > > http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html > > There is a C implementation available and the code is completely free. We > could write a PLplot interface to this RNG, and then make the changes to all > bindings. I volunteer to do that (that is the RNG interface, not all changes > to the bindings), but only in two weeks, since I'm away for one week now. Since it appears you can implement this internally (i.e., no additional external libraries are involved) I encourage you to go ahead two weeks from now. From Wikipedia, the Mersenne Twister RNG is a better choice than the historical but rather flawed middle-square method that I mentioned. Also, your idea of putting a RNG within the PLplot library rather than example 21 is a good one. I have required RNG's for past plotting needs, I am sure many of our users have similar needs. Furthermore, the interactive example 17 could use a library RNG as well as example 21. Finally, it means we only have to implement a binding interface to the C version of the RNG for each of our bindings. That is actually much simpler than implementing the same RNG in many different languages for example 21 (and 17). 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 __________________________ |
From: Arjen M. <arj...@wl...> - 2008-06-30 06:52:28
|
Alan W. Irwin wrote: >Since it appears you can implement this internally (i.e., no additional >external libraries are involved) I encourage you to go ahead two weeks from >now. From Wikipedia, the Mersenne Twister RNG is a better choice than the >historical but rather flawed middle-square method that I mentioned. Also, >your idea of putting a RNG within the PLplot library rather than example 21 >is a good one. I have required RNG's for past plotting needs, I am sure >many of our users have similar needs. Furthermore, the interactive example >17 could use a library RNG as well as example 21. Finally, it means we only >have to implement a binding interface to the C version of the RNG for each >of our bindings. That is actually much simpler than implementing the same >RNG in many different languages for example 21 (and 17). > > Hm, I should read more carefully before posting ;). I understand now that Werner wants to make the Mersenne Twister part of the PLplot library. That does sound useful. I retract my previous mail. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2008-06-28 01:12:05
|
On 2008-06-27 16:35-0700 Jerry wrote: > > On Jun 27, 2008, at 1:35 PM, Alan W. Irwin wrote: > >> The 2.6.0 issues: >> >> I have just now (revision 8497) put in a bug fix recommended by >> Brad King >> (both for branches/test_cmake/test_ada and trunk) which solves all >> 2.6.0 >> issues for a static build of the Ada libraries. However, there are >> remaining 2.6.0 rpath issues for the build tree that do not occur >> for 2.4.8. >> Those issues currently screw up the 2.6.0 ctest of the Ada examples >> (unless >> LD_LIBRARY_PATH is set to work around them), but do not affect the >> install-tree tests of Ada. >> >> General Ada issues occurring for both 2.4.8 and 2.6.0: >> >> (1) Example 19 generates the following run-time error message: >> >> raised STORAGE_ERROR : stack overflow (or erroneous memory access) >> >> This is for both the thick and thin 19th examples built on Linux >> with gnatmake >> (installed with the Debian testing 4.1.2-8 version of gnat-4.1): >> >> Jerry, I hope you also see that STORAGE_ERROR on Mac OS X so >> that you can debug it locally rather than remotely through me. > > Unfortunately, both of these examples 19 run fine for me--no errors > or exceptions are reported and the PS files are generated OK. I'm > running GNAT 4.3. > > Googling the entire error line above gives 13 results, some from > bugzilla for Ada. I don't know how to make sense of of the > discussions but I wonder if it was a problem for GNAT 4.1 on x86. > > I'm open to suggestions on what I can try at this end. I just now looked at google as well, and the above error message does appear to be part of a bug report for gcc/gnat 4.1. So perhaps it has been fixed in 4.3 which is why you don't see it, and there is nothing much more that needs to be done. N.B. I have therefore reenabled example 19 (revision 8501) to see how well it does on systems with gnat-4.3 installed. Andrew, I would appreciate it if you ctested the Ada examples on your Debian unstable system. The gnat promotion from Debian unstable to testing is in a nasty tangle right now (the gnat package is being deliberately held back because of a large number of package update issues) so I am not in a good position to try 4.3 myself on my Debian testing system. Orion, how does the Ada component of ctest work on Fedora (which presumably also has gnat-4.3 or later)? If all Ada examples (including example 19) run without errors for all systems with gnat-4.3, then I think we should just note in our release notes that gnat-4.3 provides more reliable example results than 4.1 and let it go at that. 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 __________________________ |
From: Jim D. <ji...@di...> - 2008-06-30 12:01:55
|
Werner Smekal <sm...@ia...> writes: > Hi Alan, > >> We need a volunteer to step forward to change example 21 in C so that it >> uses a simple random number generator that is internal to the example >> (perhaps something extremely simple but reasonably effective if you pick a >> "good" seed such as the middle square method described at >> http://en.wikipedia.org/wiki/Middle-square_method) and also so that >> execution times are not made part of PLplot labels. Once these changes were >> propagated to the rest of the front ends, this should hopefully make example >> 21 results uniform for all front-ends. > > Coincidently, I was thinking about a RNG provided by the PLplot library. > If nobody uses it except our example 21, no problem, since the code of > RNGs is rather short, so no harm done here, and maybe some users find it > useful though. A very good one (passed the diehard test), although maybe > not good enough for encryption (don't think that will be a problem :), > is the Mersenne Twister RNG > Would it be better to just put a simple PRNG into example 21? PLplot is a plotting library and I think it is better to focus on that. |
From: Werner S. <sm...@ia...> - 2008-07-06 11:54:28
|
Hi Jim, > > Would it be better to just put a simple PRNG into example 21? PLplot is > a plotting library and I think it is better to focus on that. The drawback of this would be, that we would need to port the RNG to all languages we provided, rather than providing just an interface to RNG code in the library, with all the problems (rounding, etc.). Apart from that, for my thesis I produced a lot of the plots with C programs using plplot and needed a RNG from time to time. Providing a cross platform RNG which produces the same results for all languages and platforms (e.g. for reproducibility) is within the scope of a plotting library I think. And as I wrote - it doesn't make the size of the library much bigger, so if it's not used, we don't care. It's a utility function for making plots. And since the Mersenne Twister is a well tested code (e.g. MT is used a lot in Viruses :), I think it's not a bad choice, though there is some criticism. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Jerry <lan...@qw...> - 2008-07-04 10:35:56
|
On Jun 27, 2008, at 1:35 PM, Alan W. Irwin wrote: > The 2.6.0 issues: > > I have just now (revision 8497) put in a bug fix recommended by > Brad King > (both for branches/test_cmake/test_ada and trunk) which solves all > 2.6.0 > issues for a static build of the Ada libraries. However, there are > remaining 2.6.0 rpath issues for the build tree that do not occur > for 2.4.8. > Those issues currently screw up the 2.6.0 ctest of the Ada examples > (unless > LD_LIBRARY_PATH is set to work around them), but do not affect the > install-tree tests of Ada. > > General Ada issues occurring for both 2.4.8 and 2.6.0: > > (1) Example 19 generates the following run-time error message: > > raised STORAGE_ERROR : stack overflow (or erroneous memory access) > > This is for both the thick and thin 19th examples built on Linux > with gnatmake > (installed with the Debian testing 4.1.2-8 version of gnat-4.1): > > Jerry, I hope you also see that STORAGE_ERROR on Mac OS X so > that you can debug it locally rather than remotely through me. > > Because of this error I had to temporarily remove example 19 from > plplot_test/test_ada.sh.cmake and examples/ada/Makefile.examples.in. > > (2) examples 2, 5, 12, 16, and 18 give different results than the > corresponding C examples. Perhaps there are enough of these > differences > now so that Jerry can spot the reason(s) for them. Ultimately, we > want > no differences between the Ada and C results for the standard > examples. Ada example 18 gives the same results on my machine as C 18. How many differences are you seeing? Or what are the visible differences? > > General example 21 problem for all front ends: > > Example 21 also gives different Ada and C results, but this is a > general > issue with example 21 for all front-ends because of differences in the > external random-number generators being used and in their execution > times. > > We need a volunteer to step forward to change example 21 in C so > that it > uses a simple random number generator that is internal to the example > (perhaps something extremely simple but reasonably effective if you > pick a > "good" seed such as the middle square method described at > http://en.wikipedia.org/wiki/Middle-square_method) and also so that > execution times are not made part of PLplot labels. Once these > changes were > propagated to the rest of the front ends, this should hopefully > make example > 21 results uniform for all front-ends. > > Alan > __________________________ |
From: Alan W. I. <ir...@be...> - 2008-07-04 19:46:55
|
On 2008-07-04 03:36-0700 Jerry wrote: > On Jun 27, 2008, at 1:35 PM, Alan W. Irwin wrote: > >> The 2.6.0 issues: >> >> I have just now (revision 8497) put in a bug fix recommended by >> Brad King >> (both for branches/test_cmake/test_ada and trunk) which solves all >> 2.6.0 >> issues for a static build of the Ada libraries. However, there are >> remaining 2.6.0 rpath issues for the build tree that do not occur >> for 2.4.8. >> Those issues currently screw up the 2.6.0 ctest of the Ada examples >> (unless >> LD_LIBRARY_PATH is set to work around them), but do not affect the >> install-tree tests of Ada. Clarification: this part of this old quoted message from me should be ignored since CMake 2.4.8 and 2.6.0 Ada language support is fine now on the Debian testing platform accessible to me. However, please use CMake-2.6.0 specifically for Ada from now on to be sure that there are no CMake-2.6.0/Ada language support issues on any platform. (Also, you should be using CMake-2.6.0 in general since we don't want any surprises when we officially switch to it.) >> >> General Ada issues occurring for both 2.4.8 and 2.6.0: >> >> (1) Example 19 generates the following run-time error message: >> >> raised STORAGE_ERROR : stack overflow (or erroneous memory access) >> >> This is for both the thick and thin 19th examples built on Linux >> with gnatmake >> (installed with the Debian testing 4.1.2-8 version of gnat-4.1): >> >> Jerry, I hope you also see that STORAGE_ERROR on Mac OS X so >> that you can debug it locally rather than remotely through me. >> >> Because of this error I had to temporarily remove example 19 from >> plplot_test/test_ada.sh.cmake and examples/ada/Makefile.examples.in. I just checked that this example 19 issue is still open for the gnat-4.1 that is accessible to me debian testing. In order to figure out what to dow We need gnat-4.3 Linux testing from those (Debian unstable, Fedora?) who have access to gnat-4.3 on Linux. >> >> (2) examples 2, 5, 12, 16, and 18 give different results than the >> corresponding C examples. Perhaps there are enough of these >> differences >> now so that Jerry can spot the reason(s) for them. Ultimately, we >> want >> no differences between the Ada and C results for the standard >> examples. > > Ada example 18 gives the same results on my machine as C 18. How many > differences are you seeing? Or what are the visible differences? Here is the report for my Debian testing platform since your recent fixes. example 2 and 18 are now fine. The remaining differences are in examples 5, 12, 16, and 29. Here are the details. Example 5 still shows a colour problem. Example 12 replaces the correct solid fill with a fill that uses horizontal lines. For the last page for example 16 the 4th quadrant of the polar plot is badly messed up. Example 29 has the X axis labelling inconsistency on the 3rd page. Jerry, you have already mentioned the example 29 problem that I confirm on my Linux system. Do you confirm the other three issues as I have described them? I wish you quick success with these remaining issues and also the implementation of examples 14 and 17 to complete the standard examples. Examples 14 and 17 are not used by ctest or the static install-tree tests, but they do supply useful additional interactive install-tree tests of the Ada interface to PLplot and also test unique parts of the API for the Ada interface to PLplot. You run them by running, e.g., ada/x14a in the install tree examples and comparing with the corresponding run of c/x14c. And similarly for the 17th example. 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 __________________________ |
From: Jerry <lan...@qw...> - 2008-07-04 21:31:32
|
On Jul 4, 2008, at 12:47 PM, Alan W. Irwin wrote: > On 2008-07-04 03:36-0700 Jerry wrote: > >> On Jun 27, 2008, at 1:35 PM, Alan W. Irwin wrote: >> >>> The 2.6.0 issues: >>> >>> I have just now (revision 8497) put in a bug fix recommended by >>> Brad King >>> (both for branches/test_cmake/test_ada and trunk) which solves all >>> 2.6.0 >>> issues for a static build of the Ada libraries. However, there are >>> remaining 2.6.0 rpath issues for the build tree that do not occur >>> for 2.4.8. >>> Those issues currently screw up the 2.6.0 ctest of the Ada examples >>> (unless >>> LD_LIBRARY_PATH is set to work around them), but do not affect the >>> install-tree tests of Ada. > > Clarification: this part of this old quoted message from me should be > ignored since CMake 2.4.8 and 2.6.0 Ada language support is fine > now on > the Debian testing platform accessible to me. However, please use > CMake-2.6.0 specifically for Ada from now on to be sure that there > are no > CMake-2.6.0/Ada language support issues on any platform. (Also, > you should > be using CMake-2.6.0 in general since we don't want any surprises > when we > officially switch to it.) > >>> >>> General Ada issues occurring for both 2.4.8 and 2.6.0: >>> >>> (1) Example 19 generates the following run-time error message: >>> >>> raised STORAGE_ERROR : stack overflow (or erroneous memory access) >>> >>> This is for both the thick and thin 19th examples built on Linux >>> with gnatmake >>> (installed with the Debian testing 4.1.2-8 version of gnat-4.1): >>> >>> Jerry, I hope you also see that STORAGE_ERROR on Mac OS X so >>> that you can debug it locally rather than remotely through me. >>> >>> Because of this error I had to temporarily remove example 19 from >>> plplot_test/test_ada.sh.cmake and examples/ada/Makefile.examples.in. > > I just checked that this example 19 issue is still open for the > gnat-4.1 > that is accessible to me debian testing. In order to figure out > what to dow > We need gnat-4.3 Linux testing from those (Debian unstable, > Fedora?) who > have access to gnat-4.3 on Linux. > >>> >>> (2) examples 2, 5, 12, 16, and 18 give different results than the >>> corresponding C examples. Perhaps there are enough of these >>> differences >>> now so that Jerry can spot the reason(s) for them. Ultimately, we >>> want >>> no differences between the Ada and C results for the standard >>> examples. >> >> Ada example 18 gives the same results on my machine as C 18. How many >> differences are you seeing? Or what are the visible differences? > > Here is the report for my Debian testing platform since your recent > fixes. > > example 2 and 18 are now fine. The remaining differences are in > examples 5, > 12, 16, and 29. Here are the details. Example 5 still shows a colour > problem. Example 12 replaces the correct solid fill with a fill > that uses > horizontal lines. For the last page for example 16 the 4th quadrant > of the > polar plot is badly messed up. Example 29 has the X axis labelling > inconsistency on the 3rd page. > > Jerry, you have already mentioned the example 29 problem that I > confirm on > my Linux system. Do you confirm the other three issues as I have > described > them? Yes. I'm pretty sure that there was another color problem as in Example 5 a while back. Either I'm remembering wrong or it disappeared. > > I wish you quick success with these remaining issues Thanks. The reason they remain is that I couldn't crack them before. > and also the > implementation of examples 14 and 17 to complete the standard > examples. > Examples 14 and 17 are not used by ctest or the static install-tree > tests, > but they do supply useful additional interactive install-tree tests > of the > Ada interface to PLplot and also test unique parts of the API for > the Ada > interface to PLplot. You run them by running, e.g., > > ada/x14a > > in the install tree examples and comparing with the corresponding run > of > > c/x14c. And similarly for the 17th example. > > Alan > |
From: Werner S. <sm...@ia...> - 2008-07-06 11:55:47
|
Hi Alan, > Since it appears you can implement this internally (i.e., no additional > external libraries are involved) I encourage you to go ahead two weeks from > now. From Wikipedia, the Mersenne Twister RNG is a better choice than the > historical but rather flawed middle-square method that I mentioned. Also, > your idea of putting a RNG within the PLplot library rather than example 21 > is a good one. I have required RNG's for past plotting needs, I am sure > many of our users have similar needs. Furthermore, the interactive example > 17 could use a library RNG as well as example 21. Finally, it means we only > have to implement a binding interface to the C version of the RNG for each > of our bindings. That is actually much simpler than implementing the same > RNG in many different languages for example 21 (and 17). Ok, so I'll go ahead implementing the code. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Werner S. <sm...@ia...> - 2008-07-07 09:31:13
|
Hi, I included the code of Mersenne Twister (http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html, the header and RNG code from the mt19937ar.sep.tgz package) in the src directory without any changes. I wrote an interface to this RNG: void plseed(unsigned int s); unsigned long plrandi(void); PLFLT plrandd(void); With plseed you can initialize the RNG with an integer (there is no need to), plrandi returns an integer and plrandd returns a double/float in the [0,1] interval. Any comments to the names of the functions and the interface itself are welcome. The interface is quite general (e.g. no initialization with an array), so it's easy to replace Mersenne Twister if needed. I also implemented the c++ bindings and made corresponding changes to example 21. I tested these changes on Windows XP with Visual C++ 2008. I will test it on Ubuntu soon - but as usual there might be problems. Best Regards, Werner Werner Smekal wrote: > Hi Alan, > >> Since it appears you can implement this internally (i.e., no additional >> external libraries are involved) I encourage you to go ahead two weeks from >> now. From Wikipedia, the Mersenne Twister RNG is a better choice than the >> historical but rather flawed middle-square method that I mentioned. Also, >> your idea of putting a RNG within the PLplot library rather than example 21 >> is a good one. I have required RNG's for past plotting needs, I am sure >> many of our users have similar needs. Furthermore, the interactive example >> 17 could use a library RNG as well as example 21. Finally, it means we only >> have to implement a binding interface to the C version of the RNG for each >> of our bindings. That is actually much simpler than implementing the same >> RNG in many different languages for example 21 (and 17). > > Ok, so I'll go ahead implementing the code. > > Regards, > Werner > -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Orion P. <or...@co...> - 2008-07-16 23:55:22
|
Alan W. Irwin wrote: > > Orion, how does the Ada component of ctest work on Fedora (which presumably > also has gnat-4.3 or later)? Testing latest svn with Fedora rawhide with gnat 4.3.1. Compiles fine but ada test x21a has now consumed more than 8 minutes of CPU time and appears hung. I'll check back in the morning... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: <or...@co...> - 2008-07-17 02:26:41
|
> Alan W. Irwin wrote: >> >> Orion, how does the Ada component of ctest work on Fedora (which >> presumably >> also has gnat-4.3 or later)? > > Testing latest svn with Fedora rawhide with gnat 4.3.1. Compiles fine > but ada test x21a has now consumed more than 8 minutes of CPU time and > appears hung. I'll check back in the morning... > Yeah, it eventually timed out: The following tests FAILED: 9 - examples_perl (Failed) 10 - examples_ada (Timeout) Errors while running CTest I'm also still having problems with perl 5.10.... - Orion > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA Division FAX: 303-415-9702 > 3380 Mitchell Lane or...@co... > Boulder, CO 80301 http://www.cora.nwra.com > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2008-07-18 18:17:07
|
On 2008-07-16 17:55-0600 Orion Poplawski wrote: > Alan W. Irwin wrote: >> >> Orion, how does the Ada component of ctest work on Fedora (which >> presumably >> also has gnat-4.3 or later)? > > Testing latest svn with Fedora rawhide with gnat 4.3.1. Compiles fine but > ada test x21a has now consumed more than 8 minutes of CPU time and appears > hung. I'll check back in the morning... I guess not all gnat-4.3 packages are the same because I get results that are different from both Orion's results and Jerry's! It turns out I do have access to gnat-4.3 for Debian testing so I installed that, and x21a runs without problems for me contrary to Orion's result but in agreement with Jerry's result. However, when I look at the second and third pages, the Ada results for the first three of the 6 plots on each page are garbage. (Those plots should agree fairly closely with the last 3 plots on each of those pages.) Jerry, do you confirm those garbage plots for example 21 on your platform? If so, then my guess is when you fix this issue, Orion's issue will also go away. Note, the garbage results for Ada are a separate issue from the reformatting of these Ada plots that should be done in any case to conform to the new C template results for example 21. The other difference I have with both Orion and Jerry for gnat-4.3 is that example 19 (both thick and thin) gives me the following error. raised STORAGE_ERROR : stack overflow (or erroneous memory access) I also saw this same error for my previous gnat-4.1 platform. Andrew, do you see this issue on the various gnat platforms accessible to you or am I the only one seeing it? For those who sail through example 19 without this error, do your Ada results agree exactly with the corresponding C results? 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 __________________________ |
From: Jerry <lan...@qw...> - 2008-07-21 00:46:34
|
On Jul 18, 2008, at 11:17 AM, Alan W. Irwin wrote: > On 2008-07-16 17:55-0600 Orion Poplawski wrote: > >> Alan W. Irwin wrote: >>> Orion, how does the Ada component of ctest work on Fedora (which >>> presumably >>> also has gnat-4.3 or later)? >> >> Testing latest svn with Fedora rawhide with gnat 4.3.1. Compiles >> fine but ada test x21a has now consumed more than 8 minutes of CPU >> time and appears hung. I'll check back in the morning... > > I guess not all gnat-4.3 packages are the same because I get > results that > are different from both Orion's results and Jerry's! > > It turns out I do have access to gnat-4.3 for Debian testing so I > installed > that, and x21a runs without problems for me contrary to Orion's > result but > in agreement with Jerry's result. However, when I look at the > second and > third pages, the Ada results for the first three of the 6 plots on > each page > are garbage. (Those plots should agree fairly closely with the > last 3 plots > on each of those pages.) > > Jerry, do you confirm those garbage plots for example 21 on your > platform? > If so, then my guess is when you fix this issue, Orion's issue will > also go > away. Note, the garbage results for Ada are a separate issue from the > reformatting of these Ada plots that should be done in any case to > conform > to the new C template results for example 21. Yes, I get garbage for the same plots as you--looks like some sort of indexing problem around the periphery of the data arrays. I apologize for submitting this in this state. I don't have any idea what might be Orion's problem with the long CPU times. > > The other difference I have with both Orion and Jerry for gnat-4.3 is > that example 19 (both thick and thin) gives me the following error. > > raised STORAGE_ERROR : stack overflow (or erroneous memory access) > > I also saw this same error for my previous gnat-4.1 platform. > > Andrew, do you see this issue on the various gnat platforms > accessible to > you or am I the only one seeing it? > > For those who sail through example 19 without this error, do your > Ada results > agree exactly with the corresponding C results? For me, x19a runs without reporting any errors and makes the same Postscript as x19c. Jerry > > Alan > > |