`floor(log(n,2))` ECL says: #<a FLOATING-POINT-OVERFLOW 0x7fac3d512600>

[Georgi Guninski]

```
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.

[Nils Bruin]

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.

[Georgi Guninski]

floor(log(n,2))
```
ECL says: #<a FLOATING-POINT-OVERFLOW 0x7fac3d5c4700>

This bug appears to be very rare and it passed many testcases.
It is not a large number issue:

sage: floor(log(3*n+1,2))
3073
sage: floor(log(3*n+2,2))
3073

Is someone is interested in the context, check:

On factoring integers of the form $n=(x^D+1)(y^D+1)$ and
$n=(x^D+a_{D-2}x^{D-2}++ ... a_0) (y^D+b_{D-2}y^{D-2}+ ... b_0)$ with
$x,y$ of the same size

https://www.researchgate.net/publication/395877507_On_factoring_integers_of_the_form_n_x_D_1y_D_1_and_n_x_D_a_D-2_x_D-2_a_0_y_D_b_D-2_y_D-2_b_0_with_x_y_of_the_same_size

[Georgi Guninski]

```
sage: for i1 in range(1,10^3):
....: n3=randint(n,2*n)
....: try: r=floor(log(n3,2))
....: except:
....: cou += 1
....: print(f"exc at {i1}")
```
no exception

[Nils Bruin]

On Thursday, 16 October 2025 at 09:38:30 UTC-7 Georgi Guninski wrote:

This bug appears to be very rare and it passed many testcases.
It is not a large number issue: 

I suspect the error does arise from a large number issue, but apparently maxima doesn't always bump into it, The number n does not fit in a system float:

sage: float(n)
inf

The mpfr implementation of floats allows for larger exponents so there it's fine:

sage: RR(n)
5.80960599536996e924

and then the log isn't so large, so there are plenty bits to get the floor correct:

sage: RR(n).log()/log(2.0)
3072.00000000000

which is still a bit of a silly way of computing the 2-log. gmp  has better tools:

sage: n.nbits()

3073

I think at this point the place to report the specific problem is to maxima. Perhaps they can find a subtle issue on their end that can solve this. For sage, the thing to look at is how sage computes floors of symbolic expressions that happen to represent a number.

[Georgi Guninski]

> which is still a bit of a silly way of computing the 2-log

I find this response to reproducible bug impolite, hope it is not an
official sage reply.
I am investing time to give and minimize and analyze bug reports. If
you check the thread, you will see that this issue is not only big
number problem.

[Nils Bruin]

On Friday, 17 October 2025 at 01:31:06 UTC-7 Georgi Guninski wrote:

> which is still a bit of a silly way of computing the 2-log

I find this response to reproducible bug impolite,

I am sorry if it came across like that. It was meant to report exclusively to the computer code doing the work. Not to the programmer who implemented the routine and also not to the user who uses it. This use is common among people who work with algorithms a lot and who understand that a computer can happen to do something "in a silly way" by a combination of perfectly capable programmers and users who end up using code in unforeseen ways. I did not foresee the phrase would not be interpreted that way and I apologize for that.