469,963 Members | 2,138 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,963 developers. It's quick & easy.

Decimal vs Float comparasion

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 99999
False
>>a 99999.0
True

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 forbidden, like arithmatic operations between the
two types.

--
Hong Yuan

大管家网上建材超市
装修装潢建材一站式购物
http://www.homemaster.cn
Jun 27 '08 #1
4 1355
I still don't see why such a module exists.

On 5 mayo, 21:52, "Yuan HOng" <hongyuan1...@gmail.comwrote:
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 99999
False
>a 99999.0

True

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 forbidden, like arithmatic operations between the
two types.

--
Hong Yuan

大管家网上建材超市
装修装潢建材一站式购物http://www.homemaster.cn
Jun 27 '08 #2
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.
Jun 27 '08 #3
Dennis Lee Bieber wrote:
On Tue, 6 May 2008 11:52:10 +0800, "Yuan HOng" <ho**********@gmail.com>
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 forbidden, like arithmatic operations between the
two types.

Why should decimal be coerced to float? Maybe float should be
coerced to decimal?

Or... the programmer should explicitly specify what comparison is
wanted -- if any...

Or... Isn't Python 3.x supposed to forbid mixed type comparisons
unless the types implement suitable handling?
Bottom line is that it shouldn't silently return something insane.
99999.0 is surely exactly representable in any modern floating point
system, being a floating point representing of an integer, so silently
returning a completely invalid comparison is a tremendously bad idea.

It's a bug.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
Can I walk with you / 'Till the day that the world stops turning
-- India Arie
Jun 27 '08 #4
On May 6, 1:31 am, Dennis Lee Bieber <wlfr...@ix.netcom.comwrote:
On Tue, 6 May 2008 11:52:10 +0800, "Yuan HOng" <hongyuan1...@gmail.com>
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 forbidden, like arithmatic operations between the
two types.

Why should decimal be coerced to float? Maybe float should be
coerced to decimal?

Or... the programmer should explicitly specify what comparison is
wanted -- if any...

Or... Isn't Python 3.x supposed to forbid mixed type comparisons
unless the types implement suitable handling?
Yes, it is fixed in 3.0. Unfortunately it's well established
behaviour in 2.x, so it won't be changing there. Don't bother
reporting a bug about this unless it's about 3.0.
Jun 27 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

21 posts views Thread by Batista, Facundo | last post: by
reply views Thread by Batista, Facundo | last post: by
3 posts views Thread by jbauer | last post: by
15 posts views Thread by Kay Schluehr | last post: by
18 posts views Thread by Kuljit | last post: by
25 posts views Thread by Lennart Benschop | last post: by
reply views Thread by Wojciech Walczak | last post: by
17 posts views Thread by D'Arcy J.M. Cain | last post: by
6 posts views Thread by Terry Reedy | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.