[Michael B. Trausch]
>> Let's say that I want to work with the latitude 33.6907570. In Python,
>> that number > can not be stored exactly without the aid of
>> decimal.Decimal().
>>
>> >>> 33.6907570
>> 33.6907568
>> >>>
>>
>> As you can see, it loses accuracy after the 6th decimal place.
Robert Kern wrote:
> Fredrik Lundh wrote:
>> Terry Reedy wrote:
>>
>>> This is far more accurate than any measured latitude could be.
>> you're saying that we don't measure geographical positions on an atomic
>> scale? ;-)
>>
>> (it's too late for serious calculations, but I'd guess we're talking
Fredrik Lundh wrote:
> Terry Reedy wrote:
>
>> This is far more accurate than any measured latitude could be.
>
> you're saying that we don't measure geographical positions on an atomic
> scale? ;-)
>
> (it's too late for serious calculations, but I'd guess we're talking
> Ångströms here, righ
Terry Reedy wrote:
> This is far more accurate than any measured latitude could be.
you're saying that we don't measure geographical positions on an atomic
scale? ;-)
(it's too late for serious calculations, but I'd guess we're talking
Ångströms here, right?)
--
http://mail.python.org/mail
"Michael B. Trausch" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Let's say that I want to work with the latitude 33.6907570. In Python,
> that number > can not be stored exactly without the aid of
> decimal.Decimal().
> >>> 33.6907570
> 33.6907568
> >>>
> As you can
Michael B. Trausch wrote:
> On Fri, 2006-11-17 at 21:25 +0100, Fredrik Lundh wrote:
>> > Some of the lat/long pairs that I have used seem to come out fine, but
>> > some do not. Because the mathmatics used with them involve complex
>> > equations when determining distance and the like, any error
Michael B. Trausch wrote:
> Sure, I do. Let's say that I want to work with the latitude
> 33.6907570. In Python, that number can not be stored exactly without
> the aid of decimal.Decimal().
>
> >>> 33.6907570
> 33.6907568
> >>>
>
> As you can see, it loses accuracy after the 6th d
On Fri, 2006-11-17 at 16:51 -0500, Michael B. Trausch wrote:
> On Fri, 2006-11-17 at 21:25 +0100, Fredrik Lundh wrote:
> > > Some of the lat/long pairs that I have used seem to come out fine, but
> > > some do not. Because the mathmatics used with them involve complex
> > > equations when deter
Michael B. Trausch wrote:
> Perhaps you should not make assumptions; I am sure that you have heard
> what they do at some point before. While *some* of the error doesn't
> propagate as expected (which is actually a problem in itself—equations
> no longer make sense if they are not mathematically b
On Fri, 2006-11-17 at 16:51 -0500, Michael B. Trausch wrote:
> [...]
> Let's say that I want to work with the latitude 33.6907570. In
> Python, that number can not be stored exactly without the aid of
> decimal.Decimal().
>
> >>> 33.6907570
> 33.6907568
You say that like it's Python's fa
On Fri, 2006-11-17 at 21:25 +0100, Fredrik Lundh wrote:
> > Some of the lat/long pairs that I have used seem to come out fine, but
> > some do not. Because the mathmatics used with them involve complex
> > equations when determining distance and the like, any error gets
> > massively compounde
Michael B. Trausch wrote:
> I don't have (so far as I know) a 64-bit float available to me.
as mentioned in the documentation, Python's "float" datatype is
implemented C doubles, which is 64-bit IEEE on all major platforms.
> Some of the lat/long pairs that I have used seem to come out fine, bu
Michael B. Trausch wrote:
> I don't have (so far as I know) a 64-bit float available to me.
Yes, you do: the regular Python float type.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as th
-point but it
> > certainly wouldn't be trivial: consider the use of C language libraries
> > that know nothing of Python's decimal representation.
>
> judging from the various decimal FAQ:s, I think it's a bit naive to
> think that using Decimal instead
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, bu
Paul Rubin wrote:
> Steve Holden <[EMAIL PROTECTED]> 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'
Steve Holden <[EMAIL PROTECTED]> 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 night
Terry Reedy wrote:
> "John Salerno" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> 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 "n
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 perspe
"John Salerno" <[EMAIL PROTECTED]> 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 I
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> .. and seriously, under-
> standing the various aspects of floats and decimals is utterly trivial
> compared to all the nearly-magical things you need to understand to be
> able to do geographical calculations at a sub-millimeter scale. heck,
>
On 16/11/2006 8:57 AM, Terry Reedy wrote:
> "John Salerno" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> 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,
>>>
In article <[EMAIL PROTECTED]>,
John Salerno <[EMAIL PROTECTED]> 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 strin
"John Salerno" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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 s
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
sho
; that know nothing of Python's decimal representation.
judging from the various decimal FAQ:s, I think it's a bit naive to
think that using Decimal instead of float would somehow make everything
"just work":
http://www2.hursley.ibm.com/decimal/decifaq.html
http://effbot.org/
Michael B. Trausch wrote:
> On Mon, 2006-11-13 at 03:45 -0600, Steve Holden wrote:
>> Michael B. Trausch wrote:
>> > Is there a way to use Decimal() by default in Python instead of float?
>>
>> No. You'll just have to be explicit.
>>
>
> That's kinda what I figured. :-(
>
> It /would/ be nice
Michael B. Trausch wrote:
> Is there a way to use Decimal() by default in Python instead of float?
No. You'll just have to be explicit.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://hol
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.
--
http://mail.python.org/ma
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
"Steven D'Aprano" <[EMAIL PROTECTED]> 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.00
> Brun
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
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
> righ
Is there a way to use Decimal() by default in Python instead of float? I've no use for the float type, and I have some stuff that would require Decimal(), but it is kind of a pain to try and cast things all over the place all the time. Float is just way too inexact for me.
I am searching aro
34 matches
Mail list logo
