On May 6, 1:31 am, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On Tue, 6 May 2008 11:52:10 +0800, "Yuan HOng" <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>
>
> > It seems to me that rather than allowing this to happen, comparasion
> > between the two should either be mad
Dennis Lee Bieber wrote:
On Tue, 6 May 2008 11:52:10 +0800, "Yuan HOng" <[EMAIL PROTECTED]>
declaimed the following in comp.lang.python:
It seems to me that rather than allowing this to happen, comparasion
between the two should either be made correct (by convertion decimal
to float e.g.) or f
Gasto wrote:
> I still don't see why such a module exists.
There are 2.0 types of programmers: those who always use floating point,
and those who know how to use them.
--
http://mail.python.org/mailman/listinfo/python-list
2008/5/6, Wojciech Walczak <[EMAIL PROTECTED]>:
> a > 9.0 returns True because NotImplemented > 9.0 returns True.
> a < 9.0 returns False because NotImplemented < 9.0 returns False.
Sorry, it should rather be:
Decimal('0.5') > 9.0 returns True because:
Decimal('0.5') > NotImplem
2008/5/6, Yuan HOng <[EMAIL PROTECTED]>:
> It seems decimal object will always be larger than float in
> comparasion, which goes against common sense:
>
> >>> from decimal import Decimal
> >>> a = Decimal('0.5')
> >>> a > 9
> False
> >>> a > 9.0
> True
>
> It seems to me that rathe
I still don't see why such a module exists.
On 5 mayo, 21:52, "Yuan HOng" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It seems decimal object will always be larger than float in
> comparasion, which goes against common sense:
>
> >>> from decimal import Decimal
> >>> a = Decimal('0.5')
> >>> a > 9
>
Hi,
It seems decimal object will always be larger than float in
comparasion, which goes against common sense:
>>> from decimal import Decimal
>>> a = Decimal('0.5')
>>> a > 9
False
>>> a > 9.0
True
It seems to me that rather than allowing this to happen, comparasion
between the two shoul
On Sat, 21 Jan 2006 14:28:20 +1100, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>On Fri, 20 Jan 2006 04:25:01 +, Bengt Richter wrote:
>
>> On Thu, 19 Jan 2006 12:16:22 +0100, =?ISO-8859-1?Q?Gerhard_H=E4ring?=
>> <[EMAIL PROTECTED]> wrote:
>> [...]
>>>
>>>floating points are always imprecise, s
Tim Peters wrote:
> [Kay Schluehr]
> > I concur and I wonder why CAS like e.g. Maple that represent floating
> > point numbers using two integers [1] are neither awkward to use nor
> > inefficient.
>
> My guess is that it's because you never timed the difference in Maple
> -- or, perhaps, that you
[Kay Schluehr]
> I concur and I wonder why CAS like e.g. Maple that represent floating
> point numbers using two integers [1] are neither awkward to use nor
> inefficient.
My guess is that it's because you never timed the difference in Maple
-- or, perhaps, that you did, but misinterpreted the res
Steven D'Aprano wrote:
> On Sat, 21 Jan 2006 03:48:26 +, Steve Holden wrote:
>
> > Steven D'Aprano wrote:
> >> On Fri, 20 Jan 2006 04:25:01 +, Bengt Richter wrote:
> >>
> >>
> >>>On Thu, 19 Jan 2006 12:16:22 +0100, =?ISO-8859-1?Q?Gerhard_H=E4ring?=
> >>><[EMAIL PROTECTED]> wrote:
> >>>[...
On Sat, 21 Jan 2006 03:48:26 +, Steve Holden wrote:
> Steven D'Aprano wrote:
>> On Fri, 20 Jan 2006 04:25:01 +, Bengt Richter wrote:
>>
>>
>>>On Thu, 19 Jan 2006 12:16:22 +0100, =?ISO-8859-1?Q?Gerhard_H=E4ring?=
>>><[EMAIL PROTECTED]> wrote:
>>>[...]
>>>
floating points are always i
Steven D'Aprano wrote:
> On Fri, 20 Jan 2006 04:25:01 +, Bengt Richter wrote:
>
>
>>On Thu, 19 Jan 2006 12:16:22 +0100, =?ISO-8859-1?Q?Gerhard_H=E4ring?= <[EMAIL
>>PROTECTED]> wrote:
>>[...]
>>
>>>floating points are always imprecise, so you wouldn't want them as an
>>
>>Please, floating po
On Fri, 20 Jan 2006 04:25:01 +, Bengt Richter wrote:
> On Thu, 19 Jan 2006 12:16:22 +0100, =?ISO-8859-1?Q?Gerhard_H=E4ring?= <[EMAIL
> PROTECTED]> wrote:
> [...]
>>
>>floating points are always imprecise, so you wouldn't want them as an
> Please, floating point is not "always imprecise." In
On Thu, 19 Jan 2006 12:16:22 +0100, =?ISO-8859-1?Q?Gerhard_H=E4ring?= <[EMAIL
PROTECTED]> wrote:
[...]
>
>floating points are always imprecise, so you wouldn't want them as an
Please, floating point is not "always imprecise." In a double there are
64 bits, and most patterns represent exact ration
Fredrik Lundh wrote:
str(1.1)
>
> '1.1'
>
repr(1.1)
>
> '1.1001'
To add to the confusion:
>>> str(1.1001)
'1.1'
>>> repr(1.1001)
'1.1001'
Floating point numbers are not precise.
Decimals are, so they require precise
information when th
[Kay Schluehr]
>> This is interesting. If we define
>>
>> def f():
>>print str(1.1)
>>
>> and disassemble the function, we get:
>>
> dis.dis(f)
> 2 0 LOAD_GLOBAL 0 (str)
> 3 LOAD_CONST 1 (1.1001) # huh?
[Fredrik Lundh]
> huh h
Kay Schluehr wrote:
> This is interesting. If we define
>
> def f():
>print str(1.1)
>
> and disassemble the function, we get:
>
> dis.dis(f)
> 2 0 LOAD_GLOBAL 0 (str)
> 3 LOAD_CONST 1 (1.1001) # huh?
huh huh?
>>> str(1.1)
'
Kay Schluehr wrote:
> Steve Holden wrote:
>
>>>If Mr. interpreter is as slick as he is why doesn't he convert the
>>>float by himself? This is at most a warning caused by possible rounding
>>>errors of float.
>>>
>>
>>Indeed, as the documentation says: """This serves as an explicit
>>reminder of t
Steve Holden wrote:
> > If Mr. interpreter is as slick as he is why doesn't he convert the
> > float by himself? This is at most a warning caused by possible rounding
> > errors of float.
> >
> Indeed, as the documentation says: """This serves as an explicit
> reminder of the details of the conver
Kay Schluehr wrote:
> I wonder why this expression works:
>
>
decimal.Decimal("5.5")**1024
>
> Decimal("1.353299876254915295189966576E+758")
>
> but this one causes an error
>
> 5.5**1024
>
> Traceback (most recent call last):
> File "", line 1, in ?
> OverflowError: (34, 'Result too la
Kay Schluehr wrote:
> I wonder why this expression works:
>
decimal.Decimal("5.5")**1024
>
> Decimal("1.353299876254915295189966576E+758")
The result is a Decimal type, which can have *very high* values.
> but this one causes an error
>
> 5.5**1024
>
> Traceback (most recent call last):
>
I wonder why this expression works:
>>> decimal.Decimal("5.5")**1024
Decimal("1.353299876254915295189966576E+758")
but this one causes an error
5.5**1024
Traceback (most recent call last):
File "", line 1, in ?
OverflowError: (34, 'Result too large')
Another quirk is the follwoing:
>>> deci
23 matches
Mail list logo
