Re: Decimal() instead of float?

Discussion in 'Python' started by Fredrik Lundh, Nov 12, 2006.

  1. Michael B. Trausch wrote:

    > Is there a way to use Decimal() by default in Python instead of float?


    nope.

    > For example, I have a ZIP code
    > database that can do some processing on its numbers, and the numbers are
    > stored as floating point values (exactly) but Python doesn't get them
    > right


    sounds odd. are you sure you don't mean "stored as strings containing
    decimal numbers" ?

    (who uses fractional ZIP codes, btw?)

    </F>
    Fredrik Lundh, Nov 12, 2006
    #1
    1. Advertising

  2. On Sun, 12 Nov 2006 02:31:04 +0100, Fredrik Lundh wrote:

    >> For example, I have a ZIP code
    >> database that can do some processing on its numbers, and the numbers are
    >> stored as floating point values (exactly) but Python doesn't get them
    >> right

    >
    > sounds odd. are you sure you don't mean "stored as strings containing
    > decimal numbers" ?
    >
    > (who uses fractional ZIP codes, btw?)


    Well, I can't speak for Americans, but here in Australia we typically give
    our post codes to six decimal places:

    Melbourne 3000.000000
    Brunswick 3056.000000
    Clifton Hill 3068.000000
    Sydney 2000.000000
    St Johns Park 2176.000000

    and so forth. You can't have too much precision with those floating point
    post/ZIP codes!


    --
    Steven.
    Steven D'Aprano, Nov 12, 2006
    #2
    1. Advertising

  3. On Sun, 12 Nov 2006 13:08:32 +1100, Steven D'Aprano
    <> declaimed the following in
    comp.lang.python:


    > Well, I can't speak for Americans, but here in Australia we typically give
    > our post codes to six decimal places:
    >
    > Melbourne 3000.000000
    > Brunswick 3056.000000
    > Clifton Hill 3068.000000
    > Sydney 2000.000000
    > St Johns Park 2176.000000
    >
    > and so forth. You can't have too much precision with those floating point
    > post/ZIP codes!


    Ah, but does one perform any arithmetic operations that require
    shifting (multiplication/division, say) these codes? If not, then the .
    is just a human-readability concern and internal usage is fully
    satisfied by an integer with (in your sample) 10 significant digits (or
    9 significant for a US ZIP+4 format); a small utility function for input
    and output to strip/insert the punctuation...
    --
    Wulfraed Dennis Lee Bieber KD6MOG

    HTTP://wlfraed.home.netcom.com/
    (Bestiaria Support Staff: )
    HTTP://www.bestiaria.com/
    Dennis Lee Bieber, Nov 12, 2006
    #3
  4. Fredrik Lundh

    John Machin Guest

    Steven D'Aprano wrote:
    > On Sun, 12 Nov 2006 02:31:04 +0100, Fredrik Lundh wrote:
    >
    > >> For example, I have a ZIP code
    > >> database that can do some processing on its numbers, and the numbers are
    > >> stored as floating point values (exactly) but Python doesn't get them
    > >> right

    > >
    > > sounds odd. are you sure you don't mean "stored as strings containing
    > > decimal numbers" ?
    > >
    > > (who uses fractional ZIP codes, btw?)

    >
    > Well, I can't speak for Americans, but here in Australia we typically give
    > our post codes to six decimal places:
    >
    > Melbourne 3000.000000
    > Brunswick 3056.000000
    > Clifton Hill 3068.000000
    > Sydney 2000.000000
    > St Johns Park 2176.000000
    >
    > and so forth. You can't have too much precision with those floating point
    > post/ZIP codes!


    Here in Austraila, (I expect this is common to most countries), there
    are people who are utterly clueless about elementary data model rules,
    like identification "numbers" should be kept as strings.

    E.g. (1) National grief started over twenty years ago when the Post
    Office started using postcodes with leading zeroes, and continues to
    the present. The postcode for Darwin can be stored as 800, "800", or
    "0800".

    E.g. (2) Many Australians have a Tax File Number (TFN) which is a
    9-digit number with an "officially kept secret" check digit algorithm
    (you need to sign an NDA with the Tax Office). Storing this as an
    integer allows the TFN be negative -- if the data entry for say
    123456789 is actually 123456789-, you don't check for anything (length,
    allowable characters, check digit) and an old-fashioned
    trailing-minus-allowed conversion-to-integer routine is used.

    Cheers,
    John
    John Machin, Nov 12, 2006
    #4
  5. Fredrik Lundh

    Ben Finney Guest

    "Steven D'Aprano" <> writes:

    > On Sun, 12 Nov 2006 02:31:04 +0100, Fredrik Lundh wrote:
    > > (who uses fractional ZIP codes, btw?)

    >
    > Well, I can't speak for Americans, but here in Australia we
    > typically give our post codes to six decimal places:
    >
    > Melbourne 3000.000000
    > Brunswick 3056.000000
    > Clifton Hill 3068.000000
    > Sydney 2000.000000
    > St Johns Park 2176.000000


    Yeah, I know. As soon as that legislation came in, I started giving
    the *precision* they asked for, with my own choice of *accuracy*, just
    to mess with their damned totalitarian databases.

    Melbourne 3000.000000
    Brunswick 3000.000000
    Clifton Hill 3000.000000

    But you try to tell people overseas about this legislation, and they
    just don't believe you.

    --
    \ "It is well to remember that the entire universe, with one |
    `\ trifling exception, is composed of others." -- John Andrew |
    _o__) Holmes |
    Ben Finney
    Ben Finney, Nov 12, 2006
    #5
  6. On Sun, 12 Nov 2006 20:38:31 +1100, Ben Finney wrote:

    > But you try to tell people overseas about this legislation, and they
    > just don't believe you.


    Ha! You were lucky. When I was a lad, we had to write our postcodes on
    envelopes in balanced ternary.


    --
    Steven.
    Steven D'Aprano, Nov 12, 2006
    #6
  7. Fredrik Lundh

    John Salerno Guest

    John Machin wrote:

    > Here in Austraila, (I expect this is common to most countries), there
    > are people who are utterly clueless about elementary data model rules,
    > like identification "numbers" should be kept as strings.


    Do you mean that ID numbers that serve as a primary key in a database
    should also be strings?
    John Salerno, Nov 15, 2006
    #7
  8. Fredrik Lundh

    Terry Reedy Guest

    "John Salerno" <> wrote in message
    news:455b82a0$0$7054$...
    > John Machin wrote:
    >
    >> Here in Austraila, (I expect this is common to most countries), there
    >> are people who are utterly clueless about elementary data model rules,
    >> like identification "numbers" should be kept as strings.

    >
    > Do you mean that ID numbers that serve as a primary key in a database
    > should also be strings?


    If you mean user-entered data like social security, phone, account, part,
    or postal code 'numbers' -- as opposed to internal db-generated numbers
    that the user never sees -- this I would presume 'yes'.

    tjr
    Terry Reedy, Nov 15, 2006
    #8
  9. Fredrik Lundh

    Aahz Guest

    In article <455b82a0$0$7054$>,
    John Salerno <> wrote:
    >John Machin wrote:
    >>
    >> Here in Austraila, (I expect this is common to most countries), there
    >> are people who are utterly clueless about elementary data model rules,
    >> like identification "numbers" should be kept as strings.

    >
    >Do you mean that ID numbers that serve as a primary key in a database
    >should also be strings?


    Depends. If they are strictly internal, ints are fine. But if they
    interact with the outside world, they should be strings.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "In many ways, it's a dull language, borrowing solid old concepts from
    many other languages & styles: boring syntax, unsurprising semantics,
    few automatic coercions, etc etc. But that's one of the things I like
    about it." --Tim Peters on Python, 16 Sep 1993
    Aahz, Nov 15, 2006
    #9
  10. Fredrik Lundh

    John Machin Guest

    On 16/11/2006 8:57 AM, Terry Reedy wrote:
    > "John Salerno" <> wrote in message
    > news:455b82a0$0$7054$...
    >> John Machin wrote:
    >>
    >>> Here in Austraila, (I expect this is common to most countries), there
    >>> are people who are utterly clueless about elementary data model rules,
    >>> like identification "numbers" should be kept as strings.

    >> Do you mean that ID numbers that serve as a primary key in a database
    >> should also be strings?

    >
    > If you mean user-entered data like social security, phone, account, part,
    > or postal code 'numbers' -- as opposed to internal db-generated numbers
    > that the user never sees -- this I would presume 'yes'.
    >
    > tjr


    Clarification:

    A db-generated number like ROWID etc should be whatever the db makes it.

    An identification "number" like social security number etc should be a
    string, irrespective of (a) whether the user entered it or a script
    entered it and (b) whether it's a primary key, foreign key or no key at all.

    Some "numbers" contain characters outside [0-9]: e.g. ISBN (base 11, "X"
    means 10); Hong Kong ID card "number" (base 36 in some positions).

    Even if all bytes are in [0-9], a simple rule should be applied: Does it
    make sense to add or subtract such "numbers"? The answer with (SSN,
    phone number, account number, postal code) is no, so don't store it as a
    numeric type.

    Cheers,
    John
    John Machin, Nov 16, 2006
    #10
  11. "John Salerno" <> wrote:

    > John Machin wrote:
    >
    > > Here in Austraila, (I expect this is common to most countries), there
    > > are people who are utterly clueless about elementary data model rules,
    > > like identification "numbers" should be kept as strings.

    >
    > Do you mean that ID numbers that serve as a primary key in a database
    > should also be strings?


    Nothing wrong with doing that - its not as if you are going to arithmetic with
    them -
    adding my id to yours is generally not very useful...

    - Hendrik
    Hendrik van Rooyen, Nov 16, 2006
    #11
  12. Hendrik van Rooyen wrote:

    > Nothing wrong with doing that - its not as if you are going to arithmetic with
    > them - adding my id to yours is generally not very useful...


    internal rowid's are best treated as pointers, though. they're more
    like memory addresses than labels.

    (from a design perspective, it's not entirely obvious that it's a good
    idea to use rowid's to point *into* the database from the outside, but
    that's another story).

    </F>
    Fredrik Lundh, Nov 16, 2006
    #12
  13. Fredrik Lundh

    Steve Holden Guest

    Terry Reedy wrote:
    > "John Salerno" <> wrote in message
    > news:455b82a0$0$7054$...
    >> John Machin wrote:
    >>
    >>> Here in Austraila, (I expect this is common to most countries), there
    >>> are people who are utterly clueless about elementary data model rules,
    >>> like identification "numbers" should be kept as strings.

    >> Do you mean that ID numbers that serve as a primary key in a database
    >> should also be strings?

    >
    > If you mean user-entered data like social security, phone, account, part,
    > or postal code 'numbers' -- as opposed to internal db-generated numbers
    > that the user never sees -- this I would presume 'yes'.
    >

    The modern trend is to use such values as alternate keys, and to have
    all tables use an automatically-allocated integer (autoincrement,
    identity, sequence) field as the primary key.

    Unfortunately some applications are getting such large tables that a
    32-bit field is insufficient to enumerate all existing and deleted rows.
    Then you have to start keeping tables of unused primary keys.

    regards
    Steve
    --
    Steve Holden +44 150 684 7255 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://holdenweb.blogspot.com
    Recent Ramblings http://del.icio.us/steve.holden
    Steve Holden, Nov 16, 2006
    #13
  14. Fredrik Lundh

    Paul Rubin Guest

    Steve Holden <> writes:
    > Unfortunately some applications are getting such large tables that a
    > 32-bit field is insufficient to enumerate all existing and deleted
    > rows. Then you have to start keeping tables of unused primary keys.


    Please tell me that's not from some Kafka nightmare. They don't use
    64-bit ints?
    Paul Rubin, Nov 16, 2006
    #14
  15. Fredrik Lundh

    Steve Holden Guest

    Paul Rubin wrote:
    > Steve Holden <> writes:
    >> Unfortunately some applications are getting such large tables that a
    >> 32-bit field is insufficient to enumerate all existing and deleted
    >> rows. Then you have to start keeping tables of unused primary keys.

    >
    > Please tell me that's not from some Kafka nightmare. They don't use
    > 64-bit ints?


    I don't believe SQL Server , for example, yet supports 64-bit identity
    values. If it does, then the version that at least one Python user has
    in use certainly doesn't.

    regards
    Steve
    --
    Steve Holden +44 150 684 7255 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://holdenweb.blogspot.com
    Recent Ramblings http://del.icio.us/steve.holden
    Steve Holden, Nov 16, 2006
    #15
  16. At Thursday 16/11/2006 04:40, Fredrik Lundh wrote:

    >internal rowid's are best treated as pointers, though. they're more
    >like memory addresses than labels.
    >
    >(from a design perspective, it's not entirely obvious that it's a good
    >idea to use rowid's to point *into* the database from the outside, but
    >that's another story).


    You could consider them like id() in python - an identifier that,
    although it's in fact a pointer, should not be dereferenced.


    --
    Gabriel Genellina
    Softlab SRL

    __________________________________________________
    Correo Yahoo!
    Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
    ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
    Gabriel Genellina, Nov 16, 2006
    #16
    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. bd
    Replies:
    0
    Views:
    624
  2. Ven
    Replies:
    3
    Views:
    1,323
  3. Gilbert Fine
    Replies:
    8
    Views:
    900
    Zentrader
    Aug 1, 2007
  4. Vitaliy
    Replies:
    1
    Views:
    474
    Peter Otten
    May 29, 2008
  5. Carsten Fuchs
    Replies:
    45
    Views:
    1,540
    James Kanze
    Oct 8, 2009
Loading...

Share This Page