You say starting from a more consistent place, but how consistent are =
and = among Numbers without transitivity?
How are numbers consistent to begin with, when for all integers you have
x + 1 ~= x
but for floats, there are a multitude of values such that
x + 1.0 = x
holds? Addition is
Being consistent then means either abandonning 1/2 = 0.5 but we saw this
has nasty side effects.
Well ok, so letting 1 / 2 = 0.5 answer false has nasty side effects.
Why is that? Isn't the code that breaks trying to tell us something?
That's what I've been trying to point out. Why rush to
2014-07-12 17:00 GMT+02:00 Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com:
2014-07-12 13:42 GMT+02:00 Andres Valloud
avall...@smalltalk.comcastbiz.net:
Being consistent then means either abandonning 1/2 = 0.5 but we saw this
has nasty side effects.
Well ok, so letting 1 / 2 =
:)
in Smalltalk, the division of two integers is a fraction, not a float.
i.e. 1/5 is 1/5.
Thierry
Le 11/07/2014 15:53, Natalia Tymchuk a écrit :
Hello.
I found interesting thing:
Why it is like this?
Best regards,
Natalia
--
Thierry Goubier
CEA list
Laboratoire des Fondations des
Usually comparing against floats is not as deterministic as you would
expect. And in other dialects you use #equals: instead of #=
But in Pharo there is no #equals: and instead there is a #closeTo:,
but #closeTo: has an arbitrary decimal precision, more than enough for
commong arithmetic.
why not round it before comparing it ? looks like an easy enough problem to
fix . I would expect that to be equal.
On Fri, Jul 11, 2014 at 5:18 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote:
That’s why mathematics and programming are two different things…
On 11 Jul 2014, at 16:08, Esteban A.
That’s why mathematics and programming are two different things…
On 11 Jul 2014, at 16:08, Esteban A. Maringolo emaring...@gmail.com wrote:
Usually comparing against floats is not as deterministic as you would
expect. And in other dialects you use #equals: instead of #=
But in Pharo there
On 11 Jul 2014, at 16:22, kilon alios kilon.al...@gmail.com wrote:
why not round it before comparing it ? looks like an easy enough problem to
fix . I would expect that to be equal.
because it wouldn’t be correct :)
On Fri, Jul 11, 2014 at 5:18 PM, Yuriy Tymchuk yuriy.tymc...@me.com
On 11 Jul 2014, at 16:30, Esteban Lorenzano esteba...@gmail.com wrote:
On 11 Jul 2014, at 16:22, kilon alios kilon.al...@gmail.com wrote:
why not round it before comparing it ? looks like an easy enough problem to
fix . I would expect that to be equal.
because it wouldn’t be correct :)
Am 11.07.2014 um 16:33 schrieb Yuriy Tymchuk yuriy.tymc...@me.com:
On 11 Jul 2014, at 16:30, Esteban Lorenzano esteba...@gmail.com wrote:
On 11 Jul 2014, at 16:22, kilon alios kilon.al...@gmail.com wrote:
why not round it before comparing it ? looks like an easy enough problem to
fix
On 11 juil. 2014, at 17:01, Igor Stasenko siguc...@gmail.com wrote:
I would put it this way:
- If you writing code, which requires comparing two floating-point values for
equality, then you do something wrong.
:D
Rule of thumb: don't use floats ;)
--
Best regards,
Igor Stasenko.
2014-07-11 12:02 GMT-03:00 Natalia Tymchuk natalia.tymc...@unikernel.net:
But why
185/10 = 18.5 - true?
It is not deterministic. That's why you can't rely on such comparisons.
Regards!
Thanks all of you.
Best regards,
Natalia
On Jul 11, 2014, at 5:14 PM, Camille Teruel camille.ter...@gmail.com wrote:
On 11 juil. 2014, at 17:02, Natalia Tymchuk natalia.tymc...@unikernel.net
wrote:
But why
185/10 = 18.5 - true?
Because 18.5 has an exact float representation, while
2014-07-11 17:14 GMT+02:00 Camille Teruel camille.ter...@gmail.com:
On 11 juil. 2014, at 17:02, Natalia Tymchuk natalia.tymc...@unikernel.net
wrote:
But why
185/10 = 18.5 - true?
Because 18.5 has an exact float representation, while 0.2 hasn't.
Couldn't we use #asApproximateFraction
I suggest you to read the Small number chapter of the Deep into Pharo.
Stef
On 11/7/14 15:53, Natalia Tymchuk wrote:
Hello.
I found interesting thing:
Why it is like this?
Best regards,
Natalia
I don't think it makes sense to compare floating point numbers to other
types of numbers with #=... there's a world of approximations and other
factors hiding behind #=, and the occasional true answer confuses more
than it helps. On top of that, then you get x = y = x hash = y hash,
and so
2014-07-12 0:40 GMT+02:00 Andres Valloud avall...@smalltalk.comcastbiz.net
:
I don't think it makes sense to compare floating point numbers to other
types of numbers with #=... there's a world of approximations and other
factors hiding behind #=, and the occasional true answer confuses more
I don't think it makes sense to compare floating point numbers to
other types of numbers with #=... there's a world of approximations
and other factors hiding behind #=, and the occasional true answer
confuses more than it helps. On top of that, then you get x = y =
x hash =
2014-07-12 1:29 GMT+02:00 Andres Valloud avall...@smalltalk.comcastbiz.net
:
I don't think it makes sense to compare floating point numbers to
other types of numbers with #=... there's a world of approximations
and other factors hiding behind #=, and the occasional true answer
2014-07-12 2:26 GMT+02:00 Andres Valloud avall...@smalltalk.comcastbiz.net
:
In short, my point is that if one is going to optimize using floating
point, then be thorough. If everything is a float, then conversion isn't a
problem, comparison isn't a problem, etc. Starting from a more
20 matches
Mail list logo
