Inequality of numerical values of different types

[Siskin-Bot]

Submitted by: meijeru

I know there has been a blog discussion on equality, and some new proposals are forthcoming to (re-)define =, == and =? (plus a fourth one perhaps), but I cannot help feeling uneasy with the simplest and most forgiving of these: equality (as in =) applied to the numerical types (number! and money!) which are similar enough to be freely convertible

see the code for observed behaviour; BTW it works with any integer number, not only 0

>> 0 = 0.0   ; true (also 0.0 = 0% and 0.0 = $0)
>> 0 != 0%   ; true (also 0 != $0, but 0% = $0)
;; thus, e.g.
>> 0 > 0%    ; false
>> 0 < 0%    ; false
>> 0 = 0%    ; false
;; none of the three yields true, this might be awkward
;; in case statements which rely on exactly one of them being true

---

^{Imported from: CureCode [ Version: alpha 66 Type: Bug Platform: All Category: Datatype Reproduce: Always Fixed-in:alpha 69 ]
Imported from: metaeducation#1046}

Comments:

Rebolbot commented on Jul 2, 2009:

Submitted by: BrianH

This should be taken into account when the equality operations are revamped. Changed to a Bug.

---

Rebolbot commented on Jul 2, 2009:

Submitted by: meijeru

It is actuall worse than I tought:

>> 0% = 0 ; true
>> 0 = 0% ; false

---

Rebolbot commented on Jul 7, 2009:

Submitted by: meijeru

See also #952

---

Rebolbot commented on Jul 7, 2009:

Submitted by: Carl

In order to get define all possible combinations, we need a series of tests that specify those combinations. That's the only way we can get this done right.

---

Rebolbot commented on Jul 15, 2009:

Submitted by: meijeru

This ticket can now be closed (I could do it myself, but that would be abusing a loophole in Curecode (see ALTME posting by BrianH).

---

Rebolbot commented on Jul 15, 2009:

Submitted by: BrianH

Determined the build where this was fixed (it could have been 69 or 70) and marked as tested.

We finally have a policy for when to mark a ticket as complete, and for Bug tickets that is when the conditions in question have tests added to verify them in the standard test suite. Since the standard test suite isn't quite standardized yet (we're working on it), this ticket shouldn't be marked as closed. For that matter, some of the other tickets that have already been marked as closed are not appropriately so. Reviewing the tested and closed tickets is on the todo list.

There's more to reviewing than just flipping a few settings :)

---

Rebolbot mentioned this issue on Jan 12, 2016:
zero TIME! equal and equivalent to INTEGER! zero, but only in one direction

---

Rebolbot added Type.bug and Test.written on Jan 12, 2016

---