On Wed, 4 Apr 2001, Christoph Rippel wrote: > Since C's double has the unique constants +/- Infinity and NaN you > need to guarantee that > 1/0.0 == 1/0.0, 1/-0.0 == 1/-0.0,( 1/0.0) * 0 == (1/0.0) * 0 (== NaN) > otherwise you would break this pattern. Anthing else would make the > special value logic essentially unusable IMO. But IMHO special value logic *has* to be essentially unusable. It's for handling of overflow exceptions without using proper Exceptions. Beyond simply producing such values you shouldn't do anything. > This is not really relevant here but I sort believe that at least one > of Ruby's equal methods should have been a class method - something like > Float.identical?(1, 1.0) # => true > This would have eliminated the problematic asymmetry of methods receiver > versus method argument and it makes generally more sense anyway - the only > reason against this are the extra key strokes. The other only reason to that is that you'd be breaking polymorphism by specifying "Float" yourself when the type of the operation can already be found by examining the arguments. > > this should return -1 since although +Infinity is not a precise number, it > > is greater than all other finite values and -Infinity. (it is however > > noncomparable to itself and to NaN) > I don't believe that this is such a good idea - you would get > 10**400 + 10**400 > 1.0 + 10**400 # => false No, you need not get that. Such an operation *could* return false to indicate that it's not greater than, but it could also return nil to indicate that it's not comparable at all, and current Ruby is certainly more radical than that: #<FloatDomainError: (eval):1:in `<=>': Infinity> You cannot make Ruby honestly return true for that expression, because once the right hand expression has been rounded upwards to infinity, you've lost the needed information about how big it really was. I think overall the current Ruby behaviour (of throwing Exception) is more safe than returning anything. > since 1.0 + 10**400 is equal to Floats Infinity but the left hand side is > still an ordinary Bignum which amounts to the mathematical equivalent > of a containment breach during a nuclear reactor melt-down. You get an OVERFLOW... That is the computing equivalent of I'm Looking For Trouble. Now for a demo of how Infinity should not equal Infinity, consider the current behaviour: 10**400 * 1.0 == 10**400 * 2.0 #=> true > I attached something below - the reason for calling them +/- nil is that > they could be the return values of [].min, [].man etc. which currently > return nil and if +/- Infinity would act as logical false values you > probably would not break any existing script. I'd like to avoid any kind of confusion with the real nil, which is not a number, and not even a NaN. I mean, it's not an instance of Numeric. Especially because +nil==nil right now, and -nil says NilClass#-@ not defined. Btw I'd like Infinity and NaN to have symbols, maybe. (so that they become serializer-friendly) > > Do you think Rational should be fixed to act, ehm, more rationally? > Don't know - the current behavior also breaks theoretical stuff like > integral or field extension of the Integer Class by ``adding sqrt(2)'' Well, it seems that all that Math.sqrt(Rational.new(2,1)) and Rational.new(2,1)**.5 do is convert to Float and do the operation on a Float, or the equivalent thereof. Do you mean that it's breaking the rule that operations on operands of a type should give a result of the same type? like 3/2 gives an Integer, 1. However, some operations on Integer and/or Rational args give Floats, and even some operations on Floats give Complex arguments -- and only if "require 'complex'" has been seen in that program. > To beat a dead horse of mine what Ruby is really missing is support for > Modules (and consequently Classes) parameterized by Module constant > with a instantiation logic. could you give a precise example and show what is missing in Ruby that prevents you from implementing that feature in Ruby? matju