Re: [Python-Dev] Python's C interface for types
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
[not sure what "And so it goes" means in English]
I apologise. I try to restrain myself from using excessive idiom, but sometimes I forget. It means "That is how things are, and there is and will be more of the same."
It may be a bit problematic to implement, but I think a clean specification is possible. If a and b are numbers, and a==b, then hash(a)==hash(b). I'm not sure whether "approximately 5.0" equals 5 or not: if it does, it should hash the same as 5, if it doesn't, it may or may not hash the same (whatever is easier to implement). For 0: hash(+0.0)==hash(-0.0)==hash(0)=hash(0L)=0
Unfortunately, that assumes that equality is transitive. With the advanced floating-point models, it may not be. For example, if you want to avoid the loss of error information, exact infinity and approximate infinity (the result of overflow) have different semantics. Similarly with infinitesimals. Even at present, Python's float (Decimal probably more so) doesn't allow you to do some things that are quite reasonable. For example, let us say that I am implementing a special function and want to distinguish -0.0 and +0.0. Why can't I use a dictionary?
a = float("+0.0") b = float("-0.0") print a, b 0.0 -0.0 c = {a: "+0.0", b: "-0.0"} print c[a], c[b] -0.0 -0.0
Well, we all know why. But it is not what some quite reasonable programmers will expect. And Decimal (with its cohorts and variant precisions) has this problem quite badly - as do I. No, I don't have an answer. You are damned if you do, and damned if you don't. It is an insoluble problem, and CURRENTLY doesn't justify two hashing mechanisms (i.e. ANY difference and EQUALITY difference). Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679
participants (1)
-
Nick Maclaren