From: Nat Pryce Date: 2001-08-02T06:25:34+09:00 Subject: [ruby-talk:18995] Re: "Bang" versions of numerical methods on non-immediate values [was: Numbers classes.. Rational number? ] From: "Kent Dahl" > I mostly wanted to have it in Numeric to be consistent across all > numeric objects, and making it transparent for the user, for instance > when his variable goes from containing a fixnum to a bignum. But in > light of your feedback and the inconsistencies it would introduce, I'll > forget about fixnums for now. > > So, my secondary, trimmed version of the idea: > Add add! and friends for Bignum, Float (and Rational?) etc only, > forgetting about fixnums. > Then I could create one accumulator number before a loop using > induced_from: > > a = Float.induced_from(0) > (1...1000).each{ |i| a.add!( 1.0 ) } Wouldn't this cause awful confusion with aliasing? At the moment, numerics are value objects, not reference objects, which is the mormal mathematical way of thinking. Even when implemented as objects on the heap, numbers have value semantics. Code knows that passing a float into a function will not change that float. With your suggestion code will no longer be able to guarantee that passing a float to a method will not change the float, and, to ensure internal consistency, objects will have to clone any float instance variables when stored and when passed to other objects. This approach has become common in Java to avoid problems with mutable value objects defined by the standard libraries, as documented on: http://www.c2.com/cgi/wiki?ValueObject http://www.c2.com/cgi/wiki?ReferenceObject http://www.c2.com/cgi/wiki?ValueObjectsShouldBeImmutable > Basically what I'm looking for, is a way of using Float (and Bignum etc) > as close as possible to a double* in C, a wrapper to a value, ... How about writing a generic "out-parameter" object that holds a single replaceable value? Or even using a single-element array as an ugly work around (another Java trick)? > I'm not too fond of the number of babies Float objects make when they do math :-) The time complexity of GC algorithms is linear with the number of live objects, not the number of dead ones, so it should not make very much difference to the speed of the program unless you have very little memory. Cheers, Nat.