[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Ruby doesn't know how to multiply

Yukihiro Matsumoto

6/22/2007 12:07:00 AM

Hi,

In message "Re: Ruby doesn't know how to multiply"
on Fri, 22 Jun 2007 05:57:48 +0900, Lloyd Linklater <lloyd@2live4.com> writes:

|I tried this in Delphi, smalltalk and oracle SQL and got the correct
|result.

Interesting. There are a few ways to get the "correct" result.

* fixed point number
* base 10 floating numbers
* comparison with epsilon

Does anyone know how these languages get the correct result?

matz.
20 Answers

Michael W. Ryder

6/22/2007 12:42:00 AM

0

Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: Ruby doesn't know how to multiply"
> on Fri, 22 Jun 2007 05:57:48 +0900, Lloyd Linklater <lloyd@2live4.com> writes:
>
> |I tried this in Delphi, smalltalk and oracle SQL and got the correct
> |result.
>
> Interesting. There are a few ways to get the "correct" result.
>
> * fixed point number
> * base 10 floating numbers
> * comparison with epsilon
>
> Does anyone know how these languages get the correct result?
>
> matz.
>
A simple way to get the correct figure is to do what is used often with
currency to prevent these types of errors. If I enter 'puts
1495.0*6.0/1000.0' I get 8.97. The only thing necessary is to keep
track of the number of decimal points.

Gregory Brown

6/22/2007 12:49:00 AM

0

On 6/21/07, Michael W. Ryder <_mwryder@worldnet.att.net> wrote:

> A simple way to get the correct figure is to do what is used often with
> currency to prevent these types of errors. If I enter 'puts
> 1495.0*6.0/1000.0' I get 8.97. The only thing necessary is to keep
> track of the number of decimal points.

Much better is to store the numbers as integers and convert to
decimal, guaranteeing zero loss.

Rob Biedenharn

6/22/2007 2:02:00 AM

0

On Jun 21, 2007, at 8:48 PM, Gregory Brown wrote:
> On 6/21/07, Michael W. Ryder <_mwryder@worldnet.att.net> wrote:
>> A simple way to get the correct figure is to do what is used often
>> with
>> currency to prevent these types of errors. If I enter 'puts
>> 1495.0*6.0/1000.0' I get 8.97. The only thing necessary is to keep
>> track of the number of decimal points.
>
> Much better is to store the numbers as integers and convert to
> decimal, guaranteeing zero loss.

Which are just different ways of saying "fixed point numbers" that
matz had at the top of his list. Believe me when I tell you that
dealing with fixed point can be challenging. I worked on part of an
air traffic control system about 20 years ago that used 16-bit values
where the LSB for a distance value represented 1/256nm (nautical
mile). There was no floating-point co-processor in the M68000-based
systems and the C code was compiled with a special, non-standard
compiler that would do things like (16-bits * 16-bits)/16-bits was
assumed to produce a 16-bit result unless you had a typecast to
indicate otherwise.

The other way to get truth from 14.95*0.6 == 8.97 is to use less
precise representations than you get with a typical Float. Of
course, that's going to be a problem as the numbers get bigger ;-)

-Rob

Rob Biedenharn http://agileconsult...
Rob@AgileConsultingLLC.com

Michael W. Ryder

6/22/2007 2:17:00 AM

0

Rob Biedenharn wrote:
> On Jun 21, 2007, at 8:48 PM, Gregory Brown wrote:
>> On 6/21/07, Michael W. Ryder <_mwryder@worldnet.att.net> wrote:
>>> A simple way to get the correct figure is to do what is used often with
>>> currency to prevent these types of errors. If I enter 'puts
>>> 1495.0*6.0/1000.0' I get 8.97. The only thing necessary is to keep
>>> track of the number of decimal points.
>>
>> Much better is to store the numbers as integers and convert to
>> decimal, guaranteeing zero loss.
>
> Which are just different ways of saying "fixed point numbers" that matz
> had at the top of his list. Believe me when I tell you that dealing
> with fixed point can be challenging. I worked on part of an air traffic
> control system about 20 years ago that used 16-bit values where the LSB
> for a distance value represented 1/256nm (nautical mile). There was no
> floating-point co-processor in the M68000-based systems and the C code
> was compiled with a special, non-standard compiler that would do things
> like (16-bits * 16-bits)/16-bits was assumed to produce a 16-bit result
> unless you had a typecast to indicate otherwise.
>

I think we have a difference of understanding of what fixed point means.
I look at fixed point numbers meaning something like 1057 means 10.57
in the real world. I was thinking more of something that shifted the
floating point number to remove the fractions and later replaced the
decimal point in the correct position, which I do not consider to be
fixed point math.
My simple calculator is more precise for some math operations than my
expensive PC. Maybe we need to implement something like General Decimal
Arithmetic which is available for C++ and Java at
http://www2.hursley.ibm.co... in Ruby. It may be as simple as
writing wrappers for the operations, I haven't had to time to look
closer at the package.


> The other way to get truth from 14.95*0.6 == 8.97 is to use less precise
> representations than you get with a typical Float. Of course, that's
> going to be a problem as the numbers get bigger ;-)
>
> -Rob
>
> Rob Biedenharn http://agileconsult...
> Rob@AgileConsultingLLC.com
>
>
>

Peña, Botp

6/22/2007 3:03:00 AM

0

From: Michael W. Ryder [mailto:_mwryder@worldnet.att.net] :
# My simple calculator is more precise for some math operations than my
# expensive PC. Maybe we need to implement something like
# General Decimal
# Arithmetic which is available for C++ and Java at
# http://www2.hursley.ibm.co... in Ruby. It may be as simple as
# writing wrappers for the operations, I haven't had to time to look
# closer at the package.

have you tried bigdecimal?

irb(main):001:0> require 'bigdecimal'
=> true
irb(main):002:0> a=BigDecimal("14.95")
=> #<BigDecimal:2867a5c,'0.1495E2',8(8)>
irb(main):003:0> b=BigDecimal("0.6")
=> #<BigDecimal:28614b8,'0.6E0',4(8)>
irb(main):004:0> c=BigDecimal("8.97")
=> #<BigDecimal:28e47b4,'0.897E1',8(8)>
irb(main):005:0> d=BigDecimal("8.970000001")
=> #<BigDecimal:28dffe8,'0.8970000001E1',16(16)>
irb(main):006:0> a*b == c
=> true
irb(main):007:0> a*b == d
=> false
irb(main):008:0> c == 8.97
=> true

bigdecimal notation is very handy for calculator-like applications since the raw input usually is of type string.

kind regards -botp

KUBO Takehiro

6/22/2007 5:18:00 AM

0

Hi,

On 6/22/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> |I tried this in Delphi, smalltalk and oracle SQL and got the correct
> |result.
>
> Interesting. There are a few ways to get the "correct" result.
>
> * fixed point number
> * base 10 floating numbers
> * comparison with epsilon

Oracle uses base 100 floating numbers.
http://download-west.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci03typ.htm...

> Does anyone know how these languages get the correct result?

Michael W. Ryder

6/22/2007 8:35:00 AM

0

Peña wrote:
> From: Michael W. Ryder [mailto:_mwryder@worldnet.att.net] :
> # My simple calculator is more precise for some math operations than my
> # expensive PC. Maybe we need to implement something like
> # General Decimal
> # Arithmetic which is available for C++ and Java at
> # http://www2.hursley.ibm.co... in Ruby. It may be as simple as
> # writing wrappers for the operations, I haven't had to time to look
> # closer at the package.
>
> have you tried bigdecimal?
>
> irb(main):001:0> require 'bigdecimal'
> => true
> irb(main):002:0> a=BigDecimal("14.95")
> => #<BigDecimal:2867a5c,'0.1495E2',8(8)>
> irb(main):003:0> b=BigDecimal("0.6")
> => #<BigDecimal:28614b8,'0.6E0',4(8)>
> irb(main):004:0> c=BigDecimal("8.97")
> => #<BigDecimal:28e47b4,'0.897E1',8(8)>
> irb(main):005:0> d=BigDecimal("8.970000001")
> => #<BigDecimal:28dffe8,'0.8970000001E1',16(16)>
> irb(main):006:0> a*b == c
> => true
> irb(main):007:0> a*b == d
> => false
> irb(main):008:0> c == 8.97
> => true
>
> bigdecimal notation is very handy for calculator-like applications since the raw input usually is of type string.
>
> kind regards -botp
>
>
I'm not trying to denigrate the project but it looks like it is still in
alpha stage while the IBM project seems to have been releasing
production code for a while. It also is an IEEE standard, which may or
may not mean anything.
I hadn't known about the bigdecimal project before and may try comparing
the results of it to the general decimal arithmetic package if I get time.

Gregory Brown

6/22/2007 1:48:00 PM

0

On 6/22/07, Michael W. Ryder <_mwryder@worldnet.att.net> wrote:

> I'm not trying to denigrate the project but it looks like it is still in
> alpha stage while the IBM project seems to have been releasing
> production code for a while. It also is an IEEE standard, which may or
> may not mean anything.

Um... BigDecimal part of the ruby standard library. What is 'alpha' about it?

Daniel DeLorme

6/22/2007 4:08:00 PM

0

Michael W. Ryder wrote:
> I think we have a difference of understanding of what fixed point means.
> I look at fixed point numbers meaning something like 1057 means 10.57
> in the real world. I was thinking more of something that shifted the
> floating point number to remove the fractions and later replaced the
> decimal point in the correct position, which I do not consider to be
> fixed point math.

Basically you are thinking of
>> require "rational"
=> true
>> Rational(1057,100).to_f
=> 10.57

Daniel

Michael W. Ryder

6/22/2007 6:49:00 PM

0

Gregory Brown wrote:
> On 6/22/07, Michael W. Ryder <_mwryder@worldnet.att.net> wrote:
>
>> I'm not trying to denigrate the project but it looks like it is still in
>> alpha stage while the IBM project seems to have been releasing
>> production code for a while. It also is an IEEE standard, which may or
>> may not mean anything.
>
> Um... BigDecimal part of the ruby standard library. What is 'alpha'
> about it?
>

My mistake. When I entered bigdecimal in the search screen at Ruby
Forge it pointed me to the long decimal package. Searching for
bigdecimal on ruby-lang.org came up with zero results. Where do I find
more information on bigdecimal as it isn't listed in the on-line version
of Pickaxe?