On Wed, Jun 19, 2013 at 03:02:27PM -0700, kcrisman wrote: > Having read this (and the tickets), I guess I have three questions. > > 1) Does this really slow things down in any significant way, or could a > universal implementation of it in many objects do so? (Where significant > might have different tolerances for different people.)
First of all, before ranting about speed someone should measure the slow down. If I remember correctly, we already did it once with Christian and the slow down was less than 10% which is in my opinion perfectly acceptable. If an error was made, it is that we didn't keep any trace of that experiment. If there is a significant slow down, I'm pretty sure that the functionality can be achieved with close to zero and maybe even zero slow down. The combinatorial map decorator create a new class only for adding a few attribute to a function. On can directly add attribute to a function without creating a new class. There is *ZERO* slow down while calling the function, and a decorator is certainly the good way to do it: sage: def add_bla(f): ....: f.is_combinatorial_bla = True ....: return f sage: @add_bla ....: def toto(x): ....: return x+1 sage: toto.is_combinatorial_bla True sage: toto(x) x + 1 sage: def tata(x): ....: return x+1 sage: %timeit toto(x) 100000 loops, best of 3: 17.4 us per loop sage: %timeit tata(x) 100000 loops, best of 3: 17.5 us per loop And even if this trick doesn't solve the problem, Cythonizing properly the decorator should reduce the slow down in a vast amount. > 2) Does the change to making certain things be CombinatorialMap class > substantially (negatively) change Sage functionality (including available > methods, introspection and tab-completion)? It certainly will change Sage positively completely independently from find_stat. We definitely need to tag combinatorial maps to know for example whether they are injective surjective of bijective.. > 3) Would it make more sense for this to be a patch applied to Sage by the > FindStat folks? It doesn't seem like it would exactly be a really hard > one, nor one that would need frequent rebasing. See my previous remark ! Florent -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.