On Friday, 23 September 2022 at 10:37:01 UTC-7 axio...@yahoo.de wrote: > OK, this is off topic, but: shouldn't it be this convention? At least: > shouldn't there be some convention? Maybe it would be good to discuss this > in a separate thread. Thus, I repeat the question: > > Is there, or should there be a convention about x._bool_ returning False > only when x is provably False? > > No, quite the opposite. Certainly in SR, equalities that can't be proven correct (for "proof" used in the loose sense of what the various symbolic engines are willing to confirm), will return "False" when converted to "bool" value. The key is: _bool_ cannot really error out (that would break too much in python) and does not allow for "unknown" outcomes, so some choice must be made.
(I don't object to keeping prod as it is, I was only curious, and I suspect > that there are further places in the codebase where it matters.) > If you're in a situation where generating the list of elements is expensive, so terminating on encountering a 0, you could do that yourself. Once you've constructed the list of elements without a 0, you can pass it to "prod". If you're doing this on objects that are prone to coefficient swell, the balanced product is worth it and the result will need about the same number of bits as the factors, so there is no significant memory benefit to not storing all the factors. It would be perfectly possible to build a stream-based balanced product that only needs to store log(n) intermediate products. Whether that should terminate on encountering a 0 depends on whether the representation of 0 could be affected by mults (as it does for p-adics and series). I suspect that "prod" being built this way is because Python 2 was much more list-based that iterator-based. In Python 3 it would make sense to rewrite it iterator-based. For products where these is a heuristic "size" you could of course do better than just balancing on factors: you could combine pairs of minimal height for your multiplications. In an iterator-based version, you'd probably want to do that while adding fresh pairs of factors to the mix while they are available. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/2be2924b-26c8-4d60-9f47-88183058952an%40googlegroups.com.
