> Generalizing code for the sake of generalization and at the expense of > efficiency is probably a bad choice, especially for something so > pervasive as the category framework, but if you can show that the more > general code is necessary to do things people actually want, it > becomes worth evaluating what the slowdowns are and if one can avoid > the slowdowns, or even accept them if they are unavoidable. Agreed. Otherwise, it will never stop - there are always more generalisations which could be done in mathematics. Otherwise, your additions sound very compelling and nice mathematically :-)
> The 1.5% you are giving is a nice guide, but it doesn't really show > that there is a slow-down, nor how badly this is going to affect > existing code. Could you try to identify which things are slowed down? > All operations? just certain coercions? Perhaps look at the timing of > separate modules and see which contribute most to that 1.5%. Even more importantly: try removing your new doctests to show the slowdown on only the original doctests; otherwise, the number 1,5% doesn't reveal much (your new tests might just be very slow compared to the average doctest out there). Cheers, Johan -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
