First class developer: who ?
in [Java Help]
|
Prev: Speaking of thread safety?
Next: solutions manual to A First Course In Probability 7th Edition by Sheldon M. Ross
From: Arne Vajhøj on 12 Mar 2010 19:58 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); } } Arne
From: Arne Vajhøj on 12 Mar 2010 20:02 On 11-03-2010 23:35, BGB / cr88192 wrote: > personally, I think many people overstate the role of math in programming in > some ways: > when ever was the last time programmers had to seriously invest time in > things like solving polynomials or writing proofs. > > these are some of the core elements of traditional math: > they spend all ones' earlier years forcing off solving on people, and then > later expect them to write proofs. > > but, usually the programmer has little need or reason to care: > it matters instead that things work, and that they can get the job done, and > nearly all else is secondary. > > the more "advanced" programmer may find themselves messing with issues which > are NOT matters of solving and/or proofs, but more a world often consisting > of endless piles of repetition and boilerplate... > > so, it would seem there is a disconnect somewhere. > > to the worlds of C, C++, and Java, traditional Math is an alien landscape, > neither sensible nor often particularly relevant... (and those few things > which are relevant are often those things Mathematicians like to sweep into > the corners...). I completely disagree. Developers that google solutions and copy paste them and generally consider the computer a black box may not use math. But developers that like to understand what they are doing and why will be thinking math every hour at work whether they realize it or not. Picking correct collection based on big O characteristics and using relational databases are extremely common. Both build on a strong mathematical foundation. Arne
From: Martin Gregorie on 12 Mar 2010 20:33 On Fri, 12 Mar 2010 20:02:01 -0500, Arne Vajhøj wrote: > Developers that google solutions and copy paste them and generally > consider the computer a black box may not use math. > No argument here. > But developers that like to understand what they are doing and why will > be thinking math every hour at work whether they realize it or not. > Here we diverge. Despite spending my working life in IT, I'm a scientist by training, not a mathematician. I work on the principle that a software design is a hypothesis from which true and false predictions can be made. Code written to implement the design is then exhaustively tested against the predictions to verify the correctness of the design. There's a nod to maths rolled in too: I use inductive proofs to generate tests of normal operation rather than exhaustive scans of the entire valid operation space. The aforesaid true predictions generate corner tests and the false predictions become error handling tests. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Arved Sandstrom on 12 Mar 2010 21:08 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); > } > } > > Arne I do consider == to be equality (identity). Same object for references, same value for primitives...that's equality. 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 ==. AHS
From: Arne Vajhøj on 12 Mar 2010 21:33
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. > 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 ==. Arne |