Bug? Different function results with same int input value.

[c-max]

Hello,

while testing some Micro Python (v1.20 & v1.23) code on an ESP32-D0WD-V3 (revision v3.1) integers with the same value led to different function results/behavior:

Code:

import os,time

a = sum(2**i for i in range(30))
b = sum(2**i for i in range(30)) +1 -1
c = (2**30)-1
t = (a,b,c)

print(os.uname())    

print('\nAll types and values are the same:\n')

for e1 in t:
    print(type(e1),[(e1==e2,e1-e2) for e2 in t])

print("\nAll second values should be constant -1 in my case.") 
print(  "None of the third values should have a leading comma:\n")

for e in t:
    print(f'{e:12,} / {time.ticks_diff(e,0):12,} / {e-1_073_741_723:4,}')

Output:

(sysname='esp32', nodename='esp32', release='1.23.0', version='v1.23.0 on 2024-06-02', machine='Generic ESP32 with ESP32')

All types and values are the same:

<class 'int'> [(True, 0), (True, 0), (True, 0)]
<class 'int'> [(True, 0), (True, 0), (True, 0)]
<class 'int'> [(True, 0), (True, 0), (True, 0)]

All second values should be constant -1 in my case.
None of the third values should have a leading comma:

1,073,741,823 /           -1 /  100
1,073,741,823 /  536,773,208 / ,100
1,073,741,823 /  536,773,704 / ,100

Perhaps a,b,c are represented differently in the C-Code below? Something seems to happen at value 2**30.

Don't know if this behavior is specific to the esp32 or more generally about MicroPython.
Please test the code below on other ports too - perhaps with an other power of 2 there.

For testing I set MAX = (2**30)-1 and ran into trouble with time.ticks_diff(MAX,0)].
time.ticks_us() may return MAX in a representation that doesn't fail and MAX = time.ticks_add(0,-1)
generates the same value like MAX = (2**30)-1 without failure with time.ticks_diff(MAX,0).
But I think the result of a function shouldn't depend on the way an equal input value was created.
Since it also effects the format string, I fear to run into other problems (in worst case without noticing).

Therefore I think it's a bug.

Have a great week!
c-max

[robert-hh]

Works fine on a ESP32, preview 1.24.0-110, fails at an earlier version of the firmware, like v1.23.0. Same for RPI Pico.
All tested boards with a recent preview RPi-Pico, SAMD51 and Teensy 4.0 (MIMXRT1062) pass.
So let's conclude that the issue is absent in the daily builds. Please test that yourself.

[c-max]

You are right. The preview 'v1.24.0-preview.163.gad3552ae2 on 2024-08-02' works for me too.
Thanks for the quick help.

And sorry that I forget to test the previews before.

[robert-hh]

Thank you for the confirmation, and no need to apologize. It's good to know this difference between versions.

[andrewleech]

I don't remember the full context or exactly when but I think there was a recent change to the way these kind of "maximum integers" are handled to deal with an inconsistency like this.

[c-max]

Great improvement. :)

[dpgeorge]

There is no bug here. You cannot pass arbitrary arguments to the time.ticks_diff() function.

The only values that should be passed to ticks_diff are values returned from ticks_ms(), ticks_us(), ticks_cpu(), and ticks_add(). Even though they look like integers you should consider these values opaque.

Only the result of ticks_diff() can be considered an integer.

(Under the hood, there's a difference between small and big integers, and the ticks functions consider all their arguments as small ints without checking. So if you pass a big int in then you get undefined behaviour, because you're operating on a pointer value rather than a small int value.)

[c-max]

I was testing. But it's rare to hit the max value with ticks_us(). Therefore I set it by hand.
I assumed the cause you mentioned. As user it's a bit messy if an input of same type and value (view of the python coder) leads to different behavior.
Fortunately it works in the current preview version - so I have hopes for a future release.