You can use: n.log(2).n()
instead. It still returns a float (what else if you want to take a floor of it?) but there shouldn't be an issue with the numerical accuracy. It is indeed the case that floor is risky on floats if you end up outside of the range where the +-1 makes a difference, but for logs this is unlikely to happen (and you could just ask for more digits with the code above. Or you could use interval or ball arithmetic to detect if a problem occurs. The error shows that floor(log(n,2)) is punting to maxima [leading to ECL] and apparently there it's asking for n to be represented as a system float before taking the log. That is indeed silly. It seems to be how "floor" is implemented. That's something you could work on and which would probably get merged if it can show significant improvement. On Thursday, 16 October 2025 at 08:53:17 UTC-7 Georgi Guninski wrote: > ``` > x0=next_prime(2^128);y0=next_prime(2^256);n=(x0^8+1)*(y0^8+1) > floor(log(n,2)) > ``` > ECL says: #<a FLOATING-POINT-OVERFLOW 0x7fac3d5c4700> > > I can live with maxima exception, but IMHO using floating points in > symbolic expressions sucks much. FP are super unreliable. > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/ac37d3f3-02f0-45d7-973b-7a9d8337573en%40googlegroups.com.
