Prothon vs. Python integers

[Marcin 'Qrczak' Kowalczyk]

I've agreed to adding longs. I'm thinking of only having longs.

It's more efficient if ints which fit in a machine word (or a machine word
minus one or two bits used for tagging them as ints) are represented as
such, rather than using a generic big int representation.

It doesn't mean they should be treated differently in the language.
It can be a hidden implementation detail, visible only for those who write
extensions in C.

 

[Mark Hahn]

It's more efficient if ints which fit in a machine word (or a machine
word minus one or two bits used for tagging them as ints) are
represented as such, rather than using a generic big int
representation.

It doesn't mean they should be treated differently in the language.
It can be a hidden implementation detail, visible only for those who
write extensions in C.

I've already implemented the new ints in Prothon. They behave as normal
ints until an overflow occurs and then they are treated as a bigint. There
is no performance penalty at all because I have to check for overflow
anyway.

C extension coders see no difference unless they want to deal with bigints.
Macros provide access to the ints and if they ask for a normal size int that
is actually a bigint it just throws an excepton.

 

[Calvin Spealman]

It's more efficient if ints which fit in a machine word (or a machine word
minus one or two bits used for tagging them as ints) are represented as
such, rather than using a generic big int representation.

Seems like it should be possible to implement big numbers in a way that
small numbers are nearly as, as, or more efficient than machine integers,
when you take into account the overflow checking needed for regular
integers in a language like python.