Prothon vs. Python integers

Discussion in 'Python' started by Paul Prescod, May 24, 2004.

  1. Paul Prescod

    Paul Prescod Guest

    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
     
    Paul Prescod, May 24, 2004
    #1
    1. Advertising

  2. Paul Prescod

    Mark Hahn Guest

    "Paul Prescod" <> 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.
     
    Mark Hahn, May 24, 2004
    #2
    1. Advertising

  3. On Mon, 24 May 2004 11:31:08 -0700,
    "Mark Hahn" <> wrote:

    > "Paul Prescod" <> 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
     
    Heather Coppersmith, May 24, 2004
    #3
  4. Paul Prescod

    Mark Hahn Guest

    "Heather Coppersmith" <> wrote in message
    news:...

    > > 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.
     
    Mark Hahn, May 24, 2004
    #4
  5. 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 && && 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
     
    Erik Max Francis, May 24, 2004
    #5
  6. On 24 May 2004 15:05:55 -0400, rumours say that Heather Coppersmith
    <> 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
     
    Christos TZOTZIOY Georgiou, May 24, 2004
    #6
  7. Paul Prescod

    mensanator Guest

    "Mark Hahn" <> wrote in message news:<Mbrsc.15253$bF3.12865@fed1read01>...
    > "Paul Prescod" <> 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.
     
    mensanator, May 25, 2004
    #7
  8. Paul Prescod

    Dan Bishop Guest

    Heather Coppersmith <> wrote in message news:<>...
    ....
    > > 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.
     
    Dan Bishop, May 25, 2004
    #8
  9. "Mark Hahn" <> 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.
     
    Jacek Generowicz, May 25, 2004
    #9
  10. 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.
     
    Peter Hickman, May 25, 2004
    #10
  11. On 24 May 2004 23:49:42 -0700,
    (Dan Bishop) wrote:

    > Heather Coppersmith <> wrote in message news:<>...


    >> 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
     
    Heather Coppersmith, May 25, 2004
    #11
  12. Paul Prescod

    Roy Smith Guest

    (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.
     
    Roy Smith, May 25, 2004
    #12
  13. Mark Hahn <> 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 -- -- 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
     
    Sion Arrowsmith, May 25, 2004
    #13
  14. 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?
     
    Calvin Spealman, May 25, 2004
    #14
  15. Paul Prescod

    Mark Hahn Guest

    "Jacek Generowicz" <> wrote in message
    news:...
    > "Mark Hahn" <> 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, May 25, 2004
    #15
  16. Paul Prescod

    Mark Hahn Guest

    "Peter Hickman" <> 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.
     
    Mark Hahn, May 25, 2004
    #16
  17. On 25 May 2004 07:02:09 -0400, rumours say that Heather Coppersmith
    <> 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
     
    Christos TZOTZIOY Georgiou, May 25, 2004
    #17
  18. Paul Prescod

    Mark Hahn Guest

    Sion Arrowsmith wrote:
    > Mark Hahn <> 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.
     
    Mark Hahn, May 26, 2004
    #18
  19. Paul Prescod

    Greg Ewing Guest

    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
     
    Greg Ewing, May 26, 2004
    #19
  20. Paul Prescod

    Mark Hahn Guest

    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.
     
    Mark Hahn, May 26, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Aahz
    Replies:
    12
    Views:
    537
    Dave Benjamin
    Apr 5, 2004
  2. Joe Mason
    Replies:
    2
    Views:
    364
    Joe Mason
    Apr 1, 2004
  3. Jacek Generowicz
    Replies:
    4
    Views:
    302
    Jacek Generowicz
    Apr 2, 2004
  4. Mark Hahn
    Replies:
    41
    Views:
    935
    Paul Boddie
    May 27, 2004
  5. Mark Hahn
    Replies:
    20
    Views:
    619
    Mark Hahn
    Jul 13, 2004
Loading...

Share This Page