On Thu, Jun 2, 2016 at 1:33 PM, Volker Braun <vbraun.n...@gmail.com> wrote: > I'm guessing that this won't fly with upstream ;-) > > Is it really faster? A new __unary_div__ method everywhere? Is it really > faster than special-casing the 1/x case in __div__?
According to my unscientific benchmark just now there seems to be no significant difference for Sage integers; after all, 1/x is still just constructing an element of QQ, which is going to be slow: ~$ sage-develop ┌────────────────────────────────────────────────────────────────────┐ │ SageMath version 7.3.beta2, Release Date: 2016-05-28 │ │ Type "notebook()" for the browser-based notebook interface. │ │ Type "help()" for help. │ └─────────────────────────────────────────────── sage: %timeit 1/10 The slowest run took 39.54 times longer than the fastest. This could mean that an intermediate result is being cached. 100000 loops, best of 3: 1.09 µs per loop sage: %timeit ~10 The slowest run took 25.02 times longer than the fastest. This could mean that an intermediate result is being cached. 1000000 loops, best of 3: 1.04 µs per loop sage: a=1;b=10 sage: %timeit a/b The slowest run took 20.79 times longer than the fastest. This could mean that an intermediate result is being cached. 1000000 loops, best of 3: 1.07 µs per loop sage: %timeit ~b The slowest run took 21.31 times longer than the fastest. This could mean that an intermediate result is being cached. 1000000 loops, best of 3: 1.03 µs per loop -- 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.
