Re: First class developer: who ?



Arne Vajhøj wrote:
On 12-03-2010 21:08, Arved Sandstrom wrote:
Arne Vajhøj wrote:
On 12-03-2010 05:26, Arved Sandstrom wrote:
Both terms actually have clear English meanings - "equality" means (or
should mean) that two things *are* the same, and "equivalence" means (or
should mean) that two things can be substituted, that they behave the
same way.

A mathematical and CS definition in fact tracks the common English
meanings of these 2 words, and the language concerning Object.equals
that Patricia quoted does say exactly this: equals is an implementation
of equivalence.

My point is that the common English, the mathematical and the CS
definitions of the two terms are pretty much the same. And programming
languages that differentiate between the two also track those
definitions. We see that Java does.

I don't think Java follow those rules.

I assume that you consider equals to be equivalence and
== to be equality.

But it is not so.

Example:

public class ZZ {
public static void main(String[] args) {
int iv = 2;
double xv = 2.0;
System.out.println(iv == xv);
}
}

I do consider == to be equality (identity). Same object for references,
same value for primitives...that's equality.

But 2 and 2.0 are not identity equals.

No, but as I indicate I don't see that we ever compared 2 and 2.0 for identity in your example. You can't do that with direct use of ==, because of promotion.

This is one of the C-based hiccups of Java. For primitives of different types we shouldn't even be asking the question ==?

An implementation of equals() I consider to be _an_ implementation of an
equivalence relation; == is clearly another.

I'm not that perturbed by your example. Java == equality for primitives
of different types is what we define it to be, so defining it to be an
operation that takes place after primitive conversions is not wrong. In
effect we're not saying that (int 2) == (double 2.0), we're saying that
(double 2.0) == (double 2.0); the binary numeric promotion happened
before the ==.

That promotion is done by ==.

"Done by?" I don't see that. "Done on behalf of", sure. Unless a bytecode guru tells me otherwise I expect that == just like + is blissfully unaware that it could ever be asked to work with two primitives of differing types.

Now, if each binary operator duplicates all the numeric promotion logic I could see that they are responsible for it.

AHS
.



Relevant Pages

  • Re: An uncountable countable set
    ... equivalence class and the equivalence class itself. ... There is no other explanation for you ignoring that I have already said that finite theories with a finite number of primitives can only address a finite number of properties. ... and inductive proof. ... and it is not the set of defining PROPERTIES. ...
    (sci.math)
  • Re: Primitive Recursive Arithmetic and Computable Categories
    ... subsets of a third primitive C (w.r.t. C's equivalence). ... are A and B to be understood as primitives or as morphisms? ... The necessary equivalence relation of N_Q is give we will ... For theoretical examinations of computability this seems ...
    (sci.logic)
  • Re: Primitive Recursive Arithmetic and Computable Categories
    ... subsets of a third primitive C (w.r.t. C's equivalence). ... and B are given by primitive recursive characteristic functions C on ... are A and B to be understood as primitives or as morphisms? ... whose base set is chi_A^-1and whose equivalence relation matches ...
    (sci.logic)
  • Re: why () is () and [] is [] work in other way?
    ... primitives and '==' as identity comparison for objects, ... exactly know how one would do that in Python. ... It is as if Java tried to get rid of pointers but never completely succeeded in doing that. ... value equality defaults to identity equality but there are ...
    (comp.lang.python)
  • Re: So whats null then if its not nothing?
    ... to store truth values in the database, ... think it is very likely that he means equivalence in all cases. ... I don't think Codd ... A redefinition of equivalence, not equality. ...
    (comp.databases.theory)