Translate in the bytecode 1e23 into 1 followed by 23 zeros

I said may be as fast.

Are you running a version of Python with the “small int” optimization? If not, then multiplication of the BigInt 100 will probably be slower than multiplication of the machine float 100.0, simply because arbitrary sized BigInts are more expensive than machine ints.

Or maybe you are running on some obscure CPU that performs badly on integer maths.

The point is that there are many possible factors that can affect the speed of Python, and you should not assume that it will perform the same as low-level machine instructions.

100*100 gives you 10000, and the int cache is from -5 to 256.

Anyway yes, I have not disabled int caching. I don’t know why I should.

marco@buzz:~/sources/cpython_3_11_build$ python3.11
Python 3.11.2 (tags/v3.11.2-dirty:878ead1ac1, Feb  8 2023, 20:19:09) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 255
>>> b = 255
>>> a is b
True

I run an Intel CPU, but I agree that Intel is obscure, if you mean a greedy company X-D

So timeit and pyperf are useless?

Nobody says that your mum should have taught you this when you were four, but you have been a Python user for many, many years. Have you never noticed before today that Python ints are unlimited in size and that (unlike when programming in C) you never need to worry about wrapping around at the limit of 2**32 or 2**64?

Have you not read the documentation?

Or wondered why ints need a bit_length method if they are always fixed size?

Nobody expects you to know everything about Python but its not unreasonable to expect you to do some research before proposing ideas.

The idea was simply to store floats that are integers as integers. And I still think it’s a good idea :smiley:

You pointed out that integers are slower. This is something I never thought or perceived. Furthermore I never worked with big numbers in Python, since Python is really slow (I hope Microsoft boost will change something). I worked with BigInteger and BigNumber in Java, or with numpy/scipy.

Storing is not the end goal. Behaviour is. You can store the all the information in the universe in a single bit, but that is useless. We are interested in how the information changes and interacts, and a bit only admits two states.

Likewise, the idea of storing “floats that are integers as integers” is meaningless without considering how do you want those types to behave. The idea is not good or bad. It is no idea at all without talking about how it should behave.

Some examples of questions that you should ask yourself:

  1. What are the results of the arithmetic operations, and comparison, on those “floats that are integers”.
  2. How do you want those “floats that are integer” to convert into other types, like int, str, and float?

I already abandoned the idea.

I think that if you write Python from scratch, probably you’ll want that N.Me+X is not always a float, but it’s an integer if

({number of digits in M} - {number of digits in N} + 1) <= X.

while N.Me-X is always a float, for the sake of simplicity.

The problem is how to represent such scientific literals in the grammar.