`1e23 != 10 ** 23` now. Possible solution: PyFloatLongObject

[Marco_Sulla]

Human beings know that

100000000000000000000000.0
1.0e+23

are integers. They are in the group of real numbers, but they are also in the integer group.

My idea is to represent internally these numbers as a new internal type. Temporary name: PyFloatLongObject.

Integers have “infinite” precision. So, 1e23 == 10 ** 23 is False now.

If 1e23 will be internally a PyFloatLongObject, 1e23 == 10 ** 23 will become True.

This behavior can be restricted to only big integers, to not slow down little floats like 10.0

EDIT: The scope is not having an infinite precision for float operations, but an infinite precision for creation of floats that are integers.

[steven.daprano]

Human beings know that

100000000000000000000000.0
1.0e+23

are integers.

I don’t know that. I know that they are both floating point values. Are you saying I’m not a human being?

This behavior can be restricted to only big integers, to not slow down little floats like 10.0

But it will slow down small floats too, because every single float operation will have to check whether the result is going to be “big enough”, and if so, swap to integer mode. And then if the result is not exactly a power of ten, it will have to swap back again to float mode.

Why don’t you just use Decimal?

[Marco_Sulla]

post deleted by author

[John_Carter]

I think python already does this. Python uses IEEE floating point doubles. If you read arolund this you will find that if abs(x) less than 2^53 and is an integer IEEE doubles store the exact representation. As long as the result is less that 2**53, +, - and * preserve the integer accuracy. / does not so you have to divide using //. You can check usins the is_integer method.
Converting to int is fast so there is no penalty converting to use as an index or a slice.

[Marco_Sulla]

post deleted by author

[John_Carter]

2^52 < 1e23 == True, any way ~9e15 is big enougjh for me.

[steven.rumbalski]

Why are you polluting Python Help with something that should be in Python Ideas? This clearly isn’t a post where you are asking for help with Python.

[steven.daprano]

You don’t have to check for every single float operation. You have to check only at creation of a float.

Do you understand that all float operations have to create a float? x + 1.0 has to create a float.

an infinite precision for creation of floats that are integers.

All floats above 2.0**52 represent whole numbers. They certainly do not have infinite precision. They have 53 bits of precision.

Why don’t you just use Decimal? I’m pretty sure they do everything you want.

>>> from decimal import Decimal

>>> x = Decimal("1e23")

>>> format(x, '.5f')

'100000000000000000000000.00000'

[Marco_Sulla]

@steven.rumbalski

Why are you polluting Python Help with something that should be in Python Ideas?

But I posted in Python Ideas. It was moved. Can some moderator explain me why?

[Marco_Sulla]

@steven.daprano

Do you understand that all float operations have to create a float? x + 1.0 has to create a float.

Steven, I re-quote myself:

@Marco_Sulla

The scope is not having an infinite precision for float operations, but an infinite precision for creation of floats that are integers.

@steven.daprano

Why don’t you just use Decimal?

Decimal is a cannon for a simple task. Please re-read carefully my proposal.

[storchaka (Serhiy Storchaka)]

I moved this topic to Python Help because it is not about enhancing Python. There is nothing here that could make Python better. The only problem is educational. The OP should learn about floating point numbers, and how they are different from integer numbers, numbers with finite decimal representations, and mathematical real numbers. I encourage other users not to write comments that do not have an educational purpose.

Sorry for not clarifying this straight away. I was exhausted.

[Marco_Sulla]

@storchaka

There is nothing here that could make Python better.

Well, I think we can remove “discuss” from the URL of this forum X-D

@storchaka

The only problem is educational.

OK, here I completely agree

@storchaka

I encourage other users not to write comments that do not have an educational purpose.

I will follow your suggestion:

mod·er·at·ing
to reduce the excessiveness of; make less violent, severe, intense, or rigorous: to moderate the sharpness of one’s words.
MODERATE Definition & Usage Examples | Dictionary.com

@storchaka

Sorry for not clarifying this straight away. I was exhausted.

So I exhausted you with two simple posts? Hey, I’m a big supervillain

If you think my ideas are stupid, I’m an ignorant and I will never contribute to something in a positive way, why you read me?

@storchaka

The OP should learn about floating point numbers, and how they are different from integer numbers

1. I proposed an internal type for creation of floats with infinite precision only for big integers, because I know that floats are different from integers, or I will not proposed that.
2. I know what decimal is and what BigDecimal is, and I’m not proposing to use decimal everywhere.
3. I know that floats are not reals (even if Fortran does not agree).

[Marco_Sulla]

About my proposal

What I simply suggested is to create a “boxed” integer instead of a float for big floats that can be easily recognized by the parser as integers, like 1e23 or 100000000000000000000000.0. This integer is “boxed”, or “proxied” inside a float (a new internal type, to not augment the size of ALL floats), so it will act as a float and it will have all the trouble of a float with operations. So this is NOT decimal.

This way, 1e23 will remain a float, but internally it will be represented by a PyLong.

About my dignity

Well, I wanted to be a little ironic, but it seems it’s more appropriate a serious discussion.

@storchaka

There is nothing here that could make Python better.

This is an harsh statement without any explaining. And personally I feel it offending, if I can say.

Since any discussion with Serhiy seems useless, can someone explain me why my idea is so bad?

[effigies (Chris Markiewicz)]

@Marco_Sulla

can someone explain me why my idea is so bad?

Not a core dev, but I think adding a brand new literal type with unfamiliar semantics should in general face an uphill climb. It’s added complexity to reason about the behavior of programs (1e23 looks like a float, but acts like an int sometimes) and has the potential to change the behavior of existing programs. If I have an application where I want to analyze floating point error and not simply live with it, a new type whose behavior is determined by context would be an unwelcome addition. (If that description is incorrect, consider that I have read two threads and that’s the best I could make of it.)

Floats and ints are broadly understood, and there are perfectly good ways to get integer values of 1e23 that will not surprise anybody who is used to working with floats and ints.

Both this thread and the original seemed to have a hypothetical scientist who needs to be protected from learning floating point error as the motivating use case, and personally I don’t find it compelling. I think education about how to construct large integers would be more valuable.

---

On a meta-level, I suspect that people are annoyed at how the original thread kept going after it became clear that there is no appetite among core devs to change the language in such a significant way, and now you have started another thread on the same topic. I don’t know about others, but I would hope that an Ideas thread that keeps getting longer would be a sign of broad interest and increasing precision about what the proposal would entail. Instead, the thread was driven by a couple people repeating arguments with perhaps minor variation. I can see how moderators would be frustrated with this situation.

[steven.daprano]

PS: in Java 17:

1e23 == Math.pow(10, 23)

is true. Maybe Java devs does not know that floats are not integers X-D

Or maybe Java converts integer arguments to doubles before calling the double function Math.Pow which returns a double, like the documentation says?

[steven.daprano]

can someone explain me why my idea is so bad?

Try reading your recent discussion thread that preceded this one.

We have already spent days of elapsed time and many man-hours of effort explaining why this suggestion is not workable. We’ve given you an alternative which will do what you want and exists today, but you refuse to use it. (Decimal.)

You have dismissed Decimal because you think it is too complex. To get the result you want from floats, we would need a hybrid data structure and to reimplement all the floating point functions to support this new hybrid. This will surely be more complex than Decimal, much more likely to contain bugs, and with the severe risk of surprising corner cases where this hybrid numeric type behaves in ways even more surprising than floats.

If you disagree, if you think it is so easy, go ahead and prove us wrong by implementing it. Just don’t expect other people to do it for you when they have no interest in this proposal, are sure it will be hard to do right, won’t do what you expect, and there already exists a solution that solves your problem better.

[Rosuav (Chris Angelico)]

@steven.daprano

To get the result you want from floats, we would need a hybrid data structure

…

I’m not sure which is fuel for worse nightmares: that image, or the hybrid data structure it’s describing.

[Marco_Sulla]

@effigies

adding a brand new literal type

I have not suggested to add a new literal type. Read below.

@effigies

with unfamiliar semantics

It’s a float. Where is it unfamiliar? Read below.

@effigies

(1e23 looks like a float, but acts like an int sometimes)

You have not understood the proposal. I’m proposing a float, that acts as a float, but has infinite precision because his value internally is an PyLong. Read below.

@effigies

and has the potential to change the behavior of existing programs

This is true, it can improve them, since 1e23 == 10**23 and not 1e23 == 99999999999999991611392. Read below.

@effigies

a new type whose behavior is determined by context

I think you completely misunderstood my proposal. There’s no context and there’s no new type. I’m proposing an internal structure, not exposed, that will be created for float literals that are big integers. I quote myself, please read carefully:

########

@Marco_Sulla

What I simply suggested is to create a “boxed” integer instead of a float for big floats that can be easily recognized by the parser as integers, like 1e23 or 100000000000000000000000.0. This integer is “boxed”, or “proxied” inside a float (a new internal type, to not augment the size of ALL floats), so it will act as a float and it will have all the trouble of a float with operations. So this is NOT decimal.

This way, 1e23 will remain a float, but internally it will be represented by a PyLong.

########

@effigies

Both this thread and the original seemed to have a hypothetical scientist who needs to be protected from learning floating point error as the motivating use case, and personally I don’t find it compelling.

If so, you should program in C, not in Python.

@effigies

On a meta-level, I suspect that people are annoyed at how the original thread kept going after it became clear that there is no appetite among core devs to change the language in such a significant way

Well, if so, they could simply ignore the thread, not move to Help.

@effigies

and now you have started another thread on the same topic

Because I have the ideas more clear, but evidently no one has even read seriously my post.

@effigies

I don’t know about others, but I would hope that an Ideas thread that keeps getting longer would be a sign of broad interest and increasing precision about what the proposal would entail

Yes, if it remains in Idea section and it’s not moved to Help X-D

@effigies

Instead, the thread was driven by a couple people repeating arguments with perhaps minor variation. I can see how moderators would be frustrated with this situation.

No one have considered my frustration?

[franklinvp]

@Marco_Sulla

You have not understood the proposal. I’m proposing a float, that acts as a float, but has infinite precision because his value internally is an PyLong. Read below.

A new type, separate from float with that property, sure, decimal, mpmath or anyone’s own new class can do that. But having float matching the behavior of finite precision floating point arithmetic is useful. Two ways that come to mind are for interoperability with other languages, or when using Python for testing or reproducing computations done by software in other languages.

The “surprise” of seeing that 1e23 == 10 ** 23 is False can be solved by simply learning that 1e23 is a float, 10 and 23 are int and that ** on int outputs int.

[Marco_Sulla]

@steven.daprano

We have already spent days of elapsed time and many man-hours of effort explaining why this suggestion is not workable.

Is it pluralis maiestatis?

@steven.daprano

We’ve given you an alternative which will do what you want and exists today, but you refuse to use it. (Decimal.)

No one refuses to use decimal. I simply think that decimal, for this simple problem, is a cannon for killing a fly.

@steven.daprano

You have dismissed Decimal because you think it is too complex.

Not too complex, but too verbose, too slow and too much inelegant for this simple task.

@steven.daprano

To get the result you want from floats, we would need a hybrid data structure

Please define “hybrid data structure”.

@steven.daprano

and to reimplement all the floating point functions to support this new hybrid.

Hey, you’re a bit drastic? X-D Have you understood the new object is only internal, it will be completely transparent for the end user, and it’s always a float?

@steven.daprano

This will surely be more complex than Decimal

This is FUD X-D More complex than an entire library?

@steven.daprano

much more likely to contain bugs

Of course it will contain bugs, it’s code.

@steven.daprano

and with the severe risk of surprising corner cases where this hybrid numeric type behaves in ways even more surprising than floats.

The surprise will be to me to see corner cases for a float.

@steven.daprano

If you disagree, if you think it is so easy, go ahead and prove us wrong by implementing it.

Is it a defiance? Should I choose the weap… the language?

@steven.daprano

Just don’t expect other people to do it for you when they have no interest in this proposal, are sure it will be hard to do right, won’t do what you expect, and there already exists a solution that solves your problem better.

I expect only to discuss my idea, not hypothetical hybrid data, natural disasters and
grasshoppers. Furthermore, I expect that an idea will be in the… well, idea section?