The reason that I required the quotient as well in the divisibility benchmark was that Magma does the n = 20 dense case in 0.15s otherwise, and I don't believe it is possible to do it that fast if you aren't doing it heuristically, as I explained in the blog post. Therefore, all the systems timed must return the quotient if the division is exact (which it is in the benchmark examples, since that is the hard case), so that Magma can't possibly "cheat".
As mentioned, if the various systems don't provide such a function, I substituted divrem, since it is possible to look at the remainder to see if it was divisible, and then take the quotient as required by the benchmark. It is really hard to benchmark a bunch of systems against one another. When I first timed Giac, I wasn't aware of a bunch of special parameters you can pass to the Giac functions which make them run much faster. And basically, there aren't many functions that all the systems happen to implement with the same semantics, so I have to simulate what a user would do if that is the semantics they want. I didn't do it to make Sage look bad, honest! On Monday, 10 July 2017 12:05:28 UTC+2, Bill Hart wrote: > > 7.6 > > On Monday, 10 July 2017 11:56:32 UTC+2, vdelecroix wrote: >> >> On 10/07/2017 09:34, Ralf Stephan wrote: >> > On Monday, July 10, 2017 at 8:55:23 AM UTC+2, vdelecroix wrote: >> >> >> >> He was certainly not using the awfully slow symbolic ring >> >> >> > >> > Then his slow timings for e.g. "Divisibility test with quotient >> (sparse)" >> > needs a different explanation. >> >> Sage version? >> >> -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
