Prothon vs. Python integers

[Christos TZOTZIOY Georgiou]

Re: Prothon vs. Python integers

On 25 May 2004 07:02:09 -0400, rumours say that Heather Coppersmith
<me@privacy.net > might have written:
[color=blue]
>What does it mean, for example, to multiply your credit
>card number by three?[/color]

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]

Re: Prothon vs. Python integers

danb_83@yahoo.c om (Dan Bishop) wrote:[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]

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]

Re: Prothon vs. Python integers

Sion Arrowsmith wrote:[color=blue]
> Mark Hahn <mark@prothon.o rg> wrote:[color=green]
>> 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.[/color]

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

[Greg Ewing]

Re: Prothon vs. Python integers

Mark Hahn wrote:[color=blue]
>
> Surely
> once you get to 3.7e19 you are in floating point territory.[/color]

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]

Re: Prothon vs. Python integers

Greg Ewing wrote:
[color=blue][color=green]
>> Surely
>> once you get to 3.7e19 you are in floating point territory.[/color]
>
> 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.[/color]

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

[Marcin 'Qrczak' Kowalczyk]

Re: Prothon vs. Python integers

On Tue, 25 May 2004 17:59:20 -0700, Mark Hahn wrote:
[color=blue]
> I've agreed to adding longs. I'm thinking of only having longs.[/color]

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
\__/ qrczak@knm.org. pl
^^ http://qrnik.knm.org.pl/~qrczak/

[Calvin Spealman]

Re: Prothon vs. Python integers

Marcin 'Qrczak' Kowalczyk wrote:[color=blue]
> 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.[/color]

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]

Re: Prothon vs. Python integers

Marcin 'Qrczak' Kowalczyk wrote:[color=blue]
> On Tue, 25 May 2004 17:59:20 -0700, Mark Hahn wrote:
>[color=green]
>> I've agreed to adding longs. I'm thinking of only having longs.[/color]
>
> 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.[/color]

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.