0.06 == 0.06 returns false in Ruby?

ruby-talk
21

Kyle Schmitt wrote:

···

On 8/30/07, doug meyer <doug.meyer@sigeps.org> wrote:

There is also a class called BigDecimal (or something like that) if
you want to have really accurate numbers and no floating-point errors.

A warning on things like BigDecimal.
Unless I'm mistaken it's still stored in twos compliment, which means
you'll still end up with the same sort of floating point problems
(albeit further down), and the same numbers that you can't express
exactly with a normal float, can't be expressed exactly with a
BigDecimal.

You'd think some fixed point math libraries would help, but be
careful, because many of those _also_ store in twos compliment.

--Kyle

IIRC BigDecimal is in fact stored in (pregnant pause) Binary Coded
Decimal. But I should check that.

22

Dan Zwell wrote:

Michael wrote very convincingly that there is no simple solution that
will work in all cases. I'm convinced, at least. If there is no solution
that works 100% of the time, we can't give the illusion that there is.
To do so would be to teach bad programming practices to newcomers, and
that's not fair.

The current "==" in okay because it works the way a moderately
experienced programmer would expect. A perfect "==" that could deal with
floats would be even better, but we aren't gonna get that. A "==" that
seems like magic and almost always works is really pretty dangerous.

Dan

Yeah ... even people like me who have spent several decades in this
branch of computing need to be reminded of these things occasionally.
What *I* wish Ruby had for scientific number-crunching is built-in
floating point arrays, rather than having to pass potential large
objects into and out of C language libraries to get number crunching done.

23

> There is also a class called BigDecimal (or something like that) if
> you want to have really accurate numbers and no floating-point errors.

A warning on things like BigDecimal.
Unless I'm mistaken it's still stored in twos compliment, which means
you'll still end up with the same sort of floating point problems
(albeit further down), and the same numbers that you can't express
exactly with a normal float, can't be expressed exactly with a
BigDecimal.

Um, 2's compliment is not a cause of floating point error. IEEE
floating point numbers do not use two's complement, they have a sign
bit. Two's complement is just a way of encoding the sign of a value.

You'd think some fixed point math libraries would help, but be
careful, because many of those _also_ store in twos compliment.

Again, the use of two's complement or lack thereof is totally irrelevant.

···

On 8/31/07, Kyle Schmitt <kyleaschmitt@gmail.com> wrote:

On 8/30/07, doug meyer <doug.meyer@sigeps.org> wrote:
--Kyle

24

# Daniel Berger wrote:
# > class Float
# > def ==(other)
# > self.to_s == other.to_s
# > end
# > end
# Oh yes, nice one. This fulfills
# 'from x==y and y==z follows x==z'
# Unfortunately it does not fulfill some other properties one

w a little help fr bigdecimal, a little goes a long long way

class Float
  def to_dec
     BigDecimal.new(self.to_s)
  end
end

=> nil

class Fixnum
   def to_dec
      BigDecimal.new(self.to_s)
   end
end

=> nil

x=0.06.to_dec
y=0.05.to_dec + 0.01.to_dec
x==y

=> true

z=0.02.to_dec+0.04.to_dec
y==z

=> true

z==y

=> true

x==z

=> true

z==x

=> true

# wants to have; e.g. it violates
# 'from x==y follows x+z==y+z'

x+z == y+z

=> true

(x+z).to_s == (y+z).to_s

=> true

puts (x+z)

0.12E0
=> nil

# for example
# In particular, you don't have

···

From: Michael Ulm [mailto:michael.ulm@isis-papyrus.com]
#
# 'from x==y follows x-y==0'

x==y

=> true

x-y == 0

=> true

# for example
#
# > x, y = 0.6, 6 * 0.1
# > x.to_s == y.to_s # => true
# > (x - y).to_s == 0.to_s # => false

x, y = 0.6.to_dec, 6 * 0.1.to_dec
(x - y) == 0

=> true

(x - y) == 0.to_dec

=> true

(x - y).to_s == 0.to_dec.to_s

=> true

kind regards -botp

25

From: Robert Klemme [mailto:shortcutter@googlemail.com]
# And who decides about the size of epsilon and which algorithm to
# choose? There is no one size fits all answer to that hence leaving
# Float#== the way it is (i.e. compare for exact identical values) is
# the only viable option. Otherwise you would soon see similar
# questions on the list, i.e., "how come it sometimes works and
# sometimes it doesn't". And they become more difficult to answer as
# the cases are likely less easy to spot / explain.

indeed :frowning:

maybe i'm not "realistic" but i thought

   0.05 + 0.01 == 0.06 => false

was "unrealistic" enough for a simple and plain 2 decimal arithmetic. Even people w zero-know on computers would laugh about it (yes, try explaining it to your wife or kids, eg).

This seems indeed a very valid argument at first sight.
But I feel that it is not the case.
Ruby has Integers and Floats, it does not have Fixed Digit Decimals
that is all which is to discuss here, as long as we discuss Floats
Michael is just dead right, now saying that we should have something
which delivers
0.05 + 0.01 == 0.06 => true
is a slightly different issue.
Personally I do not miss it because if I want decimals to be precise
to n digits I will just multiply by 10**n, at least the precision is
clear than.
But that is a matter of taste, I guess.
Cheers
Robert

···

On 8/31/07, Peña, Botp <botp@delmonte-phil.com> wrote:

For simple math (eg those dealing w money):
  i can live w slowness in simple math (quite a paradox if you ask me).
  i can live w 1/3 == 0.3333333333 =>false
  or that sqrt(2) == 1.1414213562 => false
  i use bigdecimal. bigdecimal handles 0.05 + 0.01 == 0.06 => true

For complex math,
  i can live w slowness (no question there).
  bigdecimal easily handles sqrt(2) at 100 digits: 2.sqrt(100) => #<BigDecimal:b7d74094,'0.1414213562 3730950488 0168872420 9698078569 6718753769 4807317667 9737990732 4784621070 3885038753 4327641572 7350138462 309122925E1',124(124)
  so yes, i still use bigdecimal for complex math.

so regardless, of whether its simple or complex (or "highly precise" or not), i use bigdecimal. counting ang looping otoh has no problem w me since fixnum/bignum handles this flawlessly. (Also, note that big RDBMS like oracle and postgresql use BCD and fixed pt math for numerics).

So, my question probably is (maybe this could be addressed to Matz): How can i make ruby use a particular arithmetic, like bigdecimal eg, so that literals like 1.05, and operations like 1+1.01 are now handled as bigdecimals.

thank you and kind regards -botp

--
I'm an atheist and that's it. I believe there's nothing we can know
except that we should be kind to each other and do what we can for
other people.
-- Katharine Hepburn

26

From: Robert Klemme [mailto:shortcutter@googlemail.com]
# And who decides about the size of epsilon and which algorithm to
# choose? There is no one size fits all answer to that hence leaving
# Float#== the way it is (i.e. compare for exact identical values) is
# the only viable option. Otherwise you would soon see similar
# questions on the list, i.e., "how come it sometimes works and
# sometimes it doesn't". And they become more difficult to answer as
# the cases are likely less easy to spot / explain.

indeed :frowning:

maybe i'm not "realistic" but i thought

   0.05 + 0.01 == 0.06 => false

was "unrealistic" enough for a simple and plain 2 decimal arithmetic. Even people w zero-know on computers would laugh about it (yes, try explaining it to your wife or kids, eg).

That's probably the exact reason why not your wife or kids write
software but people who are (hopefully) experts. :slight_smile: If you study
computer sciences you'll typically hit the topic of numeric issues at
some point.

For simple math (eg those dealing w money):
  i can live w slowness in simple math (quite a paradox if you ask me).
  i can live w 1/3 == 0.3333333333 =>false
  or that sqrt(2) == 1.1414213562 => false
  i use bigdecimal. bigdecimal handles 0.05 + 0.01 == 0.06 => true

For complex math,
  i can live w slowness (no question there).
  bigdecimal easily handles sqrt(2) at 100 digits: 2.sqrt(100) => #<BigDecimal:b7d74094,'0.1414213562 3730950488 0168872420 9698078569 6718753769 4807317667 9737990732 4784621070 3885038753 4327641572 7350138462 309122925E1',124(124)
  so yes, i still use bigdecimal for complex math.

so regardless, of whether its simple or complex (or "highly precise" or not), i use bigdecimal. counting ang looping otoh has no problem w me since fixnum/bignum handles this flawlessly. (Also, note that big RDBMS like oracle and postgresql use BCD and fixed pt math for numerics).

So, my question probably is (maybe this could be addressed to Matz): How can i make ruby use a particular arithmetic, like bigdecimal eg, so that literals like 1.05, and operations like 1+1.01 are now handled as bigdecimals.

Well, you could provide your formula as strings and convert it to
something that creates BigDecimals along the way, like

irb(main):015:0> "0.01+0.05".gsub(%r{\d+(?:\.\d*)?}, "BigDecimal.new('\\&')")
=> "BigDecimal.new('0.01')+BigDecimal.new('0.05')"
irb(main):016:0> eval("0.01+0.05".gsub(%r{\d+(?:\.\d*)?},
"BigDecimal.new('\\&')"))
=> #<BigDecimal:7ff6dd60,'0.6E-1',4(12)>

# note this is of course not a proper solution since the RX does not
match all valid floats

Kind regards

robert

···

2007/8/31, Peña, Botp <botp@delmonte-phil.com>:

27

Neither one can represent 1/3 or sqrt(2) exactly.

···

On Sat, 01 Sep 2007 00:24:39 +0900, M. Edward (Ed) Borasky wrote:

Kyle Schmitt wrote:

On 8/30/07, doug meyer <doug.meyer@sigeps.org> wrote:

There is also a class called BigDecimal (or something like that) if
you want to have really accurate numbers and no floating-point errors.

A warning on things like BigDecimal.
Unless I'm mistaken it's still stored in twos compliment, which means
you'll still end up with the same sort of floating point problems
(albeit further down), and the same numbers that you can't express
exactly with a normal float, can't be expressed exactly with a
BigDecimal.

You'd think some fixed point math libraries would help, but be careful,
because many of those _also_ store in twos compliment.

--Kyle

IIRC BigDecimal is in fact stored in (pregnant pause) Binary Coded
Decimal. But I should check that.

--
Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

28

Used the wrong term :stuck_out_tongue: sue me. I guess that's why I should lookup
stuff before responding :wink:
Anyway it's all based on the fact that you can't store some numbers
exactly as sum of different xes for 2**(-x).

--Kyle

···

On 8/31/07, Logan Capaldo <logancapaldo@gmail.com> wrote:

On 8/31/07, Kyle Schmitt <kyleaschmitt@gmail.com> wrote:
> On 8/30/07, doug meyer <doug.meyer@sigeps.org> wrote:
> > There is also a class called BigDecimal (or something like that) if
> > you want to have really accurate numbers and no floating-point errors.
>
> A warning on things like BigDecimal.
> Unless I'm mistaken it's still stored in twos compliment, which means
> you'll still end up with the same sort of floating point problems
> (albeit further down), and the same numbers that you can't express
> exactly with a normal float, can't be expressed exactly with a
> BigDecimal.
>
Um, 2's compliment is not a cause of floating point error. IEEE
floating point numbers do not use two's complement, they have a sign
bit. Two's complement is just a way of encoding the sign of a value.

29

Peña wrote:

From: Michael Ulm [mailto:michael.ulm@isis-papyrus.com] # Daniel Berger wrote:
# > class Float
# > def ==(other)
# > self.to_s == other.to_s
# > end
# > end
# Oh yes, nice one. This fulfills # 'from x==y and y==z follows x==z'
# Unfortunately it does not fulfill some other properties one

w a little help fr bigdecimal, a little goes a long long way

class Float
  def to_dec
     BigDecimal.new(self.to_s)
  end
end

=> nil

class Fixnum
   def to_dec
      BigDecimal.new(self.to_s)
   end
end

=> nil

x=0.06.to_dec
y=0.05.to_dec + 0.01.to_dec
x==y

=> true

z=0.02.to_dec+0.04.to_dec
y==z

=> true

z==y

=> true

x==z

=> true

z==x

=> true

--snip--

However (among other problems):

x = (1.0/3.0).to_dec
y = 1.0.to_dec / 3.0.to_dec
x == y # => false

HTH,

Michael

30

Hi,
Try converting to strings e.g:
irb(main):004:0> (0.05 + 0.01).to_s == 0.06.to_s
=> true

BR
Davor

···

On 31 Aug, 14:02, "Robert Klemme" <shortcut...@googlemail.com> wrote:

2007/8/31, Peña, Botp <b...@delmonte-phil.com>:

> From: Robert Klemme [mailto:shortcut...@googlemail.com]
> # And who decides about the size of epsilon and which algorithm to
> # choose? There is no one size fits all answer to that hence leaving
> # Float#== the way it is (i.e. compare for exact identical values) is
> # the only viable option. Otherwise you would soon see similar
> # questions on the list, i.e., "how come it sometimes works and
> # sometimes it doesn't". And they become more difficult to answer as
> # the cases are likely less easy to spot / explain.

> indeed :frowning:

> maybe i'm not "realistic" but i thought

> 0.05 + 0.01 == 0.06 => false

> was "unrealistic" enough for a simple and plain 2 decimal arithmetic. Even people w zero-know on computers would laugh about it (yes, try explaining it to your wife or kids, eg).

That's probably the exact reason why not your wife or kids write
software but people who are (hopefully) experts. :slight_smile: If you study
computer sciences you'll typically hit the topic of numeric issues at
some point.

> For simple math (eg those dealing w money):
> i can live w slowness in simple math (quite a paradox if you ask me).
> i can live w 1/3 == 0.3333333333 =>false
> or that sqrt(2) == 1.1414213562 => false
> i use bigdecimal. bigdecimal handles 0.05 + 0.01 == 0.06 => true

> For complex math,
> i can live w slowness (no question there).
> bigdecimal easily handles sqrt(2) at 100 digits: 2.sqrt(100) => #<BigDecimal:b7d74094,'0.1414213562 3730950488 0168872420 9698078569 6718753769 4807317667 9737990732 4784621070 3885038753 4327641572 7350138462 309122925E1',124(124)
> so yes, i still use bigdecimal for complex math.

> so regardless, of whether its simple or complex (or "highly precise" or not), i use bigdecimal. counting ang looping otoh has no problem w me since fixnum/bignum handles this flawlessly. (Also, note that big RDBMS like oracle and postgresql use BCD and fixed pt math for numerics).

> So, my question probably is (maybe this could be addressed to Matz): How can i make ruby use a particular arithmetic, like bigdecimal eg, so that literals like 1.05, and operations like 1+1.01 are now handled as bigdecimals.

Well, you could provide your formula as strings and convert it to
something that creates BigDecimals along the way, like

irb(main):015:0> "0.01+0.05".gsub(%r{\d+(?:\.\d*)?}, "BigDecimal.new('\\&')")
=> "BigDecimal.new('0.01')+BigDecimal.new('0.05')"
irb(main):016:0> eval("0.01+0.05".gsub(%r{\d+(?:\.\d*)?},
"BigDecimal.new('\\&')"))
=> #<BigDecimal:7ff6dd60,'0.6E-1',4(12)>

# note this is of course not a proper solution since the RX does not
match all valid floats

Kind regards

robert- Dölj citerad text -

- Visa citerad text -

31

Robert Klemme wrote:

From: Robert Klemme [mailto:shortcutter@googlemail.com]
# And who decides about the size of epsilon and which algorithm to
# choose? There is no one size fits all answer to that hence leaving
# Float#== the way it is (i.e. compare for exact identical values) is
# the only viable option. Otherwise you would soon see similar
# questions on the list, i.e., "how come it sometimes works and
# sometimes it doesn't". And they become more difficult to answer as
# the cases are likely less easy to spot / explain.

indeed :frowning:

maybe i'm not "realistic" but i thought

   0.05 + 0.01 == 0.06 => false

was "unrealistic" enough for a simple and plain 2 decimal arithmetic. Even people w zero-know on computers would laugh about it (yes, try explaining it to your wife or kids, eg).

That's probably the exact reason why not your wife or kids write
software but people who are (hopefully) experts. :slight_smile: If you study
computer sciences you'll typically hit the topic of numeric issues at
some point.

Actually, unless you're a (hard) science or engineering major, you
probably won't. Numerical analysis/methods aren't really considered part
of "computer science". Computer science is mostly about *discrete*
mathematics, data structures, programming languages and their
interpreters and compilers, etc. And you probably won't get it in a
"software engineering" program either. Applied mathematics is your best
shot, I think.

···

2007/8/31, Peña, Botp <botp@delmonte-phil.com>:

32

Ken Bloom wrote:

Kyle Schmitt wrote:

There is also a class called BigDecimal (or something like that) if
you want to have really accurate numbers and no floating-point errors.

A warning on things like BigDecimal.
Unless I'm mistaken it's still stored in twos compliment, which means
you'll still end up with the same sort of floating point problems
(albeit further down), and the same numbers that you can't express
exactly with a normal float, can't be expressed exactly with a
BigDecimal.

You'd think some fixed point math libraries would help, but be careful,
because many of those _also_ store in twos compliment.

--Kyle

IIRC BigDecimal is in fact stored in (pregnant pause) Binary Coded
Decimal. But I should check that.

Neither one can represent 1/3 or sqrt(2) exactly.

Which is why there are libraries and packages like GiNaC, CLN, GMP,
Singular, Maxima, Axiom, ...

I personally think Ruby's libraries for exact arithmetic are better than
those in the other scripting languages -- I don't think anyone else has
BigDecimal, Rational, Complex, Matrix, "mathn" and Bignums built in or
part of the *standard* libraries. The only thing that's missing, as I
noted earlier, is the ability to declare a physically contiguous block
of RAM as a vector of floating point or complex numbers and operate on
them as such. For that, you need to go to an external package like NArray.

···

On Sat, 01 Sep 2007 00:24:39 +0900, M. Edward (Ed) Borasky wrote:

On 8/30/07, doug meyer <doug.meyer@sigeps.org> wrote:

33

# Well, you could provide your formula as strings and convert it to
# something that creates BigDecimals along the way, like
# irb(main):015:0> "0.01+0.05".gsub(%r{\d+(?:\.\d*)?},
# "BigDecimal.new('\\&')")
# => "BigDecimal.new('0.01')+BigDecimal.new('0.05')"
# irb(main):016:0> eval("0.01+0.05".gsub(%r{\d+(?:\.\d*)?},
# "BigDecimal.new('\\&')"))
# => #<BigDecimal:7ff6dd60,'0.6E-1',4(12)>
# note this is of course not a proper solution since the RX does not
# match all valid floats

:slight_smile:
on my case, i just want ruby to default to bigdeci (or whatever i want) instead of float. meaning, i choose any math processor i want. is that possible now, or in near future of ruby?

kind regards -botp

···

From: Robert Klemme [mailto:shortcutter@googlemail.com]

34

BigDecimals do *not* use binary representation. That's why they are called Big/Decimal/.

If you want to give a warning then it should be that for *any* representation (binary, decimal, hex, octal whatever) there are fractional numbers that cannot be represented properly with that representation. You have to be aware of this for *all* representation types. The reason people are surprised is typically because we enter float numbers in decimal but systems use binary representation (which is standardized btw.) internally and that has other numbers that it cannot properly represent. BigDecimal helps because it uses the same representation internally that we are used to use for numbers - decimal digits.

Kind regards

  robert

···

On 01.09.2007 22:33, Kyle Schmitt wrote:

On 8/31/07, Logan Capaldo <logancapaldo@gmail.com> wrote:

On 8/31/07, Kyle Schmitt <kyleaschmitt@gmail.com> wrote:

On 8/30/07, doug meyer <doug.meyer@sigeps.org> wrote:

There is also a class called BigDecimal (or something like that) if
you want to have really accurate numbers and no floating-point errors.

A warning on things like BigDecimal.
Unless I'm mistaken it's still stored in twos compliment, which means
you'll still end up with the same sort of floating point problems
(albeit further down), and the same numbers that you can't express
exactly with a normal float, can't be expressed exactly with a
BigDecimal.

Um, 2's compliment is not a cause of floating point error. IEEE
floating point numbers do not use two's complement, they have a sign
bit. Two's complement is just a way of encoding the sign of a value.

Used the wrong term :stuck_out_tongue: sue me. I guess that's why I should lookup
stuff before responding :wink:
Anyway it's all based on the fact that you can't store some numbers
exactly as sum of different xes for 2**(-x).

35

# However (among other problems):
# > x = (1.0/3.0).to_dec

foul.. ^^^^^^^^^ is a float op and not a bigdecimal/to_dec. use atomic operations comparison, pls :slight_smile:

# > y = 1.0.to_dec / 3.0.to_dec

that is more like it

# > x == y # => false

of course.

so consider eg,

irb(main):057:0> x = 1.0.to_dec / 3.0.to_dec
=> #<BigDecimal:b7d87acc,'0.3333333333 333333E0',16(24)>
irb(main):058:0> y = 2.0.to_dec / 6.0.to_dec
=> #<BigDecimal:b7d7d874,'0.3333333333 333333E0',16(24)>
irb(main):059:0> x == y
=> true

kind regards -botp

···

From: Michael Ulm [mailto:michael.ulm@isis-papyrus.com]

36

Of course I can speak only for Germany but I had a mandatory lecture on numerical analysis during my CS studies. IIRC it was even during the lower grade phase (dunno the proper English wording), i.e. within the first two years. But then again, the "Diplom" is probably considered roughly equivalent to a major. Somehow I thought numerical effects were so basic and common that they are mentioned in all other places as well. Thanks for pointing this out.

Kind regards

  robert

···

On 31.08.2007 17:30, M. Edward (Ed) Borasky wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Klemme wrote:

2007/8/31, Peña, Botp <botp@delmonte-phil.com>:

From: Robert Klemme [mailto:shortcutter@googlemail.com]
# And who decides about the size of epsilon and which algorithm to
# choose? There is no one size fits all answer to that hence leaving
# Float#== the way it is (i.e. compare for exact identical values) is
# the only viable option. Otherwise you would soon see similar
# questions on the list, i.e., "how come it sometimes works and
# sometimes it doesn't". And they become more difficult to answer as
# the cases are likely less easy to spot / explain.

indeed :frowning:

maybe i'm not "realistic" but i thought

   0.05 + 0.01 == 0.06 => false

was "unrealistic" enough for a simple and plain 2 decimal arithmetic. Even people w zero-know on computers would laugh about it (yes, try explaining it to your wife or kids, eg).

That's probably the exact reason why not your wife or kids write
software but people who are (hopefully) experts. :slight_smile: If you study
computer sciences you'll typically hit the topic of numeric issues at
some point.

Actually, unless you're a (hard) science or engineering major, you
probably won't. Numerical analysis/methods aren't really considered part
of "computer science". Computer science is mostly about *discrete*
mathematics, data structures, programming languages and their
interpreters and compilers, etc. And you probably won't get it in a
"software engineering" program either. Applied mathematics is your best
shot, I think.

37

Hi,
Try converting to strings e.g:
irb(main):004:0> (0.05 + 0.01).to_s == 0.06.to_s
=> true

I think what puzzles is while 0.05+0.01 == 0.06 returns false, the
strings _do_ match.

def float_check(a,b)
  p [a==b,a.to_s == b.to_s]
end

float_check(0.06,0.06) # -> [true,true]
float_check(0.05+0.01,0.06) # -> [false,true]

Most other programming languages either have no format-less .to_s
function (like in C) or return values at inspection time so that
people get aware of the issue more easily. In Python it is obvious
that 0.05+0.01 == 0.06 is false.

$ python

0.05

0.050000000000000003

0.01

0.01

0.05+0.01

0.060000000000000005

0.06

0.059999999999999998

I don't understand why Ruby 'rounds' values with .inspect (and
.to_s) opposed to Marshal.dump. Compare its output with the one
Python gives (this code is for Ruby 1.8.6):

[0.05,0.01,0.05+0.01,0.06].each do |v|
  p Marshal.dump(v).sub(/....([^\000]*).*/,'\1')
end

Output:

"0.050000000000000003"
"0.01"
"0.060000000000000005"
"0.059999999999999998"

Did I miss something here, is there a way to make Float#to_s (and,
thus, Float#inspect) give the same output as Marshal?

- Matthias

···

On 31.08.2007 16:07, Davor wrote:

38

Peña wrote:

From: Michael Ulm [mailto:michael.ulm@isis-papyrus.com] # However (among other problems):
# > x = (1.0/3.0).to_dec

foul.. ^^^^^^^^^ is a float op and not a bigdecimal/to_dec. use atomic operations comparison, pls :slight_smile:

--snip--

What about

x = 1.0.to_dec / 3.0.to_dec
y = x + x + x
y == 1.0.to_dec # => false

?

HTH,

Michael

···

--
Michael Ulm
R&D Team
ISIS Information Systems Austria
tel: +43 2236 27551-542, fax: +43 2236 21081
e-mail: michael.ulm@isis-papyrus.com
Visit our Website: www.isis-papyrus.com

---------------------------------------------------------------
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
---------------------------------------------------------------

39

I am in the Sophomore year of a CS degree at Washing State University
and I am currently enrolled in a mandatory Numerical Computing class.
While it is very much more CS-than-math it does, of course, cover
topics like FP implementations and related issues.

40

Matthias Wächter wrote:

I don't understand why Ruby 'rounds' values with .inspect (and
.to_s) opposed to Marshal.dump. Compare its output with the one
Python gives (this code is for Ruby 1.8.6):

Because for an *inspection* a precision of 5, 6 places are sufficient.
Inspect isn't used for printing values other than debugging etc.
In the opposite, having 40+ places for every float in your debug output
would be rather annoying and almost always of little help.
If python choses to be annoying, be it so, I'm happy ruby doesn't.
Use sprintf/String#% if you want to specify the precision you want your
output.
Marshal.dump on the other hand is serializing, of course you don't want
your floats truncated just because you're serializing.
As for having a way: you can always open the Float class and define
.to_s to your liking. Same for inspect.

Regards
Stefan

···

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