Op 2005-12-15, Grant Edwards schreef <[EMAIL PROTECTED]>: > On 2005-12-15, Antoon Pardon <[EMAIL PROTECTED]> wrote: > >>> Well, in my case, a given name (or return value) is always >>> bound to a floating point object. I don't test the type of the >>> object and treat it in two different ways depending on what >>> type it is. It's just a float. >> >> Do you find that difference so important? > > Possibly. In my case, a float is always a float. You can > always do the same set of operations on it. > >> As far as I understand >> the gtk identifiers are always positive integers. So I could >> have coded as follows: >> >> UnConnected = (-1, -2) >> Registered, UnRegistered = UnConnected > > In your case, there isn't a single set of operations that work > regardles of the value. You have to _check_ the value in order > to decide what operations are allowed on that value. I'm not > saying the latter is "evil" but I think the distinction is > important. > >> ... >> >> if self.cb_src in UnConnected: >> >> Now all values are integers and I no longer treat an object different >> depending on type but on value. However conceptually nothing changed. >> My code branches depending on set membership of this attribute. >> >> Could you explain why it should make a (big) difference between >> these two approaches? > > Your examples are still both very different from the NaN > example. A NaN is a floating point operation that supports all > the same operations as all other floating point operations. In > your example an integer object of -2 does not support the same > "operations" that a "real" GTK identifier does. They are two > different types.
I think the disctinction you are making is based on which level you look at things. For you floats are something you use, you see NaN as just a floats because the details of implementation have been abstracted out for you. But look at it from the level of someone who has to implement floating point numbers. He can't just take two floats and put them into his general add_float algorithm. If he did that the result of working with a NaN could result in a regular number. So he has to test for special values like NaN is his 'code' too. Of course we tend to forget this because in this case the abstraction is usually done at the hardware level. But I don't think that is such an important disctinction here. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
