int/long unification hides bugs

kartik kartick_vaddadi at yahoo.com
Wed Oct 27 00:47:59 EDT 2004


aleaxit at yahoo.com (Alex Martelli) wrote in message news:<1gm98e3.ewsm1jxg9y3tN%aleaxit at yahoo.com>...
>  
> Try doing some accounting in Turkish liras, one of these days.  Today,
> each Euro is 189782957 cents of Turkish liras.  If an Italian firm
> selling (say) woodcutting equipment bids on a pretty modest contract in
> Turkey, offering machinery worth 2375220 Euros, they need to easily
> compute that their bid is 450776275125540 cents of Turkisk Liras.  And
> that's a _pretty modest_ contract, again -- if you're doing some
> computation about truly substantial sums (e.g. ones connected to
> government budgets) the numbers get way larger.
> [...]Even just for accounting, unlimited-size integers are simply much more 
> practical.
> 
> 
> > as another example, using too long a string as an index into a
> > dictionary is not a problem (true, the dictionary may not have a
> > mapping, but i have the same issue with a short string). but too long
> > an index into a list rewards me with an exception.
> 
> But the same index, used as a dictionary key, works just fine.  Specious
> argument, therefore.

I don't think so. I didn't say that large numbers always cause
trouble, so you can't claim to have refuted by argument by giving a
single counter-example.


> As common and everyday a
> computation (in some fields) as the factorial of 1000 (number of
> permutations of 1000 objects) is 2**8530 -- and combinatorial arithmetic
> is anything but an "ivory tower" pursuit these days, and factorial is
> the simplest building block in combinatorial arithmetic.

It's nice to get some facts, rather than an attempt to prove your
position by analogy between ints & strings ("Proof by analogy is
fraud" - Bjarne Stroustrup)



More information about the Python-list mailing list