Rails - Dec 2010 - Weird issue with converting floats to integer

Any idea why this calculates the integer the way it does?

irb> ("291.15".to_f * 100.0).to_i
=> 29114

Thanks,
Tom

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

TomRossi7 wrote in post #970207:
> Any idea why this calculates the integer the way it does?
>
> irb> ("291.15".to_f * 100.0).to_i
> => 29114
Because of the vagaries of floating-point arithmetic:
irb> ("291.15".to_f * 100.0) < 29115
=> true
irb> printf "%.30f", ("291.15".to_f * 100.0)
29114.999999999996362021192908287048

It bears repeating: never, ever use Floats for arithmetic.  If you
can''t
use fixed-point math, then use BigDecimal.
>
> Thanks,
> Tom
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Or just change the way you calculate to get at the level of accuracy
that you want/need:

irb> ("291.15".to_f * 1000.0).to_i/10
=> 29115

Jeff

On Dec 22, 7:41 pm, Marnen Laibow-Koser
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> TomRossi7 wrote in post #970207:
>
> > Any idea why this calculates the integer the way it does?
>
> > irb> ("291.15".to_f * 100.0).to_i
> > => 29114
>
> Because of the vagaries of floating-point arithmetic:
> irb> ("291.15".to_f * 100.0) < 29115
> => true
> irb> printf "%.30f", ("291.15".to_f * 100.0)
> 29114.999999999996362021192908287048
>
> It bears repeating: never, ever use Floats for arithmetic.  If you
can''t
> use fixed-point math, then use BigDecimal.
>
>
>
> > Thanks,
> > Tom
>
> Best,
> --
> Marnen Laibow-Koserhttp://www.marnen.org
> mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
>
> --
> Posted viahttp://www.ruby-forum.com/.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Please quote when replying.

Jeff Burlysystems wrote in post #970344:
> Or just change the way you calculate to get at the level of accuracy
> that you want/need:
>
> irb> ("291.15".to_f * 1000.0).to_i/10
> => 29115
That''s incredibly silly IMHO.  Besides, it will not always be the same 
for all values, will it?  I think BigDecimal is the right answer here.
>
> Jeff
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

I have currency information that I plan to store as an integer --
ironically to avoid issues like this.  The user input will always be
in a decimal form.  I''m thinking I will just do this
(''291.15''.to_f *
100).round instead.  That should round out any of the weird float
issues.

On Dec 23, 12:51 pm, Marnen Laibow-Koser
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> Please quote when replying.
>
> Jeff Burlysystems wrote in post #970344:
>
> > Or just change the way you calculate to get at the level of accuracy
> > that you want/need:
>
> > irb> ("291.15".to_f * 1000.0).to_i/10
> > => 29115
>
> That''s incredibly silly IMHO.  Besides, it will not always be the
same
> for all values, will it?  I think BigDecimal is the right answer here.
>
>
>
> > Jeff
>
> Best,
> --
> Marnen Laibow-Koserhttp://www.marnen.org
> mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
>
> --
> Posted viahttp://www.ruby-forum.com/.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Please quote when replying.

TomRossi7 wrote in post #970346:
> I have currency information that I plan to store as an integer --
> ironically to avoid issues like this.  The user input will always be
> in a decimal form.  I''m thinking I will just do this
(''291.15''.to_f *
> 100).round instead.  That should round out any of the weird float
> issues.
I think there are better ways of doing that -- such as using a DECIMAL 
field in the database.  Then no conversion is necessary and the data is 
stored as fixed-point.

Or, if you''d rather store the data as an integral number of pennies 
(though that may have i18n issues -- there are a few currencies, such as 
the Kuwaiti dinar, that are subdivided into 1000, not 100), then a quick 
way would be to normalize the string so that it contains 2 decimal 
places (so "123" would become "123.00"), then drop the
decimal point.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Dec 22, 10:34 pm, TomRossi7
<t...-5bxIUPmzHicFraO2wh7vUA@public.gmane.org>
wrote:
> Any idea why this calculates the integer the way it does?
>
> irb> ("291.15".to_f * 100.0).to_i
> => 29114
As Marnen''s already pointed out, the issue is that the result is a
*tiny* bit smaller than 29115, so to_i truncates off the entire
fractional part and gives the wrong answer. In general, if you want to
convert a decimal to an integer the way most people would on paper,
use .round.to_i, which will correctly round the float to the nearest
integer.

On the currency issue, it''s typically a good idea to avoid floating-
point throughout the process if you''re trying to get a reliable fixed-
point result. Decimal columns are definitely a good idea for this sort
of thing.

--Matt Jones

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

TomRossi7 wrote in post #970346:
> I have currency information that I plan to store as an integer --
> ironically to avoid issues like this.  The user input will always be
> in a decimal form.  I''m thinking I will just do this
(''291.15''.to_f *
> 100).round instead.  That should round out any of the weird float
> issues.
As was said before by others in this thread, using the BigDecimal type
really is the most reliable, and simple, solution. Don''t reinvent
the wheel with calculating in pennies and rounding etc. ...

In the migration, do this:

class AddAmountToPayment < ActiveRecord::Migration
  def self.up
    add_column :payments, :amount, :decimal, :precision => 12, :scale => 
2
  end
...

This which will work automatically correct when reading
user input in your forms and when doing internal calculations:

$ rails c
Loading development environment (Rails 3.0.3)
001:0> Payment.columns.select{|c| c.sql_type =~ /decimal/}
=> [#<ActiveRecord::ConnectionAdapters::MysqlColumn:0xb6c1e844 
@sql_type="decimal(12,2)", @scale=2, @name="amount",
@limit=12,
@precision=12, @primary=false, @type=:decimal, @default=nil, 
@null=true>]

002:0> payment = Payment.new(:amount => "291.15")
=> #<Payment id: nil, user_id: nil, testing: nil, created_at: nil, 
updated_at: nil, amount:
#<BigDecimal:b6c09318,''0.29115E3'',8(12)>>

003:0> payment.amount
=> #<BigDecimal:b6c07e14,''0.29115E3'',8(12)>

004:0> payment.amount.to_s
=> "291.15"

...

019:0> (payment.amount - BigDecimal("291") -
BigDecimal("0.15")).to_s
=> "0.0"
020:0> ((291.15 - 291) - 0.15).to_s
=> "-2.27318164292001e-14" # Rounding errors with float !!!

HTH,

Peter

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 23 December 2010 03:41, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> TomRossi7 wrote in post #970207:
>> Any idea why this calculates the integer the way it does?
>>
>> irb> ("291.15".to_f * 100.0).to_i
>> => 29114
>
> Because of the vagaries of floating-point arithmetic:
> irb> ("291.15".to_f * 100.0) < 29115
> => true
> irb> printf "%.30f", ("291.15".to_f * 100.0)
> 29114.999999999996362021192908287048
>
> It bears repeating: never, ever use Floats for arithmetic.  If you
can''t
> use fixed-point math, then use BigDecimal.
I have to disagree here.  I would rephrase it as _almost_ never use
Floats  The one time when they would be appropriate is if you have a
large amount of arithmetic to perform.  The sort of thing that might
occur in complex statistical analysis for example or engineering
calculations of some sort.  On most (possibly all) computers floating
point consumes vastly less processor time to perform than BigDecimal.
This is a rare occurence in Rails apps I expect so I agree that for
most people Marnen''s advice would be appropriate.

Colin

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Colin Law wrote in post #970376:
> On 23 December 2010 03:41, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
> wrote:
>> 29114.999999999996362021192908287048
>>
>> It bears repeating: never, ever use Floats for arithmetic. If you
can''t
>> use fixed-point math, then use BigDecimal.
>
> I have to disagree here.
I knew someone would. :)
>  I would rephrase it as _almost_ never use
> Floats  The one time when they would be appropriate is if you have a
> large amount of arithmetic to perform.  The sort of thing that might
> occur in complex statistical analysis for example or engineering
> calculations of some sort.  On most (possibly all) computers floating
> point consumes vastly less processor time to perform than BigDecimal.
Then use fixed-point math.  IEEE floats are 100% inappropriate for any 
sort of mathematical calculation.  And who cares how fast they are if 
they''re inaccurate?  Inaccurate engineering calculations are worse than
none at all -- do *you* want to drive over that bridge? :)

If you want to use IEEE floats for arithmetic, then the onus is on you 
to do the requisite numerical analysis to figure out how much error you 
are introducing, and to inform your users of that fact.
> This is a rare occurence in Rails apps
Yes indeed!
> I expect so I agree that for
> most people Marnen''s advice would be appropriate.
>
> Colin
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 23 December 2010 21:34, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> Colin Law wrote in post #970376:
>> On 23 December 2010 03:41, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
>> wrote:
>>> 29114.999999999996362021192908287048
>>>
>>> It bears repeating: never, ever use Floats for arithmetic. If you
can''t
>>> use fixed-point math, then use BigDecimal.
>>
>> I have to disagree here.
>
> I knew someone would. :)
You probably guessed it might be me :)
>
>>  I would rephrase it as _almost_ never use
>> Floats  The one time when they would be appropriate is if you have a
>> large amount of arithmetic to perform.  The sort of thing that might
>> occur in complex statistical analysis for example or engineering
>> calculations of some sort.  On most (possibly all) computers floating
>> point consumes vastly less processor time to perform than BigDecimal.
>
> Then use fixed-point math.  IEEE floats are 100% inappropriate for any
> sort of mathematical calculation.  And who cares how fast they are if
> they''re inaccurate?  Inaccurate engineering calculations are worse
than
> none at all -- do *you* want to drive over that bridge? :)
We are getting off topic for Rails apps but I think if you looked into
most engineering and scientific software you would find they use
floating point arithmetic.  Fixed point is not appropriate as
intermediate calculations need guaranteed _relative_ error, not
absolute error.  That is what floats provide.
> If you want to use IEEE floats for arithmetic, then the onus is on you
> to do the requisite numerical analysis to figure out how much error you
> are introducing, and to inform your users of that fact.
Yes of course.  As you said, the bridge designer needs to know the
possible errors in his calculations.

Colin

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Marnen Laibow-Koser wrote in post #970377:
> Then use fixed-point math.  IEEE floats are 100% inappropriate for any
> sort of mathematical calculation.  And who cares how fast they are if
> they''re inaccurate?  Inaccurate engineering calculations are worse
than
> none at all -- do *you* want to drive over that bridge? :)
Let''s break this down to a comparison of accuracy vs. precision.

Take for example the value 1/3.

First using floating point math:

x = 1.0
=> 1.0
y = 3.0
=> 3.0
z = x / y
=> 0.3333333333333333

Now with Ruby''s BigDecimal math:
x = BigDecimal.new(''1'')
=> #<BigDecimal:102c078,''0.1E1'',4(8)>
y = BigDecimal.new(''3'')
=> #<BigDecimal:10388f0,''0.3E1'',4(8)>
z = x / y
=> #<BigDecimal:103680c,''0.33333333E0'',8(16)>

In the case of float we have 16 decimal digits of precision, but in the 
case of BigDecimal we have only eight digits of precision.

Yes, in the case of BigDecimal we have a value representing
"precisely"
the value 0.33333333, but that result is obviously less accurate than 
the result of the floating point calculation.

Over large aggregations this can make a difference. It is certainly the 
case that IEEE floats introduce error due to the inherent storage 
limitations, but doing precise mathematics as fixed point has it''s own 
complications as well.

Ruby''s BigDecimal class does not provide the needed accuracy for
complex
mathematics. The difference is that BigDecimal always stores precise 
values within the limits of it storage space. Where floats store 
imprecise representations, but representations with a fixed precision.

I don''t think either of these classes are appropriate for the sort of 
math mentioned above. But, they both have their uses.

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Robert Walker wrote in post #970390:
> Marnen Laibow-Koser wrote in post #970377:
>> Then use fixed-point math.  IEEE floats are 100% inappropriate for any
>> sort of mathematical calculation.  And who cares how fast they are if
>> they''re inaccurate?  Inaccurate engineering calculations are
worse than
>> none at all -- do *you* want to drive over that bridge? :)
>
> Let''s break this down to a comparison of accuracy vs. precision.
>
> Take for example the value 1/3.
>
> First using floating point math:
>
> x = 1.0
> => 1.0
> y = 3.0
> => 3.0
> z = x / y
> => 0.3333333333333333
>
> Now with Ruby''s BigDecimal math:
> x = BigDecimal.new(''1'')
> => #<BigDecimal:102c078,''0.1E1'',4(8)>
> y = BigDecimal.new(''3'')
> => #<BigDecimal:10388f0,''0.3E1'',4(8)>
> z = x / y
> => #<BigDecimal:103680c,''0.33333333E0'',8(16)>
>
> In the case of float we have 16 decimal digits of precision, but in the
> case of BigDecimal we have only eight digits of precision.
Are you sure?  Or are only eight digits displayed?
>
> Yes, in the case of BigDecimal we have a value representing
"precisely"
> the value 0.33333333, but that result is obviously less accurate than
> the result of the floating point calculation.
Not obvious at all, since I don''t know how many 3s the BigDecimal is 
*actually* storing.
>
> Over large aggregations this can make a difference.
Yes, it certainly can.
> It is certainly the
> case that IEEE floats introduce error due to the inherent storage
> limitations, but doing precise mathematics as fixed point has it''s
own
> complications as well.
Sure.  BigDecimal is the best of both worlds.
>
> Ruby''s BigDecimal class does not provide the needed accuracy for
complex
> mathematics.
Of course it does.  Why do you think it does not?

Anyway, if you need more than BigDecimal, then start climbing into the 
realms of symbolic math with Rational.
> The difference is that BigDecimal always stores precise
> values within the limits of it storage space. Where floats store
> imprecise representations, but representations with a fixed precision.
>
> I don''t think either of these classes are appropriate for the sort
of
> math mentioned above.
Why is BigDecimal inappropriate?  What would you use instead?
> But, they both have their uses.
I''m not sure Float has a proper use case at all. :)

Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

Sent from my iPhone

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 24 December 2010 03:59, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> Robert Walker wrote in post #970390:
>> Marnen Laibow-Koser wrote in post #970377:
>>> Then use fixed-point math.  IEEE floats are 100% inappropriate for
any
>>> sort of mathematical calculation.  And who cares how fast they are
if
>>> they''re inaccurate?  Inaccurate engineering calculations
are worse than
>>> none at all -- do *you* want to drive over that bridge? :)
>>
>> Let''s break this down to a comparison of accuracy vs.
precision.
>>
>> Take for example the value 1/3.
>>
>> First using floating point math:
>>
>> x = 1.0
>> => 1.0
>> y = 3.0
>> => 3.0
>> z = x / y
>> => 0.3333333333333333
>>
>> Now with Ruby''s BigDecimal math:
>> x = BigDecimal.new(''1'')
>> => #<BigDecimal:102c078,''0.1E1'',4(8)>
>> y = BigDecimal.new(''3'')
>> => #<BigDecimal:10388f0,''0.3E1'',4(8)>
>> z = x / y
>> =>
#<BigDecimal:103680c,''0.33333333E0'',8(16)>
>>
>> In the case of float we have 16 decimal digits of precision, but in the
>> case of BigDecimal we have only eight digits of precision.
>
> Are you sure?  Or are only eight digits displayed?
$ rails console
Loading development environment (Rails 3.0.3)
ruby-1.9.2-p0 >
x=BigDecimal(''1'')/BigDecimal(''3'')
 => #<BigDecimal:ad823a4,''0.33333333E0'',8(16)>
ruby-1.9.2-p0 > x*BigDecimal(''3'')
 => #<BigDecimal:ad2b270,''0.99999999E0'',8(20)>
ruby-1.9.2-p0 > x*BigDecimal(''3'') == 1
 => false
ruby-1.9.2-p0 > x*BigDecimal(''3'') - 1
 => #<BigDecimal:aa4fdf8,''-0.1E-7'',4(20)>

Colin

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 24 December 2010 03:59, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> [...]
> I''m not sure Float has a proper use case at all. :)
Consider  table containing the masses of objects.  Columns description
and mass (kg), with the following records
apple, 0.2
earth, 5.9742E24
sun, 1.98892E30
super massive black hole, 1.0E39

What column type would be appropriate for storing the mass?

Colin

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Colin Law wrote in post #970449:
> On 24 December 2010 03:59, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
> wrote:
>> [...]
>> I''m not sure Float has a proper use case at all. :)
>
> Consider  table containing the masses of objects.  Columns description
> and mass (kg), with the following records
> apple, 0.2
> earth, 5.9742E24
> sun, 1.98892E30
> super massive black hole, 1.0E39
>
> What column type would be appropriate for storing the mass?
Irrelevant.  If I understand you correctly, you''re asking about DB 
column types, not Ruby column types.

Anyway, the answer is: it depends.  If I didn''t need arbitrary 
precision, I''d store them as floats in the DB, and then change to 
BigDecimal before doing any math on them.

If I did need arbitrary precision, and the DB didn''t provide a 
BigDecimal-like type, I''d store them as strings.
>
> Colin
Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

Sent from my iPhone

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Colin Law wrote in post #970447:
> On 24 December 2010 03:59, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
> wrote:
>>>
>>> x = BigDecimal.new(''1'')
>>> => #<BigDecimal:102c078,''0.1E1'',4(8)>
>>> y = BigDecimal.new(''3'')
>>> => #<BigDecimal:10388f0,''0.3E1'',4(8)>
>>> z = x / y
>>> =>
#<BigDecimal:103680c,''0.33333333E0'',8(16)>
>>>
>>> In the case of float we have 16 decimal digits of precision, but in
the
>>> case of BigDecimal we have only eight digits of precision.
>>
>> Are you sure? Or are only eight digits displayed?
>
> $ rails console
> Loading development environment (Rails 3.0.3)
> ruby-1.9.2-p0 >
x=BigDecimal(''1'')/BigDecimal(''3'')
>  => #<BigDecimal:ad823a4,''0.33333333E0'',8(16)>
> ruby-1.9.2-p0 > x*BigDecimal(''3'')
>  => #<BigDecimal:ad2b270,''0.99999999E0'',8(20)>
> ruby-1.9.2-p0 > x*BigDecimal(''3'') == 1
>  => false
> ruby-1.9.2-p0 > x*BigDecimal(''3'') - 1
>  => #<BigDecimal:aa4fdf8,''-0.1E-7'',4(20)>
>

Interesting.  However, the BigDecimal constructor allows specification 
of the minimum number of significant figures, so in this case we could 
have done BigDecimal.new(''1'', 16).
> Colin
Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

Sent from my iPhone

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 24 December 2010 14:25, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> Colin Law wrote in post #970447:
>> On 24 December 2010 03:59, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
>> wrote:
>>>>
>>>> x = BigDecimal.new(''1'')
>>>> =>
#<BigDecimal:102c078,''0.1E1'',4(8)>
>>>> y = BigDecimal.new(''3'')
>>>> =>
#<BigDecimal:10388f0,''0.3E1'',4(8)>
>>>> z = x / y
>>>> =>
#<BigDecimal:103680c,''0.33333333E0'',8(16)>
>>>>
>>>> In the case of float we have 16 decimal digits of precision,
but in the
>>>> case of BigDecimal we have only eight digits of precision.
>>>
>>> Are you sure? Or are only eight digits displayed?
>>
>> $ rails console
>> Loading development environment (Rails 3.0.3)
>> ruby-1.9.2-p0 >
x=BigDecimal(''1'')/BigDecimal(''3'')
>>  =>
#<BigDecimal:ad823a4,''0.33333333E0'',8(16)>
>> ruby-1.9.2-p0 > x*BigDecimal(''3'')
>>  =>
#<BigDecimal:ad2b270,''0.99999999E0'',8(20)>
>> ruby-1.9.2-p0 > x*BigDecimal(''3'') == 1
>>  => false
>> ruby-1.9.2-p0 > x*BigDecimal(''3'') - 1
>>  => #<BigDecimal:aa4fdf8,''-0.1E-7'',4(20)>
>>
>
>
> Interesting.  However, the BigDecimal constructor allows specification
> of the minimum number of significant figures, so in this case we could
> have done BigDecimal.new(''1'', 16).
ruby-1.9.2-p0 > x = BigDecimal.new(''1'',
16)/BigDecimal.new(''3'',16)
 => #<BigDecimal:a146bbc,''0.33333333E0'',8(16)>
ruby-1.9.2-p0 > x*BigDecimal(''3'',16) - 1
 => #<BigDecimal:a114acc,''-0.1E-7'',4(20)>

It doesn''t make any difference how many digits you have, 1/3 as a
decimal number multiplied by 3 will never be equal to 1.

I am not sure why the above still gives only 8 digits accuracy
however, I would have thought it aught to be 16.

Colin

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Dec 24, 2:21 pm, Marnen Laibow-Koser
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> Colin Law wrote in post #970449:
>
> If I did need arbitrary precision, and the DB didn''t provide a
> BigDecimal-like type, I''d store them as strings.
Which still doesn''t allow you to store all numbers with arbitrary
precision (in fact putting my mathematical hat on, most numbers can''t
be stored like this). You''ll have to deal with numerical error
eventually

Fred
>
>
>
> > Colin
>
> Best,
> -- 
> Marnen Laibow-Koserhttp://www.marnen.org
> mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
>
> Sent from my iPhone
>
> --
> Posted viahttp://www.ruby-forum.com/.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Colin Law wrote in post #970496:
> On 24 December 2010 14:25, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
> wrote:
>>>>>
>>> =>
#<BigDecimal:ad2b270,''0.99999999E0'',8(20)>
>>> ruby-1.9.2-p0 > x*BigDecimal(''3'') == 1
>>> => false
>>> ruby-1.9.2-p0 > x*BigDecimal(''3'') - 1
>>> => #<BigDecimal:aa4fdf8,''-0.1E-7'',4(20)>
>>>
>>
>>
>> Interesting. However, the BigDecimal constructor allows specification
>> of the minimum number of significant figures, so in this case we could
>> have done BigDecimal.new(''1'', 16).
>
> ruby-1.9.2-p0 > x = BigDecimal.new(''1'',
16)/BigDecimal.new(''3'',16)
>  => #<BigDecimal:a146bbc,''0.33333333E0'',8(16)>
> ruby-1.9.2-p0 > x*BigDecimal(''3'',16) - 1
>  => #<BigDecimal:a114acc,''-0.1E-7'',4(20)>
>
> It doesn''t make any difference how many digits you have, 1/3 as a
> decimal number multiplied by 3 will never be equal to 1.

I''m aware of that, of course.  In this particular case, we could use a 
Rational to fix that.  But that won''t necessarily work with arbitrary 
floating-point numbers...

...unless we recast them as Rationals and do all math that way.  Hmm.
>
> I am not sure why the above still gives only 8 digits accuracy
> however, I would have thought it aught to be 16.
Yeah, that''s peculiar.  I''ll have to run some tests.

(I can almost guarantee that Rubinius would get that one right, since I 
wrote most of the BigDecimal library at one time.  Don''t know if
they''re
still using it.)
>
> Colin
Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

Sent from my iPhone

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Dec 24, 2:39 pm, Frederick Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Dec 24, 2:21 pm, Marnen Laibow-Koser
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:
> Which still doesn''t allow you to store all numbers with arbitrary
> precision (in fact putting my mathematical hat on, most numbers
can''t
> be stored like this). You''ll have to deal with numerical error
> eventually
Talking slight bollocks. I meant that you can''t store with infinite
precision, ie you''ll always be liable for some error.

Fred
>
> Fred
>
>
>
>
>
> > > Colin
>
> > Best,
> > -- 
> > Marnen Laibow-Koserhttp://www.marnen.org
> > mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
>
> > Sent from my iPhone
>
> > --
> > Posted viahttp://www.ruby-forum.com/.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Frederick Cheung wrote in post #970500:
> On Dec 24, 2:39pm, Frederick Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
>> On Dec 24, 2:21pm, Marnen Laibow-Koser
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:
>
>> Which still doesn''t allow you to store all numbers with
arbitrary
>> precision (in fact putting my mathematical hat on, most numbers
can''t
>> be stored like this). You''ll have to deal with numerical error
>> eventually
>
> Talking slight bollocks. I meant that you can''t store with
infinite
> precision, ie you''ll always be liable for some error.
Of course.  You know a better way? Should we just store everything as 
Rational?
>
> Fred
Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

Sent from my iPhone

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Dec 24, 2:47 pm, Marnen Laibow-Koser
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> Frederick Cheung wrote in post #970500:
>
> > On Dec 24, 2:39pm, Frederick Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > wrote:
> >> On Dec 24, 2:21pm, Marnen Laibow-Koser
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:
>
> >> Which still doesn''t allow you to store all numbers with
arbitrary
> >> precision (in fact putting my mathematical hat on, most numbers
can''t
> >> be stored like this). You''ll have to deal with numerical
error
> >> eventually
>
> > Talking slight bollocks. I meant that you can''t store with
infinite
> > precision, ie you''ll always be liable for some error.
>
> Of course.  You know a better way? Should we just store everything as
> Rational?
>
Well that wouldn''t solve things anyway. Just didn''t wanted to
make
sure no one was under the illusion that there''s some sort of silver
bullet for this

Fred
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 24 December 2010 14:47, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> Frederick Cheung wrote in post #970500:
>> On Dec 24, 2:39pm, Frederick Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> wrote:
>>> On Dec 24, 2:21pm, Marnen Laibow-Koser
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:
>>
>>> Which still doesn''t allow you to store all numbers with
arbitrary
>>> precision (in fact putting my mathematical hat on, most numbers
can''t
>>> be stored like this). You''ll have to deal with numerical
error
>>> eventually
>>
>> Talking slight bollocks. I meant that you can''t store with
infinite
>> precision, ie you''ll always be liable for some error.
>
> Of course.  You know a better way? Should we just store everything as
> Rational?
For things that _are_ decimal numbers (such as money) use Fixed or
BigDecimal and for things that are not decimal then use Float and
determine the errors if it is important.

Colin

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Colin Law wrote in post #970510:
> On 24 December 2010 14:47, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
> wrote:
>>> Talking slight bollocks. I meant that you can''t store with
infinite
>>> precision, ie you''ll always be liable for some error.
>>
>> Of course. You know a better way? Should we just store everything as
>> Rational?
>
> For things that _are_ decimal numbers (such as money) use Fixed or
> BigDecimal and for things that are not decimal then use Float and
> determine the errors if it is important.
That''s basically what I''ve been saying, except for
"decimal" substitute
"rational".  However, there''s not always an a priori way to
determine if
a given field will need to store irrational numbers.
>
> Colin
Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

Sent from my iPhone

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 24 December 2010 16:36, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> Colin Law wrote in post #970510:
>> On 24 December 2010 14:47, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
>> wrote:
>>>> Talking slight bollocks. I meant that you can''t store
with infinite
>>>> precision, ie you''ll always be liable for some error.
>>>
>>> Of course. You know a better way? Should we just store everything
as
>>> Rational?
>>
>> For things that _are_ decimal numbers (such as money) use Fixed or
>> BigDecimal and for things that are not decimal then use Float and
>> determine the errors if it is important.
>
> That''s basically what I''ve been saying, except for
"decimal" substitute
> "rational".  However, there''s not always an a priori way
to determine if
> a given field will need to store irrational numbers.
I am not quite sure that is that is the same as "never, ever use
Floats for arithmetic" :)

Also as we have seen for rational numbers like 1/3 BigDecimal is no
better than float, except that it is possible to specify a smaller or
larger precision than that which float supplies, and it is a decimal
precision rather than a binary one.

Colin

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Colin Law wrote in post #970523:
> On 24 December 2010 16:36, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
> wrote:
>>> BigDecimal and for things that are not decimal then use Float and
>>> determine the errors if it is important.
>>
>> That''s basically what I''ve been saying, except for
"decimal" substitute
>> "rational". However, there''s not always an a priori
way to determine if
>> a given field will need to store irrational numbers.
>
> I am not quite sure that is that is the same as "never, ever use
> Floats for arithmetic" :)
Oh, now I see the difference.  Even if I store something as a Float,
I''d
probably use BigDecimal for arithmetic.  I simply don''t believe that 
Float arithmetic has any place at all in a wise programmer''s
repertoire.
Consider it the 21st-century goto, if you like. :)
>
> Also as we have seen for rational numbers like 1/3 BigDecimal is no
> better than float, except that it is possible to specify a smaller or
> larger precision than that which float supplies,
That makes it better than Float right there.  Also, you don''t
accumulate
any *more* error.
> and it is a decimal
> precision rather than a binary one.
...which is not generally better or worse.
>
> Colin
Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

Sent from my iPhone

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 24 December 2010 17:29, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> Colin Law wrote in post #970523:
>> On 24 December 2010 16:36, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
>> wrote:
>>>> BigDecimal and for things that are not decimal then use Float
and
>>>> determine the errors if it is important.
>>>
>>> That''s basically what I''ve been saying, except
for "decimal" substitute
>>> "rational". However, there''s not always an a
priori way to determine if
>>> a given field will need to store irrational numbers.
>>
>> I am not quite sure that is that is the same as "never, ever use
>> Floats for arithmetic" :)
>
> Oh, now I see the difference.  Even if I store something as a Float,
I''d
> probably use BigDecimal for arithmetic.  I simply don''t believe
that
> Float arithmetic has any place at all in a wise programmer''s
repertoire.
> Consider it the 21st-century goto, if you like. :)
>
>>
>> Also as we have seen for rational numbers like 1/3 BigDecimal is no
>> better than float, except that it is possible to specify a smaller or
>> larger precision than that which float supplies,
>
> That makes it better than Float right there.  Also, you don''t
accumulate
> any *more* error.
The more I think about it the more I think that the ruby
implementation of BigDecimal is flawed. BigDecimal(''1'') /
BigDecimal(''3'') should be stored as a rational (ie as two
values, 1
and 3 to be divided). Otherwise it seems to me that it is not
''proper''
BigDecimal.  I have been unable to find documentation that fully
defines what the result of 1/3 should be.

Colin

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Colin Law wrote in post #970536:
> The more I think about it the more I think that the ruby
> implementation of BigDecimal is flawed. BigDecimal(''1'') /
> BigDecimal(''3'') should be stored as a rational (ie as two
values, 1
> and 3 to be divided). Otherwise it seems to me that it is not
''proper''
> BigDecimal.  I have been unable to find documentation that fully
> defines what the result of 1/3 should be.
I think differently here (but I may be mistaken ...).

BigDecimal, for me, as the name implies, guarantees an "exact" 
representation of all numbers that are of the form:

[+-] (d(n)*10^n + d(n-1)*10^(n-1) + ... + d(0)*10^0 +  d(-1)*10^(-1) + 
... d(-m)*10^(-m))

with d(n), the digit n places to the left of unity and
d(-m), the digit m places to the right of the unit and the comma.
The ^ (caret) represents the "to the power of" function (e.g.
10^3 == 1000).

E.g. in the decimal number "3004.5006"
d(3) = 3
d(2) = 0
d(1) = 0
d(0) = 4
d(-1) = 5
d(-2) = 0
d(-3) = 0
d(-4) = 6
>> a = BigDecimal.new("3004.5006")
=> #<BigDecimal:b72706c0,''0.30045006E4'',8(12)>

These numbers form a (mathematical) field for the operators:
+, -, *  , but NOT with the division operator.

The nice thing about BigDecimal is that it will automatically
expand it''s precision if needed to make sure the representation remains
correct when using the functions: +, -, *. There is always a finite (and 
exact) precision that is sufficient to represent the result of

  a [+-*] b

Let''s try it:
>> a = BigDecimal.new("1000000000000000000",12)
=> #<BigDecimal:b725ae60,''0.1E19'',4(24)>
# (precision automatically larger than the 12 I requested)
>> b = BigDecimal.new("0.00000000000000003", 12)
=> #<BigDecimal:b72320b4,''0.3E-16'',4(24)>
# (precision automatically larger than the 12 I requested)
>> sum = a+b
=> #<BigDecimal:b722254c,''0.1000000000 0000000000 0000000000 
000003E19'',40(56)>
# nice, precision is enlarged to represent the _exact_ result :-)
>> difference = a-b
=> #<BigDecimal:b721ee9c,''0.9999999999 9999999999 9999999999 
99997E18'',40(56)>
# nice, precision is enlarged to represent the _exact_ result :-)
>> product = a*b
=> #<BigDecimal:b721c494,''0.3E2'',4(16)>
# nice, precision is reduced because more is not required :-)

But for the division ...
>> division = a/b
=> #<BigDecimal:b721aa7c,''0.3333333333 3333333333 3333333333
3333333333
3333333E35'',48(56)>
>> division = a/b
BigDecimal gives it a shot, takes a "large" precision ... but in a
"Decimal" representation (Sum of d(i).10^i), there is no way to
represent this exactly. So there is no limited value of precision
that will allow the exact representation. Otherwise said, the function
division ''/'' is not part of the field, it can produce results
that
are outside the set of decimals (even if the 2 operands are inside).

The Decimal numbers are clearly a subset of the Rational numbers.
It would be quite feasible to make a Rational class which is a field
with the operators ''+'', ''-'',
''*'', ''/''. Of course, the Rational class
exists and does this neatly:
>> ra = Rational(1000000000000000000000000000,1)
=> Rational(1000000000000000000000000000, 1)
>> rb = Rational(2,1000000000000000000000000000)
=> Rational(1, 500000000000000000000000000)
>> ra.to_s
=> "1000000000000000000000000000"
>> rb.to_s
=> "1/500000000000000000000000000"
>> (ra+rb).to_s
=> 
"500000000000000000000000000000000000000000000000000001/500000000000000000000000000"
>> (ra-rb).to_s
=> 
"499999999999999999999999999999999999999999999999999999/500000000000000000000000000"
>> (ra*rb).to_s
=> "2"
>> (ra/rb).to_s
=>
"500000000000000000000000000000000000000000000000000000"
>> (rb/ra).to_s
=>
"1/500000000000000000000000000000000000000000000000000000"
>> ra.inspect
=> "Rational(1000000000000000000000000000,
1)"
>> rb.inspect
=> "Rational(1, 500000000000000000000000000)"

But then again ... sin, sqrt, etc. are not part of the field and
will bring the result outside of the BigRational set into the
set of "Real" numbers.

My conclusion:
* on the *, +, - operators, it is nice to see BigDecimal
  expand the precision of the results to stick to an
  "exact" representation and stay in the field.
* if the BigDecimal class sticks to its definition of "Decimal"
  (and not Rational) then behavior of BigDecimal on the
  division operator can be nothing else then arbitrary.

Possible solutions I see on top of my head:
A do nothing (the result of division has a "large" precision,
  but is not "exact")
B raise an exception if the representation becomes not exact
C set an instance variable in the BigDecimal object that marks
  it is "not exact" (like the "tainted" flag)
D let BigDecimal return a Rational if the result can not be
  exactly represented as a BigDecimal
E use the Rational class if you want exact divisions
...

They all have their advantages:
* A OK. Understanding the behaviour is enough. I understand
    now that +.-,* work as expected and / causes the risk
    to loose exact representation.

* B (could be Class or per object flag)
==> in bookkeeping applications, exactness is required,
    so any calculation that destroys the exactness must
    be flagged. So if you calculate the "average" profit
    over your 7 divisions, you would get an exception,
    unless you did something special and understand the risks

* C this is really unintrusive and allows one to check at the
    end if the exactness did not get lost along the road

* E this exists, use it if you want an "exact" representation
    of 1/3.

I am not in favor of D because it silently changes the class
of the result and this violates the principle of least surprise.
If you want Rational, use it from the start then.

HTH,

Peter

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 25 December 2010 00:37, Peter Vandenabeele
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:
> Possible solutions I see on top of my head:
> A do nothing (the result of division has a "large" precision,
>  but is not "exact")
> B raise an exception if the representation becomes not exact
> C set an instance variable in the BigDecimal object that marks
>  it is "not exact" (like the "tainted" flag)
> D let BigDecimal return a Rational if the result can not be
>  exactly represented as a BigDecimal
> E use the Rational class if you want exact divisions
> ...
>
> They all have their advantages:
> * A OK. Understanding the behaviour is enough. I understand
>    now that +.-,* work as expected and / causes the risk
>    to loose exact representation.
>
> * B (could be Class or per object flag)
> ==> in bookkeeping applications, exactness is required,
>    so any calculation that destroys the exactness must
>    be flagged. So if you calculate the "average" profit
>    over your 7 divisions, you would get an exception,
>    unless you did something special and understand the risks
>
> * C this is really unintrusive and allows one to check at the
>    end if the exactness did not get lost along the road
>
> * E this exists, use it if you want an "exact" representation
>    of 1/3.
>
> I am not in favor of D because it silently changes the class
> of the result and this violates the principle of least surprise.
> If you want Rational, use it from the start then.
For D there is no reason why the class of the result needs to change
to Rational.  It could stay as BigDecimal but internally store the
data as a Rational.  Looking at Java BigDecimal it throws an exception
if the result of a division cannot be held exactly.

In summary however I think you are correct for Ruby.  BigDecimal will
retain full accuracy except for division, where it is up to the user
to make sure he/she understands what he is doing and ensures that
errors are understood.

Colin
>
> HTH,
>
> Peter
>
> --
> Posted via http://www.ruby-forum.com/.
>
> --
> You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Colin Law wrote in post #970616:
> On 25 December 2010 00:37, Peter Vandenabeele
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
> wrote:
...
>> I am not in favor of D because it silently changes the class
>> of the result and this violates the principle of least surprise.
>> If you want Rational, use it from the start then.
>
> For D there is no reason why the class of the result needs to change
> to Rational.  It could stay as BigDecimal but internally store the
> data as a Rational.
Ah, I see. I had not thought it that way.

Thanks,

Peter

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Peter Vandenabeele wrote in post #970618:
> Colin Law wrote in post #970616:
>> On 25 December 2010 00:37, Peter Vandenabeele
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
>> wrote:
> ...
>>> I am not in favor of D because it silently changes the class
>>> of the result and this violates the principle of least surprise.
>>> If you want Rational, use it from the start then.
>>
>> For D there is no reason why the class of the result needs to change
>> to Rational.  It could stay as BigDecimal but internally store the
>> data as a Rational.
In this case there would be no advantage to storing as a Rational. 
Sounds like you want an ExactNumber class that abstracts both.

For the record, I think BigDecimal / BigDecimal = BigDecimal is the 
correct design.
>
> Ah, I see. I had not thought it that way.
>
> Thanks,
>
> Peter
Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

Sent from my iPhone

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 25 December 2010 14:24, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> Peter Vandenabeele wrote in post #970618:
>> Colin Law wrote in post #970616:
>>> On 25 December 2010 00:37, Peter Vandenabeele
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
>>> wrote:
>> ...
>>>> I am not in favor of D because it silently changes the class
>>>> of the result and this violates the principle of least
surprise.
>>>> If you want Rational, use it from the start then.
>>>
>>> For D there is no reason why the class of the result needs to
change
>>> to Rational.  It could stay as BigDecimal but internally store the
>>> data as a Rational.
>
> In this case there would be no advantage to storing as a Rational.
> Sounds like you want an ExactNumber class that abstracts both.
>
> For the record, I think BigDecimal / BigDecimal = BigDecimal is the
> correct design.
In an earlier post I think it was suggested that an advantage of
BigDecimal is that errors do not increase.  With divide as it is, and
choosing 16 digit accuracy, then BigDecimal is virtually identical to
Float (assuming ruby Float is actually what would be known as double
in C).   Also errors will potentially increase every time a divide
operation is performed.  It seems that the default is actually 8 digit
which is only single precision float accuracy.

I see that http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic
discusses exactly this problem and the use of Rationals to get around
it.  It seems to suggest that some languages do that.

Colin

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Colin Law wrote in post #970648:
> On 25 December 2010 14:24, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
> wrote:
>>>> to Rational. It could stay as BigDecimal but internally store
the
>>>> data as a Rational.
>>
>> In this case there would be no advantage to storing as a Rational.
>> Sounds like you want an ExactNumber class that abstracts both.
>>
>> For the record, I think BigDecimal / BigDecimal = BigDecimal is the
>> correct design.
>
> In an earlier post I think it was suggested that an advantage of
> BigDecimal is that errors do not increase.
Basically.
>  With divide as it is, and
> choosing 16 digit accuracy, then BigDecimal is virtually identical to
> Float (assuming ruby Float is actually what would be known as double
> in C).
Not at all!  You can''t store 397 significant figures in a Float.  You 
can in a BigDecimal.  Apparently you are wilfully ignoring this 
advantage, since it has been brought up several times already.
>   Also errors will potentially increase every time a divide
> operation is performed.  It seems that the default is actually 8 digit
> which is only single precision float accuracy.
>
So don''t use the default!  Sheesh.
> I see that http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic
> discusses exactly this problem and the use of Rationals to get around
> it.  It seems to suggest that some languages do that.
And that would be easy to do in Ruby.  I''m glad we have a choice, 
though.
>
> Colin
Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

Sent from my iPhone

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 25 December 2010 20:15, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> Colin Law wrote in post #970648:
>> On 25 December 2010 14:24, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
>> wrote:
>>>>> to Rational. It could stay as BigDecimal but internally
store the
>>>>> data as a Rational.
>>>
>>> In this case there would be no advantage to storing as a Rational.
>>> Sounds like you want an ExactNumber class that abstracts both.
>>>
>>> For the record, I think BigDecimal / BigDecimal = BigDecimal is the
>>> correct design.
>>
>> In an earlier post I think it was suggested that an advantage of
>> BigDecimal is that errors do not increase.
>
> Basically.
>
>>  With divide as it is, and
>> choosing 16 digit accuracy, then BigDecimal is virtually identical to
>> Float (assuming ruby Float is actually what would be known as double
>> in C).
>
> Not at all!  You can''t store 397 significant figures in a Float.
 You
> can in a BigDecimal.  Apparently you are wilfully ignoring this
> advantage, since it has been brought up several times already.
I am not at all saying there is no advantage to BigDecimal, merely
exploring the issues.  I entirely agree that for + - * there can be
significant advantages.  I am pointing out here that as soon as you
get into more complex calculations involving division, or irrational
numbers such as pi, and trig functions, square roots and so on that
BigDecimal is not a panacea and will not guarantee that there are no
errors in the calculations.
>>   Also errors will potentially increase every time a divide
>> operation is performed.  It seems that the default is actually 8 digit
>> which is only single precision float accuracy.
>>
>
> So don''t use the default!  Sheesh.
Right, again I was pointing out that one cannot blindly assume that
BigDecimal is a panacea, it is necessary to understand ones problem
and use the features appropriately.  I am not suggesting you would not
do that, others may not realise the issues however.  It does seem
strange to me that the default should be such low precision.  It means
that doing complex arithmetic with BigDecimal using the default
precision one may get much greater errors than with Float.
>> I see that http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic
>> discusses exactly this problem and the use of Rationals to get around
>> it.  It seems to suggest that some languages do that.
>
> And that would be easy to do in Ruby.  I''m glad we have a choice,
> though.
You misunderstand me, I was talking about the possibility of
BigDecimal automatically using Rationals internally when division is
involved (if the division does not result in an exact result).  So if
one did BD(1) / BD(3) then the result would be exactly 1/3 and would
be a BigDecimal.  Internally it would be a Rational but the user would
not need to know that.  The Wikipedia article appeared to suggest that
some languages automatically do that.  Again I am not saying Ruby
_should_ do that, merely exploring the issues again.

I am not trying to have an argument here, I am learning a lot myself
by researching the issues and value such discussions greatly.

Did you have a chance to see whether for you the result of BD 1 / BD 3
where each was specified as 16 bit appeared to result in an 8 bit
answer, and if so, why?

Colin

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Colin Law wrote in post #970667:
> On 25 December 2010 20:15, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
> wrote:
>>>> correct design.
>>
>> Not at all! You can''t store 397 significant figures in a
Float. You
>> can in a BigDecimal. Apparently you are wilfully ignoring this
>> advantage, since it has been brought up several times already.
>
> I am not at all saying there is no advantage to BigDecimal, merely
> exploring the issues.  I entirely agree that for + - * there can be
> significant advantages.  I am pointing out here that as soon as you
> get into more complex calculations involving division, or irrational
> numbers such as pi, and trig functions, square roots and so on that
> BigDecimal is not a panacea and will not guarantee that there are no
> errors in the calculations.
OK, that I agree with.  I thought you were going further.
>
>>>  Also errors will potentially increase every time a divide
>>> operation is performed. It seems that the default is actually 8
digit
>>> which is only single precision float accuracy.
>>>
>>
>> So don''t use the default! Sheesh.
>
> Right, again I was pointing out that one cannot blindly assume that
> BigDecimal is a panacea, it is necessary to understand ones problem
> and use the features appropriately.  I am not suggesting you would not
> do that, others may not realise the issues however.  It does seem
> strange to me that the default should be such low precision.
And to me.
> It means
> that doing complex arithmetic with BigDecimal using the default
> precision one may get much greater errors than with Float.
Right.
>
>>> I see that
http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic
>>> discusses exactly this problem and the use of Rationals to get
around
>>> it. It seems to suggest that some languages do that.
>>
>> And that would be easy to do in Ruby. I''m glad we have a
choice,
>> though.
>
> You misunderstand me, I was talking about the possibility of
> BigDecimal automatically using Rationals internally when division is
> involved (if the division does not result in an exact result).  So if
> one did BD(1) / BD(3) then the result would be exactly 1/3 and would
> be a BigDecimal.  Internally it would be a Rational but the user would
> not need to know that.
Is that really a good idea?  This is where I think you''re really
arguing
for a further abstraction as I already proposed.

> The Wikipedia article appeared to suggest that
> some languages automatically do that.  Again I am not saying Ruby
> _should_ do that, merely exploring the issues again.
I''d want a symbolic math system like Mathematica to do that. 
I''m not
sure if a general-purpose programming language should.
>
> I am not trying to have an argument here, I am learning a lot myself
> by researching the issues and value such discussions greatly.
Me too!  This is fascinating.
>
> Did you have a chance to see whether for you the result of BD 1 / BD 3
> where each was specified as 16 bit appeared to result in an 8 bit
> answer, and if so, why?
Not yet.  Even though I''m Jewish, Christmas has me really busy!
>
> Colin
Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

Sent from my iPhone

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Just a footnote to all of this.

The difference between using a value for pi of 3.1415927 or 3.14159265,
between 7 and 8 digits of precision, when calculating the circumference of
the earth introduces a difference of less than a meter. All very reasonable,
but I still found it surprising.

I was taking a differential equations class from a very knowledgeable math
professor who told us about it. He was also surprised to discover that such
low precision in *pi* can lead to such precision in the physical world.

Fred

On Sat, Dec 25, 2010 at 5:30 PM, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>wrote:
> Colin Law wrote in post #970667:
> > On 25 December 2010 20:15, Marnen Laibow-Koser
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
> > wrote:
> >>>> correct design.
> >>
> >> Not at all! You can''t store 397 significant figures in a
Float. You
> >> can in a BigDecimal. Apparently you are wilfully ignoring this
> >> advantage, since it has been brought up several times already.
> >
> > I am not at all saying there is no advantage to BigDecimal, merely
> > exploring the issues.  I entirely agree that for + - * there can be
> > significant advantages.  I am pointing out here that as soon as you
> > get into more complex calculations involving division, or irrational
> > numbers such as pi, and trig functions, square roots and so on that
> > BigDecimal is not a panacea and will not guarantee that there are no
> > errors in the calculations.
>
> OK, that I agree with.  I thought you were going further.
>
> >
> >>>  Also errors will potentially increase every time a divide
> >>> operation is performed. It seems that the default is actually
8 digit
> >>> which is only single precision float accuracy.
> >>>
> >>
> >> So don''t use the default! Sheesh.
> >
> > Right, again I was pointing out that one cannot blindly assume that
> > BigDecimal is a panacea, it is necessary to understand ones problem
> > and use the features appropriately.  I am not suggesting you would not
> > do that, others may not realise the issues however.  It does seem
> > strange to me that the default should be such low precision.
>
> And to me.
>
> > It means
> > that doing complex arithmetic with BigDecimal using the default
> > precision one may get much greater errors than with Float.
>
> Right.
>
> >
> >>> I see that
http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic
> >>> discusses exactly this problem and the use of Rationals to get
around
> >>> it. It seems to suggest that some languages do that.
> >>
> >> And that would be easy to do in Ruby. I''m glad we have a
choice,
> >> though.
> >
> > You misunderstand me, I was talking about the possibility of
> > BigDecimal automatically using Rationals internally when division is
> > involved (if the division does not result in an exact result).  So if
> > one did BD(1) / BD(3) then the result would be exactly 1/3 and would
> > be a BigDecimal.  Internally it would be a Rational but the user would
> > not need to know that.
>
> Is that really a good idea?  This is where I think you''re really
arguing
> for a further abstraction as I already proposed.
>
>
> > The Wikipedia article appeared to suggest that
> > some languages automatically do that.  Again I am not saying Ruby
> > _should_ do that, merely exploring the issues again.
>
> I''d want a symbolic math system like Mathematica to do that. 
I''m not
> sure if a general-purpose programming language should.
>
> >
> > I am not trying to have an argument here, I am learning a lot myself
> > by researching the issues and value such discussions greatly.
>
> Me too!  This is fascinating.
>
> >
> > Did you have a chance to see whether for you the result of BD 1 / BD 3
> > where each was specified as 16 bit appeared to result in an 8 bit
> > answer, and if so, why?
>
> Not yet.  Even though I''m Jewish, Christmas has me really busy!
>
> >
> > Colin
>
> Best,
> --
> Marnen Laibow-Koser
> http://www.marnen.org
> marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
>
> Sent from my iPhone
>
> --
> Posted via http://www.ruby-forum.com/.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.