As you can see, tinderbox is not very happy today
http://www.cs.unipr.it/~tinderbox/all_trees.panel.html
(BTW: this is the link any developer should monitor on a regular basis).
The reasons for the failures are:
1) on cluster64 everything fails becase the changes Enea made yesterday triggered a bug in GCC 3.3.3:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13635
After proper consisderation, I decided that the only reasonable fix was to ask the cluster64's admin to upgrade GCC;
2) on crystal, XSB Prolog dies because of a segmentation fault; I will look at it now;
3) on thunder, we stumble on the GCC (4.0.1) bug I reported to this list a few days ago; I will install GCC 4.0.2 there as soon as it will be available;
4) the matasciidumpload1 test fails for some choices of the Coefficient type.
Bugs, bugs... bugs everywhere... Ciao,
Roberto
Roberto Bagnara bagnara@cs.unipr.it writes:
As you can see, tinderbox is not very happy today
http://www.cs.unipr.it/~tinderbox/all_trees.panel.html(BTW: this is the link any developer should monitor on a regular basis).
The reasons for the failures are:
on cluster64 everything fails becase the changes Enea made yesterday triggered a bug in GCC 3.3.3:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13635
After proper consisderation, I decided that the only reasonable fix was to ask the cluster64's admin to upgrade GCC;
on crystal, XSB Prolog dies because of a segmentation fault; I will look at it now;
on thunder, we stumble on the GCC (4.0.1) bug I reported to this list a few days ago; I will install GCC 4.0.2 there as soon as it will be available;
the matasciidumpload1 test fails for some choices of the Coefficient type.
This is just from the size of random numbers being generated in the test. I'm on it.
Bugs, bugs... bugs everywhere... Ciao,
Roberto-- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it _______________________________________________ PPL-devel mailing list PPL-devel@cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/ppl-devel
- the matasciidumpload1 test fails for some choices of the Coefficient type.
This is just from the size of random numbers being generated in the test. I'm on it.
For this test I'd like to generate a positive random number within the bounds of the coefficient type. This requires the size of the coefficient type. Is there an existing way to this size?
I've thought of defining a directive in configure.ac, say COEFFICIENT_RAW_TYPE, and then calculating the random number as follows.
#if defined(NATIVE_INTEGERS) || defined(CHECKED_INTEGERS) tem = rand() % std::numeric_limits<COEFFICIENT_RAW_TYPE>::max(); #else tem = rand(); #endif
Is there a better way to do this?
Matthew Mundell wrote:
- the matasciidumpload1 test fails for some choices of the Coefficient type.
This is just from the size of random numbers being generated in the test. I'm on it.
For this test I'd like to generate a positive random number within the bounds of the coefficient type. This requires the size of the coefficient type. Is there an existing way to this size?
I've thought of defining a directive in configure.ac, say COEFFICIENT_RAW_TYPE, and then calculating the random number as follows.
#if defined(NATIVE_INTEGERS) || defined(CHECKED_INTEGERS) tem = rand() % std::numeric_limits<COEFFICIENT_RAW_TYPE>::max(); #else tem = rand(); #endifIs there a better way to do this?
I don't think this is the right way to do it. Why do you need to modify configure.ac? We should have the specializations of std::numeric_limits also for checked numbers (I am sure I raised this point with Abramo in the past). If we don't have them, we should add them.
Abramo? Are they done? If not, do you prefer to add them or to give some pointers to Matthew about how/where to add them? Ciao,
Roberto
Roberto Bagnara ha scritto:
I don't think this is the right way to do it. Why do you need to modify configure.ac? We should have the specializations of std::numeric_limits also for checked numbers (I am sure I raised this point with Abramo in the past). If we don't have them, we should add them.
Abramo? Are they done? If not, do you prefer to add them or to give some pointers to Matthew about how/where to add them?
As far as I remember (and I've supported my memory reading checked_numeric_limits.hh) it's already implemented.
The funny part is that I'm almost sure Roberto added it (with a little help from myself).
We definitely must remove some work from your shoulder, "all work and no play makes Jack..." :-D
That apart the use of rand(3) to generate random coefficients is suboptimal. The range is limited from 0 to RAND_MAX (2147483647 on ia32).
Abramo Bagnara wrote:
The funny part is that I'm almost sure Roberto added it (with a little help from myself).
We definitely must remove some work from your shoulder, "all work and no play makes Jack..." :-D
Precisely :-)
That apart the use of rand(3) to generate random coefficients is suboptimal. The range is limited from 0 to RAND_MAX (2147483647 on ia32).
GMP supports the generation of arbitrary-size pseudo-random numbers. I would use those. Ciao,
Roberto
That apart the use of rand(3) to generate random coefficients is suboptimal. The range is limited from 0 to RAND_MAX (2147483647 on ia32).
GMP supports the generation of arbitrary-size pseudo-random numbers.
Yes. I just need a few numbers to create a test Matrix though.
Abramo Bagnara abramobagnara@tin.it writes:
Roberto Bagnara ha scritto:
I don't think this is the right way to do it. Why do you need to modify configure.ac? We should have the specializations of std::numeric_limits also for checked numbers (I am sure I raised this point with Abramo in the past). If we don't have them, we should add them.
Abramo? Are they done? If not, do you prefer to add them or to give some pointers to Matthew about how/where to add them?
As far as I remember (and I've supported my memory reading checked_numeric_limits.hh) it's already implemented.
Oh right, I should have tried it first. Thanks.
Roberto Bagnara wrote:
I don't think this is the right way to do it. Why do you need to modify configure.ac? We should have the specializations of std::numeric_limits also for checked numbers (I am sure I raised this point with Abramo in the past). If we don't have them, we should add them.
Abramo? Are they done? If not, do you prefer to add them or to give some pointers to Matthew about how/where to add them?
Ehm, Abramo reminds me that _I_ did add the specializations of std::numeric_limits a few months ago. Perhaps I need a break? :-) Ciao,
Roberto
participants (3)
-
Abramo Bagnara -
Matthew Mundell -
Roberto Bagnara