On 14 March 2011 13:04, David Kirkby <david.kir...@onetel.net> wrote: > On 13 March 2011 15:34, Julien PUYDT <julien.pu...@laposte.net> wrote: >> Hi, >> >> among the few failing tests with my ARM built, two are because of accuracy >> reasons : >> >> File "/home/jpuydt/sage-4.6.2/devel/sage/sage/functions/other.py", line 497: >> sage: gamma1(float(6)) >> Expected: >> 120.0 >> Got: >> 119.99999999999997 > > This is a bit of a pain, as the number you get is less than expected. > I don't believe there's anything magic about using the number 6 - > virtually any positive integer would work. I'd try to find one such > the number is either exact, or *above* the nearest integer. Gamma(n) > should be factorial (n-1) - at least for positive integers. (See the > next example for how to fix it if you get one where the result is just > over an integer value). > >> File "/home/jpuydt/sage-4.6.2/devel/sage/sage/symbolic/expression.pyx", line >> 6067: >> sage: SR(10.0r).gamma() >> Expected: >> 362880.0 >> Got: >> 362880.00000000047 > > That's easy to change. If the test was changed to look for 362880.000000000... > then it would pass since it will ignore the "47". The "..." means to > ignore anything beyond there.
Actually I'm wrong here, as "362880.000000000..." would fail if the result was 362880.0, as it would expect to string of zeros, which are not present. Changing the test to "362880.0..." would work, but I'm not sure that is such a good idea, as it would allow a very high relative error. (362880.099999999 would pass). Perhaps you can find value of n, such that gamma(n) gives an exact integer result. If that happens on other CPUs too, then I suggest the argument to the doctest is changed. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
