Prothon vs. Python integers

[Paul Prescod]

I think that in this case, Python is demonstrably better than Prothon.

C:\temp\prothon\Prothon>python
ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

36893488147419103232

False


C:\temp\prothon\Prothon>prothon

Prothon 0.1 Interactive Console, Build 532, May 21 2004 (Ctrl-D to exit)

3.68935e+19

True

If Prothon is a language designed for the next ten years then it should
be tuned for correctness and ease of use, not for limitations of today's
hardware.

Paul Prescod

 

[Mark Hahn]

I think that in this case, Python is demonstrably better than Prothon.

C:\temp\prothon\Prothon>python
ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

36893488147419103232

False


C:\temp\prothon\Prothon>prothon

Prothon 0.1 Interactive Console, Build 532, May 21 2004 (Ctrl-D to exit)

3.68935e+19

True

If Prothon is a language designed for the next ten years then it should
be tuned for correctness and ease of use, not for limitations of today's
hardware.

I'm sure this isn't the only place Python is better.

Prothon has the long integer support in the parser if anyone wants to take
the trouble to put the long object code in. I did nothing to preclude it. I
just didn't see any need for it myself and didn't take the trouble to put it
in.

Longs seemed like a needless exotic kludge to me in the 64-bit world. Surely
once you get to 3.7e19 you are in floating point territory. I can't imagine
counting anything up to 10**19.

 

[Heather Coppersmith]

"Paul Prescod" <[email protected]> wrote

[ snip ]

I'm sure this isn't the only place Python is better.

Prothon has the long integer support in the parser if anyone
wants to take the trouble to put the long object code in. I did
nothing to preclude it. I just didn't see any need for it myself
and didn't take the trouble to put it in.

Longs seemed like a needless exotic kludge to me in the 64-bit
world. Surely once you get to 3.7e19 you are in floating point
territory. I can't imagine counting anything up to 10**19.

Beans? ;-)

Accountants ("bean counters," in the derogatory vernacular) will
be displeased if Prothon silently loses pennies (or other small-
valued currencies) after a certain amount (lira and drachma spring
to mind, too).

Also, modern day cryptography applications can demand integer/
logical operations on 256-, 512-, or more- bit (upwards of 1e150)
integers.

Regards,
Heather

 

[Mark Hahn]

Beans? ;-)

Accountants ("bean counters," in the derogatory vernacular) will
be displeased if Prothon silently loses pennies (or other small-
valued currencies) after a certain amount (lira and drachma spring
to mind, too).

No economy is ever going to to have a gdp of 10**19 pennies.

Also, modern day cryptography applications can demand integer/
logical operations on 256-, 512-, or more- bit (upwards of 1e150)
integers.

Are Python longs being used for those? I guess even if they aren't someone
might want to evaluate algorithms using longs.

Ok, I'm wrong once again. I'll put implementing longs on the to-do list.

 

[Erik Max Francis]

Also, modern day cryptography applications can demand integer/
logical operations on 256-, 512-, or more- bit (upwards of 1e150)
integers.

Also, number theorists certainly would care.

 

[Christos TZOTZIOY Georgiou]

(lira and drachma spring
to mind, too)

Lira? Drachma? Too late for that... There are lots of children in
both countries that had their lunch money always in euros.

PS A funny incident from the transition period to the euro: in a small
shop, an elderly lady is before me in front of the counter.

Lady: "How much is it?"
Clerk: "4.2 euros"
Lady: "No, I mean in *money*, how much is it?"

The translation might not be as strong as the original, but I loved it
so much, that since then, whenever I did conversions out loud, it was
"euros" to "money", never "drachmae"

 

[mensanator]

I think that in this case, Python is demonstrably better than Prothon.

C:\temp\prothon\Prothon>python
ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

print 2**65 36893488147419103232

print 2**65 == (2**65 + 1)

False


C:\temp\prothon\Prothon>prothon

Prothon 0.1 Interactive Console, Build 532, May 21 2004 (Ctrl-D to exit)

print 2** 65 3.68935e+19

print 2**65 == (2**65 + 1)

True

If Prothon is a language designed for the next ten years then it should
be tuned for correctness and ease of use, not for limitations of today's
hardware.

I'm sure this isn't the only place Python is better.

Prothon has the long integer support in the parser if anyone wants to take
the trouble to put the long object code in. I did nothing to preclude it. I
just didn't see any need for it myself and didn't take the trouble to put it
in.

Longs seemed like a needless exotic kludge to me in the 64-bit world. Surely
once you get to 3.7e19 you are in floating point territory.

Unless you're working on problems in Number Theory, in which every single
decimal digit of 2**177525 - 1 is significant.

I can't imagine counting anything up to 10**19.

Not every sequence increments by 1. Putting 2**177525 - 1 into the Collatz
Conjecture results in a mere 2.5 million iterations, not 10**53000.
Limiting the loop counts to <10**19 doesn't mean you have to limit
the values.

 

[Dan Bishop]

Beans? ;-)

Accountants ("bean counters," in the derogatory vernacular) will
be displeased if Prothon silently loses pennies (or other small-
valued currencies) after a certain amount

Or credit card numbers. They're 16 digits long, and Microsoft Excel
has this inconvenient feature of displaying them with 15 significant
digits.

(lira and drachma spring to mind, too).

The Italian Lira and Greek Drachma have been replaced by the Euro.

However, the *Turkish* lira hasn't, and I think it takes 500 000 of
those just to buy a candy bar.

 

[Jacek Generowicz]

Longs seemed like a needless exotic kludge to me in the 64-bit world. Surely
once you get to 3.7e19 you are in floating point territory. I can't imagine
counting anything up to 10**19.

Aaaargh !

Please don't do this. Please don't make language design decisions on
the basis of your lack of imagination. It's a very good way of
designing a crap language.

 

[Peter Hickman]

Longs seemed like a needless exotic kludge to me in the 64-bit world. Surely
once you get to 3.7e19 you are in floating point territory. I can't imagine
counting anything up to 10**19.

Except all those sad people doing that thing called 'maths'.

Sorry but one of my requirements for a language is that is can handle integers of any size quickly and easily (and a good integer square root would be nice). However I always seem to
end up coding with C and GMP.

 

[Heather Coppersmith]

On 24 May 2004 23:49:42 -0700,

Or credit card numbers. They're 16 digits long, and Microsoft
Excel has this inconvenient feature of displaying them with 15
significant digits.

Credit card numbers aren't integers, though; they just look like
integers (modulo the internal spaces) when you print them out (not
unlike U.S. postal codes, which consist of five or nine digits).
Excel overzealously converts all such entries to mathematical
objects. What does it mean, for example, to multiply your credit
card number by three?

Regards,
Heather

 

[Roy Smith]

Or credit card numbers. They're 16 digits long, and Microsoft Excel
has this inconvenient feature of displaying them with 15 significant
digits.

I'm not sure credit card numbers are really numbers. I think of them
more as strings. The fact that they're made up only of digits is almost
meaningless, since you don't generally do any arithmetic operations on
them. You record them someplace and spit them back when needed. Even
as database keys, you're more likely to hash them than to use their
arithmetic value directly.

One common operation is to figure out which vendor owns a certain
number, and you do that by looking at the first four digits. Thinking
of it as a string, you would do "substring (digitString, 0, 4)".
Thinking of it as an integer, you would do "int (value / 1000000000)".
Which would you do?

Another common example of digit strings which aren't really numeric
values is a telephone number. If I've counted properly, to call a
number in London, England using my calling card, I need to dial 31
digits (access number + 01 + country code + local number + auth code +
PIN). Sure, they're all digits, but I think any sane system would store
that as a string, especially given that the only operation I ever want
to do with the sub-parts is concatenate them in various ways.

 

[Sion Arrowsmith]

No economy is ever going to to have a gdp of 10**19 pennies.

Turkey's is around 10**18 lira (obtained from 2002 GDP in $ and
current exchange rate). You could argue that by the time they
hit 10**19 they'll have got EU membership and gone over to the
Euro....

(Japan's GDP appears to be around 10**16Y, BTW.)

Given the number of times we see newbies confused by Python's
handling of floating points, it strikes me that silent conversion
of overflowing ints to doubles is asking for trouble somewhere
down the line, and should be avoided if possible.

 

[Calvin Spealman]

objects. What does it mean, for example, to multiply your credit
card number by three?

I get three credit cards and go on a shopping spree?

 

[Mark Hahn]

Aaaargh !

Please don't do this. Please don't make language design decisions on
the basis of your lack of imagination. It's a very good way of
designing a crap language.

I said yesterday noon in this same thread I was wrong and was implementing
longs. Please give me a break.

 

[Mark Hahn]

Except all those sad people doing that thing called 'maths'.

Sorry but one of my requirements for a language is that is can handle

integers of any size quickly and easily (and a good integer square root
would be nice). However I always seem to

end up coding with C and GMP.

I said in this thread at noon yesterday that I was wrong and that I will
implement longs.

 

[Christos TZOTZIOY Georgiou]

What does it mean, for example, to multiply your credit
card number by three?

I instantly become more attractive?-)

 

[Mark Hahn]

Turkey's is around 10**18 lira (obtained from 2002 GDP in $ and
current exchange rate). You could argue that by the time they
hit 10**19 they'll have got EU membership and gone over to the
Euro....

(Japan's GDP appears to be around 10**16Y, BTW.)

Given the number of times we see newbies confused by Python's
handling of floating points, it strikes me that silent conversion
of overflowing ints to doubles is asking for trouble somewhere
down the line, and should be avoided if possible.

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

 

[Greg Ewing]

Surely
once you get to 3.7e19 you are in floating point territory.

Incorrect. You're only ever in floating point territory
if you can tolerate inexact results. Some applications
can't.

Even if you don't support arbitrary-size integers, you
should *not* automatically overflow from ints to floats.
You should raise an exception instead. That way, people
won't be bitten by unexpected loss of precision.

 

[Mark Hahn]

Incorrect. You're only ever in floating point territory
if you can tolerate inexact results. Some applications
can't.

Even if you don't support arbitrary-size integers, you
should *not* automatically overflow from ints to floats.
You should raise an exception instead. That way, people
won't be bitten by unexpected loss of precision.

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