Re: a few thoughts for ruby...

>> Roger Pack
>>
>> Thought I'd pass these thoughts by the readers here before sending them
>> to core.  They're my current wish list :)
>>
>> 1) add an Object#in? method to complement the existing Array#include?

> Joel VanderWerf
>
> It's not really symmetrical. Array has an #include? method because it is
> a collection. Object has #in? because it is--what? A potential member of
> a collection?

> Robert Klemme
>
> I don't see the benefit but I'm also not strongly against.  I do see
> Joel's point about the reversion.  Basically it is strange that every
> object should be able to answer a question that only the collection can
> answer.  Plus, you can easily add it yourself if you need it.

Sometimes the best (or better) usage depends on the context.
For example, on some occasions we use:  Integer === object
and on other occasions we use:          object.kind_of?( Integer )
So I'm not against this on principle, and for me the question is
what is the balance between not adding things unless we need to
and does this make things easier in a significant number of cases.
I don't know the answer!


>> Roger Pack
>> 4) (this one's controversial) remove the extra # for code in strings
>> (i.e. "string#{code}") -> "string{code}" less typing.

I'm not in favour, for Robert Klemme's reasons.


>>> Roger Pack
>>>
>>> 5) add a BigDecimal(float) method.
>>>  -> BigDecimal.new("%f" % float)

>> Robert Klemme
>>
>> Seems reasonable at first sight but the absence might have a reason.
>> For example, by making the conversion to String explicit it is more
>> obvious that float and BigDecimal are not really compatible.

> Roger Pack
>
> Yeah I wonder that myself. I was just hoping to make it easier to use
> BigDecimal, since Floats are so imprecise to use for decimal numbers :)

Then probably best to start with BigDecimal and keep using it?
We can always use  BD = BigDecimal ; BD.new( "123.456" )
and I seem to recall that there's a way to assign a method to a variable
which could reduce this to BD( "123.456" ). I think it's important
to normally use strings to get BigDecimal values to avoid precision errors.

Robert Klemme makes a good point: Float has less precision than BigDecimal
and in general I think that you should be *very* wary about converting
from lower precision to higher precision - at least not without being
fully aware of what you are doing - because later on you may be mislead
into thinking that your calculation is more accurate than it actually is.
(See "Here's one I made earlier" below.)

You can't gain precision by such a conversion, which is why my start
position is not to do it. That said, converting Float to BigDecimal
may sometimes be useful when it can prevent further loss of precision.
For example, ( float_a - float_b ) can reduce the accuracy drastically,
and conversion to BigDecimal might be useful there.
 ( Caveat: Numerical Analysis - study of ... - can be extremely tricky,
   and I only know enough about it to know that:
   1. I don't understand it sufficiently to make definitive statements.
   2. In my own stuff I probably ignore it more than I should. )

So I am against easy conversion by using something like BigDecimal( float ).
I think any standard conversion method from Float to BigDecimal
should be relatively ugly and messy. I did tbink of suggesting a rather long
method name, maybe BigDecimal.do_you_really_want_to_convert_this_float(fnum)
but someone can always alias that to a much shorter name.

If you  require "bigdecimal/util"  this does, amongst other things:
# BigDecimal utility library. ... The following methods are provided
# to convert other types to BigDecimals: ...
class Float < Numeric
  def to_d
    BigDecimal(self.to_s)
  end
end

So you can require that library, or just use  BigDecimal( float.to_s ),
I think  BigDecimal( float.to_s )  satisfies my general thought here
that whatever the conversion method used is, it shouldn't be so simple
that you can use it without being in some way being reminded
that what you are doing might not be a good idea.
So making it sort of ugly fits in with that.
(In fact, I'm not sure that having a Float#to_d method is a good idea.)

Doing a quick bit of testing suggested that using  "%f" % float
might be better than using float.to_s because in some cases
the former preserves information that is actually in the float
which the latter uses. In fact, I was going to suggest you propose
to use  "%f" % self  in Float#to_d instead of  self.to_s.
But after some more thought and a bit of testing, I found that
for me in IRB  "%f" % float  only gives results to 6 decimal places
but  float.to_s  seems to give results to 14 or 15 significant figures
so overall using  float.to_s  for the conversion seems better.

If we want a BigDecimal method (and in view of  BigDecimal( float.to_s )
I don't think we do - but  BigDecimal( float.to_s )  should perhaps
be mentioned prominently in BigDecimal documentation)
how about something like (not tested):
  def BigDecimal.from_f( f )
    if f.kind_of?( Float ) then BigDecimal( f.to_s )
    else raise "BigDecimal.from_f: argument must be a Float"
    end
  end

An argument for this is that by providing it you give a reasonably
simple standard way to do it which might reduce potentially
problematic "build your own" solutions.
(I'm not against "build your own" in principle: at the least
 it can be a useful way to find out how things work,
 and it may result in an improvement, and as long as it's
 your own time and your own decision to do it, why not?
 But where there are hidden pitfalls, a reliable and
 reasonably easy to use solution is a good idea.)


***** For those who want to know a bit more *****

*** Here's one I made earlier. ***

(Really! Two days ago, in fact. For those not in the UK the reference
 is to a long-running BBC television programme for children:
   http://en.wikipedia.org/wiki/Blue_peter
   ... The show is also famous for its "makes", which are demonstrations
   of how to construct a useful object or prepare food. These have given rise
   to the oft-used phrase "Here's one I made earlier", as presenters bring out
   a perfect and completed version of the object they are making. ...
 Well, one thing we try to do in Ruby is make (almost) perfect objects! )

I'm looking (for my own purposes) at the various Numeric classes,
and I think it's useful to consider them in terms of precision
potentially being lost on conversion and how we should cope with that.

(I'm using Microsoft Windows Vista (*1): if the behaviour shown doesn't work,
 just increase n until it does! Admittedly this uses Integer not BigDecimal,
 but it shows the potential problems if precision is lost.)

irb

n = 53
i = 2 ** n           #=>  9007199254740992
ii = i + 1           #=>  9007199254740993
f = Float( i )       #=> 9.00719925474099e+015
ff = Float( ii )     #=> 9.00719925474099e+015
iii = Integer( ff )  #=>  9007199254740992
i  == ii    #=> false
i  == f     #=> true
ii == f     #=> true
f  == ff    #=> true
i  <=> ii   #=> -1
i  <=> f    #=> 0
ii <=> f    #=> 0

Colin Bartlett

(*1) Question: Why do you like Linux and BSD Unix so much?
               You've never used either of them.
     Answer:   No, but I have used Microsoft Windows.
with apologies to Karl Kraus http://en.wikipedia.org/wiki/Karl_Kraus