> What functions return for example python double? The MixedIntegerLinearProgram code, for instance. And probably many others. Either way, if you want to prevent functions from returning 'int', I don't get why you would allow float/double. That would be very surprising.
> For example > centrality_degree on graphs return Sage rational, not machine float. Not only. I was forced to implement a Rational version of that because the reviewer would not accept a function that returns float. But the Rational version is mostly useless, given that it is way way way slower than the other one (and that I wrote that only to be faster than other libraries on some benchmarks) > To be honest, I don't know when the user would P.height()/Q.height() with P > and Q posets; but isn't it odd to have type(P.height()) != type(P.width())? Given that you will not be able to make len(something) return anything else than a Python int, that you have no power over numpy nor the many third-party packages that we include, this current attempt to set crazy laws that Sage (as a whole) cannot obey is (to me) a disaster. What I don't want to see is a half-standard that is a bore when we write code but offers us absolutely no advantage. Let us at least make this "somehow consistent" by not distinguishing the numerical types that we like and the ones that we do not like. Nathann -- 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/d/optout.
