Maybe I'm missing something here, but aren't these test also badly stated? This would be a good example why some tolerance should be included if one test something with floating points: Every small change in some flop somewhere in the code will lead to a fail. I personally wouldn't call something "strange numerical error", where some floating point operation differs from the expected output by a difference below machine epsilon.
If this is the only problem with the different pari version, it would be better to restate the unit test. Regards, Stefan On Wednesday, February 18, 2015 at 1:53:58 PM UTC+1, Snark wrote: > > Hi, > > I'm having strange numerical behaviour with my experimental sage using > debian packages, with two failing doctests in the src/sage/libs/pari/ > directory (both in gen.pyx) : > > Failed example: > (s*z)^5 > Expected: > 2.00000000000000 - 1.08420217248550 E-19*I > Got: > 2.00000000000000 + 0.E-19*I > > Failed example: > e.ellztopoint(1+i) > Expected: > [0.E-19 - 1.02152286795670*I, -0.149072813701096 - > 0.149072813701096*I] > Got: > [0.E-18 - 1.02152286795670*I, -0.149072813701096 - > 0.149072813701096*I] > > > For the first one, the "Got:" is the one expected on a 32-bit box! And > from all the tests in the directory where there is a differing > 32-bit/64-bit expectation, it's the only failing. > > For the second one... I really don't know... > > Does it look familiar? > > Snark on #sagemath > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
