Smalltalk › Frameworks & Tools › SciSmalltalk

equalsTo: is naive

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Nicolas Cellier

equalsTo: is naive

try this snippet:

Float fmax asInteger * (3/2) equalsTo: 0

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

werner kassens-2

Re: equalsTo: is naive

Hi Nicolas,

<g> this is funny indeed. what do think about this change:

Number>>relativelyEqualsTo: aNumber upTo: aSmallNumber
        "compare to Float>>closeTo:
        generally called from Number>>equalsTo:
        (c) Copyrights Didier BESSET, 1999, all rights reserved.
        Initial code: 21/4/99 "
    | norm |
    norm := self abs max: aNumber abs.
    ^norm <= DhbFloatingPointMachine new defaultNumericalPrecision
        or: [ (self - aNumber) abs asFloat < ( aSmallNumber * norm)]

just the #asFloat added. would that still be buggy?

werner

On Wed, May 4, 2016 at 4:32 PM, Nicolas Cellier <[hidden email]> wrote:

try this snippet:

Float fmax asInteger * (3/2) equalsTo: 0

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Nicolas Cellier

Re: equalsTo: is naive

Hi Werner,
if we are perpetually reinventing the wheel, life is easy: I just have to perpetually exhume old bug reports ;)

http://bugs.squeak.org/view.php?id=6729
http://bugs.squeak.org/view.php?id=7368

I would attack the asFloat defense with:

(999e1000 relativelyEqualsTo: 998e1000 upTo: 1/100) which I expect to be true

Maybe something closer to closeTo:, just without hardcoded relative precision.

2016-05-04 19:58 GMT+02:00 werner kassens <[hidden email]>:

Hi Nicolas,
<g> this is funny indeed. what do think about this change:
Number>>relativelyEqualsTo: aNumber upTo: aSmallNumber
        "compare to Float>>closeTo:
        generally called from Number>>equalsTo:
        (c) Copyrights Didier BESSET, 1999, all rights reserved.
        Initial code: 21/4/99 "
    | norm |
    norm := self abs max: aNumber abs.
    ^norm <= DhbFloatingPointMachine new defaultNumericalPrecision
        or: [ (self - aNumber) abs asFloat < ( aSmallNumber * norm)]

just the #asFloat added. would that still be buggy?
werner

On Wed, May 4, 2016 at 4:32 PM, Nicolas Cellier <[hidden email]> wrote:
try this snippet:

Float fmax asInteger * (3/2) equalsTo: 0

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

werner kassens-2

Re: equalsTo: is naive

Hi Nicolas,
i see <g> the region is plastered with pitfalls and you already gave some serious thoughts to them. so yes, something closer to #closeTo:

Number>>relativelyEqualsTo: aNumber upTo: aSmallNumber
        "compare to Float>>closeTo:
        generally called from Number>>equalsTo:
        (c) Copyrights Didier BESSET, 1999, all rights reserved.
        Initial code: 21/4/99 "
    | norm |
    (norm := self abs max: aNumber abs)
        <= DhbFloatingPointMachine new defaultNumericalPrecision ifTrue:[^true].
    ^self = aNumber asFloat
        or: [(self - aNumber) abs / norm < aSmallNumber]

what about that?
the problem of comparisons with non-Numbers, that #closeTo: catches, is obviously still there. i had added #equalsTo: to DhbMatrix, DualNumber, SequenceableCollection etc, but i have to admit eg not yet to Complex. otoh #closeTo: is too strict in this case anyway and eg Point has therefore its own #closeTo:. so perhaps that shortcoming, that one needs to give non-Numbers its own #equalsTo:, is acceptable?
werner

On Wed, May 4, 2016 at 9:47 PM, Nicolas Cellier <[hidden email]> wrote:

Hi Werner,
if we are perpetually reinventing the wheel, life is easy: I just have to perpetually exhume old bug reports ;)
http://bugs.squeak.org/view.php?id=6729
http://bugs.squeak.org/view.php?id=7368

I would attack the asFloat defense with:

(999e1000 relativelyEqualsTo: 998e1000 upTo: 1/100) which I expect to be true

Maybe something closer to closeTo:, just without hardcoded relative precision.

2016-05-04 19:58 GMT+02:00 werner kassens <[hidden email]>:
Hi Nicolas,
<g> this is funny indeed. what do think about this change:
Number>>relativelyEqualsTo: aNumber upTo: aSmallNumber
        "compare to Float>>closeTo:
        generally called from Number>>equalsTo:
        (c) Copyrights Didier BESSET, 1999, all rights reserved.
        Initial code: 21/4/99 "
    | norm |
    norm := self abs max: aNumber abs.
    ^norm <= DhbFloatingPointMachine new defaultNumericalPrecision
        or: [ (self - aNumber) abs asFloat < ( aSmallNumber * norm)]

just the #asFloat added. would that still be buggy?
werner

On Wed, May 4, 2016 at 4:32 PM, Nicolas Cellier <[hidden email]> wrote:
try this snippet:

Float fmax asInteger * (3/2) equalsTo: 0

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

werner kassens-2

Re: equalsTo: is naive

and for which case is the #asFloat in "^self = num asFloat ..."? is that also necessary in #relativelyEqualsTo:?

werner

On Thu, May 5, 2016 at 12:27 PM, werner kassens <[hidden email]> wrote:

Hi Nicolas,
i see <g> the region is plastered with pitfalls and you already gave some serious thoughts to them. so yes, something closer to #closeTo:

Number>>relativelyEqualsTo: aNumber upTo: aSmallNumber
        "compare to Float>>closeTo:
        generally called from Number>>equalsTo:
        (c) Copyrights Didier BESSET, 1999, all rights reserved.
        Initial code: 21/4/99 "
    | norm |
    (norm := self abs max: aNumber abs)
        <= DhbFloatingPointMachine new defaultNumericalPrecision ifTrue:[^true].
    ^self = aNumber asFloat
        or: [(self - aNumber) abs / norm < aSmallNumber]

what about that?
the problem of comparisons with non-Numbers, that #closeTo: catches, is obviously still there. i had added #equalsTo: to DhbMatrix, DualNumber, SequenceableCollection etc, but i have to admit eg not yet to Complex. otoh #closeTo: is too strict in this case anyway and eg Point has therefore its own #closeTo:. so perhaps that shortcoming, that one needs to give non-Numbers its own #equalsTo:, is acceptable?
werner

On Wed, May 4, 2016 at 9:47 PM, Nicolas Cellier <[hidden email]> wrote:
Hi Werner,
if we are perpetually reinventing the wheel, life is easy: I just have to perpetually exhume old bug reports ;)
http://bugs.squeak.org/view.php?id=6729
http://bugs.squeak.org/view.php?id=7368

I would attack the asFloat defense with:

(999e1000 relativelyEqualsTo: 998e1000 upTo: 1/100) which I expect to be true

Maybe something closer to closeTo:, just without hardcoded relative precision.

2016-05-04 19:58 GMT+02:00 werner kassens <[hidden email]>:
Hi Nicolas,
<g> this is funny indeed. what do think about this change:
Number>>relativelyEqualsTo: aNumber upTo: aSmallNumber
        "compare to Float>>closeTo:
        generally called from Number>>equalsTo:
        (c) Copyrights Didier BESSET, 1999, all rights reserved.
        Initial code: 21/4/99 "
    | norm |
    norm := self abs max: aNumber abs.
    ^norm <= DhbFloatingPointMachine new defaultNumericalPrecision
        or: [ (self - aNumber) abs asFloat < ( aSmallNumber * norm)]

just the #asFloat added. would that still be buggy?
werner

On Wed, May 4, 2016 at 4:32 PM, Nicolas Cellier <[hidden email]> wrote:
try this snippet:

Float fmax asInteger * (3/2) equalsTo: 0

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

werner kassens-2

Re: equalsTo: is naive

In reply to this post by werner kassens-2

Hi,
there was an obvious slip of the pen in my last proposal insofar as i used defaultNumericalPrecision instead of aSmallnumber, but when i tried to make a test for equalsTo: i noticed another problem in my proposal. hence some tests:
Float fmax asInteger * (3/2) equalsTo: 0. "false"
999e1000 relativelyEqualsTo: 998e1000 upTo: 1/100. "true"
-1/200 relativelyEqualsTo: 1/200 upTo: 1/100. "false"
1/200 relativelyEqualsTo: -1/200 upTo: 1/100. "false"
1/100 relativelyEqualsTo: 0 upTo: 1/100. "true"
0 relativelyEqualsTo: 1/100 upTo: 1/100. "true"
-1/100 relativelyEqualsTo: 0 upTo: 1/100. "true"
0 relativelyEqualsTo: -1/100 upTo: 1/100. "true"
the problem was that small positive and negative numbers were equal and i guess that shouldnt be so or algos that use equalsto: can get nonsense results. so perhaps this version would be better?
Number>>relativelyEqualsTo: aNumber upTo: aSmallNumber
        "similar to Float>>closeTo:
        generally called from Number>>equalsTo:"
    | norm |
    ^((norm := self abs max: aNumber abs) <= aSmallNumber
            and:[(self sign negated ~= aNumber sign)])
                or: [self = aNumber asFloat
                    or: [(self - aNumber) abs / norm < aSmallNumber]]

what do you think?

On Thu, May 5, 2016 at 12:27 PM, werner kassens <[hidden email]> wrote:

Hi Nicolas,
i see <g> the region is plastered with pitfalls and you already gave some serious thoughts to them. so yes, something closer to #closeTo:

Number>>relativelyEqualsTo: aNumber upTo: aSmallNumber
        "compare to Float>>closeTo:
        generally called from Number>>equalsTo:
        (c) Copyrights Didier BESSET, 1999, all rights reserved.
        Initial code: 21/4/99 "
    | norm |
    (norm := self abs max: aNumber abs)
        <= DhbFloatingPointMachine new defaultNumericalPrecision ifTrue:[^true].
    ^self = aNumber asFloat
        or: [(self - aNumber) abs / norm < aSmallNumber]

what about that?
the problem of comparisons with non-Numbers, that #closeTo: catches, is obviously still there. i had added #equalsTo: to DhbMatrix, DualNumber, SequenceableCollection etc, but i have to admit eg not yet to Complex. otoh #closeTo: is too strict in this case anyway and eg Point has therefore its own #closeTo:. so perhaps that shortcoming, that one needs to give non-Numbers its own #equalsTo:, is acceptable?
werner

On Wed, May 4, 2016 at 9:47 PM, Nicolas Cellier <[hidden email]> wrote:
Hi Werner,
if we are perpetually reinventing the wheel, life is easy: I just have to perpetually exhume old bug reports ;)
http://bugs.squeak.org/view.php?id=6729
http://bugs.squeak.org/view.php?id=7368

I would attack the asFloat defense with:

(999e1000 relativelyEqualsTo: 998e1000 upTo: 1/100) which I expect to be true

Maybe something closer to closeTo:, just without hardcoded relative precision.

2016-05-04 19:58 GMT+02:00 werner kassens <[hidden email]>:
Hi Nicolas,
<g> this is funny indeed. what do think about this change:
Number>>relativelyEqualsTo: aNumber upTo: aSmallNumber
        "compare to Float>>closeTo:
        generally called from Number>>equalsTo:
        (c) Copyrights Didier BESSET, 1999, all rights reserved.
        Initial code: 21/4/99 "
    | norm |
    norm := self abs max: aNumber abs.
    ^norm <= DhbFloatingPointMachine new defaultNumericalPrecision
        or: [ (self - aNumber) abs asFloat < ( aSmallNumber * norm)]

just the #asFloat added. would that still be buggy?
werner

On Wed, May 4, 2016 at 4:32 PM, Nicolas Cellier <[hidden email]> wrote:
try this snippet:

Float fmax asInteger * (3/2) equalsTo: 0

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

werner kassens-2

Re: equalsTo: is naive

Hi Nicolas,
i sometimes have the tendency to overcomplicate simple things, and im unsure whether one should simply omit the "and:[(self sign negated ~= aNumber sign)]" part (i would perhaps omit it and let small numbers with unequal sign be equal). what is your opinion?

werner

On Wed, May 11, 2016 at 12:23 PM, werner kassens <[hidden email]> wrote:

Hi,
there was an obvious slip of the pen in my last proposal insofar as i used defaultNumericalPrecision instead of aSmallnumber, but when i tried to make a test for equalsTo: i noticed another problem in my proposal. hence some tests:
Float fmax asInteger * (3/2) equalsTo: 0. "false"
999e1000 relativelyEqualsTo: 998e1000 upTo: 1/100. "true"
-1/200 relativelyEqualsTo: 1/200 upTo: 1/100. "false"
1/200 relativelyEqualsTo: -1/200 upTo: 1/100. "false"
1/100 relativelyEqualsTo: 0 upTo: 1/100. "true"
0 relativelyEqualsTo: 1/100 upTo: 1/100. "true"
-1/100 relativelyEqualsTo: 0 upTo: 1/100. "true"
0 relativelyEqualsTo: -1/100 upTo: 1/100. "true"
the problem was that small positive and negative numbers were equal and i guess that shouldnt be so or algos that use equalsto: can get nonsense results. so perhaps this version would be better?
Number>>relativelyEqualsTo: aNumber upTo: aSmallNumber
        "similar to Float>>closeTo:
        generally called from Number>>equalsTo:"
    | norm |
    ^((norm := self abs max: aNumber abs) <= aSmallNumber
            and:[(self sign negated ~= aNumber sign)])
                or: [self = aNumber asFloat
                    or: [(self - aNumber) abs / norm < aSmallNumber]]

what do you think?