> You are not fair. You changed the specification of the function from > returning rationals to floats. And then, I complained that rationals are > exact and the function was not taking care of error propagation when doing > floating point operations.
O_o It's hardly the place to debate this, but the only reason I implemented the rational version is because you requested it. I did not do it when I first wrote the patch, nor did I care for rational results. > Sometimes you claim that truthness is more > important (remember the def hash: return 0) and sometimes you claim that > speed is better (as here). O_o Computing on floats does not mean that the result is wrong. As a matter of fact, I implemented this function because it appeared in benchmarks between different graph theory libraries: we are the *ONLY ONES* to support rationals. Nobody else cares. These algorithms are meant to run on graphs with thousands of vertices: they just don't run over rationals. > That being said, any function of the form > > cpdef long f(): > cdef long res > .. operations .. > return res > > will return an int in Python because this is how Cython works. Similarly > with C double and Python float. We do not want to change that. We do not want to change Cython's behaviour indeed but if I make no mistake people want Sage functions to return Integers and not 'int'. So we will have to wrap this 'return res' with 'return Integer(res)'. Or else I haven't understood when exactly we are supposed to return Integer objects. 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.
