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.
[color=blue][color=green][color=darkred]
>>> print 2**65[/color][/color][/color]
368934881474191 03232
[color=blue][color=green][color=darkred]
>>> print 2**65 == (2**65 + 1)[/color][/color][/color]
False


C:\temp\prothon \Prothon>protho n

Prothon 0.1 Interactive Console, Build 532, May 21 2004 (Ctrl-D to exit)
[color=blue][color=green][color=darkred]
>>> print 2** 65[/color][/color][/color]
3.68935e+19
[color=blue][color=green][color=darkred]
>>> print 2**65 == (2**65 + 1)[/color][/color][/color]
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]

Re: Prothon vs. Python integers


"Paul Prescod" <paul@prescod.n et> wrote
[color=blue]
> 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.
>[color=green][color=darkred]
> >>> print 2**65[/color][/color]
> 368934881474191 03232
>[color=green][color=darkred]
> >>> print 2**65 == (2**65 + 1)[/color][/color]
> False
>
>
> C:\temp\prothon \Prothon>protho n
>
> Prothon 0.1 Interactive Console, Build 532, May 21 2004 (Ctrl-D to exit)
>[color=green][color=darkred]
> >>> print 2** 65[/color][/color]
> 3.68935e+19
>[color=green][color=darkred]
> >>> print 2**65 == (2**65 + 1)[/color][/color]
> 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.[/color]

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]

Re: Prothon vs. Python integers

On Mon, 24 May 2004 11:31:08 -0700,
"Mark Hahn" <mark@prothon.o rg> wrote:
[color=blue]
> "Paul Prescod" <paul@prescod.n et> wrote[/color]

[ snip ]
[color=blue][color=green]
>> Prothon 0.1 Interactive Console, Build 532, May 21 2004 (Ctrl-D to exit)
>>[color=darkred]
>> >>> print 2** 65[/color]
>> 3.68935e+19
>>[color=darkred]
>> >>> print 2**65 == (2**65 + 1)[/color]
>> True[/color][/color]
[color=blue][color=green]
>> 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.[/color][/color]
[color=blue]
> I'm sure this isn't the only place Python is better.[/color]
[color=blue]
> 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.[/color]
[color=blue]
> 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.[/color]

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]

Re: Prothon vs. Python integers


"Heather Coppersmith" <me@privacy.net > wrote in message
news:m2k6z1ejcc .fsf@unique.pho ny.fqdn...
[color=blue][color=green]
> > 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.[/color]
>
> 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).[/color]

No economy is ever going to to have a gdp of 10**19 pennies.
[color=blue]
> Also, modern day cryptography applications can demand integer/
> logical operations on 256-, 512-, or more- bit (upwards of 1e150)
> integers.[/color]

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]

Re: Prothon vs. Python integers

Heather Coppersmith wrote:
[color=blue]
> Also, modern day cryptography applications can demand integer/
> logical operations on 256-, 512-, or more- bit (upwards of 1e150)
> integers.[/color]

Also, number theorists certainly would care.

--
__ Erik Max Francis && max@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]

Re: Prothon vs. Python integers

On 24 May 2004 15:05:55 -0400, rumours say that Heather Coppersmith
<me@privacy.net > might have written:
[color=blue]
>(lira and drachma spring
>to mind, too)[/color]

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]

Re: Prothon vs. Python integers

"Mark Hahn" <mark@prothon.o rg> wrote in message news:<Mbrsc.152 53$bF3.12865@fe d1read01>...[color=blue]
> "Paul Prescod" <paul@prescod.n et> wrote
>[color=green]
> > 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.
> >[color=darkred]
> > >>> print 2**65[/color]
> > 368934881474191 03232
> >[color=darkred]
> > >>> print 2**65 == (2**65 + 1)[/color]
> > False
> >
> >
> > C:\temp\prothon \Prothon>protho n
> >
> > Prothon 0.1 Interactive Console, Build 532, May 21 2004 (Ctrl-D to exit)
> >[color=darkred]
> > >>> print 2** 65[/color]
> > 3.68935e+19
> >[color=darkred]
> > >>> print 2**65 == (2**65 + 1)[/color]
> > 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.[/color]
>
> 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.[/color]

Unless you're working on problems in Number Theory, in which every single
decimal digit of 2**177525 - 1 is significant.
[color=blue]
>I can't imagine counting anything up to 10**19.[/color]

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]

Re: Prothon vs. Python integers

Heather Coppersmith <me@privacy.net > wrote in message news:<m2k6z1ejc c.fsf@unique.ph ony.fqdn>...
....[color=blue][color=green]
> > 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.[/color]
>
> 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[/color]

Or credit card numbers. They're 16 digits long, and Microsoft Excel
has this inconvenient feature of displaying them with 15 significant
digits.
[color=blue]
> (lira and drachma spring to mind, too).[/color]

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]

Re: Prothon vs. Python integers

"Mark Hahn" <mark@prothon.o rg> writes:
[color=blue]
> 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.[/color]

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]

Re: Prothon vs. Python integers

Mark Hahn wrote:[color=blue]
> 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.[/color]

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]

Re: Prothon vs. Python integers

On 24 May 2004 23:49:42 -0700,
danb_83@yahoo.c om (Dan Bishop) wrote:
[color=blue]
> Heather Coppersmith <me@privacy.net > wrote in message news:<m2k6z1ejc c.fsf@unique.ph ony.fqdn>...[/color]
[color=blue][color=green]
>> Accountants ("bean counters," in the derogatory vernacular)
>> will be displeased if Prothon silently loses pennies (or other
>> small- valued currencies) after a certain amount[/color][/color]
[color=blue]
> Or credit card numbers. They're 16 digits long, and Microsoft
> Excel has this inconvenient feature of displaying them with 15
> significant digits.[/color]

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]

Re: Prothon vs. Python integers

Mark Hahn <mark@prothon.o rg> wrote:[color=blue]
>No economy is ever going to to have a gdp of 10**19 pennies.[/color]

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 -- siona@chiark.gr eenend.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]

Re: Prothon vs. Python integers

Heather Coppersmith wrote:[color=blue]
> objects. What does it mean, for example, to multiply your credit
> card number by three?[/color]

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

[Mark Hahn]

Re: Prothon vs. Python integers


"Jacek Generowicz" <jacek.generowi cz@cern.ch> wrote in message
news:tyfd64tlzq r.fsf@pcepsft00 1.cern.ch...[color=blue]
> "Mark Hahn" <mark@prothon.o rg> writes:
>[color=green]
> > Longs seemed like a needless exotic kludge to me in the 64-bit world.[/color][/color]
Surely[color=blue][color=green]
> > once you get to 3.7e19 you are in floating point territory. I can't[/color][/color]
imagine[color=blue][color=green]
> > counting anything up to 10**19.[/color]
>
> 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.[/color]

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

[Mark Hahn]

Re: Prothon vs. Python integers


"Peter Hickman" <peter@semantic o.com> wrote
[color=blue][color=green]
> > Longs seemed like a needless exotic kludge to me in the 64-bit world.[/color][/color]
Surely[color=blue][color=green]
> > once you get to 3.7e19 you are in floating point territory. I can't[/color][/color]
imagine[color=blue][color=green]
> > counting anything up to 10**19.[/color]
>
> Except all those sad people doing that thing called 'maths'.
>
> Sorry but one of my requirements for a language is that is can handle[/color]
integers of any size quickly and easily (and a good integer square root
would be nice). However I always seem to[color=blue]
> end up coding with C and GMP.[/color]

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