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.

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.

Paul Prescod

[Mark Hahn]

"Paul Prescod" <pa**@prescod.net> wrote

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. I can't imagine
counting anything up to 10**19.

[Heather Coppersmith]

On Mon, 24 May 2004 11:31:08 -0700,
"Mark Hahn" <ma**@prothon.org> wrote:

"Paul Prescod" <pa**@prescod.net> wrote
[ snip ]

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. 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

--
Heather Coppersmith
That's not right; that's not even wrong. -- Wolfgang Pauli

[Mark Hahn]

"Heather Coppersmith" <[e-mail]> wrote in message
news:m2************@unique.phony.fqdn...

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).

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]

Heather Coppersmith wrote:

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.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ A war at sea. A war with no battles, no monuments ... only
casualties. -- Capt. Marko Ramius

[Christos TZOTZIOY Georgiou]

On 24 May 2004 15:05:55 -0400, rumours say that Heather Coppersmith
<[e-mail]> might have written:

(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" :)
--
TZOTZIOY, I speak England very best,
"I have a cunning plan, m'lord" --Sean Bean as Odysseus/Ulysses

[mensanator]

"Mark Hahn" <ma**@prothon.org> wrote in message news:<Mbrsc.15253$bF3.12865@fed1read01>...

"Paul Prescod" <pa**@prescod.net> wrote

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]

Heather Coppersmith <[e-mail]> wrote in message news:<m2************@unique.phony.fqdn>...
....

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

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]

"Mark Hahn" <ma**@prothon.org> writes:

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]

Mark Hahn wrote:

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,
da*****@yahoo.com (Dan Bishop) wrote:

Heather Coppersmith <[e-mail]> wrote in message news:<m2************@unique.phony.fqdn>...

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.

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

--
Heather Coppersmith
That's not right; that's not even wrong. -- Wolfgang Pauli

[Sion Arrowsmith]

Mark Hahn <ma**@prothon.org> wrote:

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.

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

[Calvin Spealman]

Heather Coppersmith wrote:

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]

"Jacek Generowicz" <ja**************@cern.ch> wrote in message
news:ty*************@pcepsft001.cern.ch...

"Mark Hahn" <ma**@prothon.org> writes:

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.

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

[Mark Hahn]

"Peter Hickman" <pe***@semantico.com> wrote

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.

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

[Christos TZOTZIOY Georgiou]

On 25 May 2004 07:02:09 -0400, rumours say that Heather Coppersmith
<[e-mail]> might have written:

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

I instantly become more attractive?-)
--
TZOTZIOY, I speak England very best,
"I have a cunning plan, m'lord" --Sean Bean as Odysseus/Ulysses

[Roy Smith]

da*****@yahoo.com (Dan Bishop) wrote:

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.

[Mark Hahn]

Sion Arrowsmith wrote:

Mark Hahn <ma**@prothon.org> wrote:

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.

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

[Greg Ewing]

Mark Hahn wrote:

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.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Mark Hahn]

Greg Ewing wrote:

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.

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

[Marcin 'Qrczak' Kowalczyk]

On Tue, 25 May 2004 17:59:20 -0700, Mark Hahn wrote:

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.

--
__("< Marcin Kowalczyk
\__/ qr****@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/

[Calvin Spealman]

Marcin 'Qrczak' Kowalczyk wrote:

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.

[Mark Hahn]

Marcin 'Qrczak' Kowalczyk wrote:

On Tue, 25 May 2004 17:59:20 -0700, Mark Hahn wrote:

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.

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.