operator overloading

[Mark Space]

That's almost(*) the amount of overloading, that I'd be happy with.

I mentioned it in other subthreads a few times: only arithmetic
operations for scalar types.

Yes, sorry if I just retyped someone else's suggestion. I thought I had
seen this (only java.lang.Number and subclasses) idea before, but I
couldn't be sure.

Anyway, these suggestions sound very reasonable and well scoped. This
would be ok with me.

 

[Mark Space]

How do people feel about overloading "[]" and ".length", so that List
and array code would be more similar? An ordered sequence type would
provide implementations for ".length", "[]" as get(), and "[]" as set().

"length" confuses me because it's not an operator. Also I don't see
much readability difference between "length" and "length()". (Or
"size()" for that matter.)

[] is interesting. Perhaps only for subclasses of AbstractSet,
AbstractList and AbstractMap?

There's still the decision for what type(s) get() and set() take. Ints?
Parameterized types? How many? "set()" for Set and List might be
different. Hmm, actually I don't think set() works for Set

Set<Integer> sieve = //...
sieve[2] = // ...??

Don't know about that. Using add and remove might be much clearer.
"get()"'s ok, it should return true or false depending if the object is
present in the set.

if( sieve[3] )
{
// do something
}

 

[Patricia Shanahan]

Patricia Shanahan wrote :

Ok, this appears to be used as a utility method, therefore I would make
it static with the method returning the result of the formulae
calculation. The class could be named MyMath. So:

BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm,
termLimit, difference);

So what does the code inside seriesSum look like? Remember this is just
a *very* simple example of the sort of thing that shows up all over
engineering and scientific programs.

Patricia

 

[Mark Thornton]

Patricia Shanahan wrote:

Can we have some set of operators that you feel you really need, and
some that would be just "nice to have?" Are their any that you
definitely do not need to overload?

Essential:

Binary operators: +,-,*,/
Unary operators: +,-


On BigInteger, BigDecimal, and complex (float and double forms).

Plus comparison operators (<, <=, ==, !=, >=, >) and remainder (%) on
Big*, but not complex values.

Very nice to have:
[] operator for matrix element access.

That would be it. Interval arithmetic and rational numbers would be nice
too, but neither is in widespread use. So I would just do the set above
and not implement user overloading of operators.

Mark Thornton

 

[Mark Thornton]

Patricia Shanahan wrote :

Ok, this appears to be used as a utility method, therefore I would make
it static with the method returning the result of the formulae
calculation. The class could be named MyMath. So:

BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm,
termLimit, difference);

I think you have missed the point. It is just a fragment of code and we
don't want to turn every such fragment into a method of its own. It is
also on the very simple end of mathematical expressions.

Mark Thornton

 

[Wojtek]

Mark Thornton wrote :

I think you have missed the point. It is just a fragment of code and we don't
want to turn every such fragment into a method of its own. It is also on the
very simple end of mathematical expressions.

Also to Patricia,

The series sum is a pure math operation, and would not need operator
overloading.

And yes, I WOULD create a library with these types of calls. It makes
using them in multiple places consistent. I would encase it even for a
single use as it makes cleaner code at the point of usage.

What the formula is like in the method is up to the author. Black box
testing should prove that the formula implementation is correct. If you
do not have trust in the author, then extend the library class and
override the method with your own implementation.

But that is always the risk in using someone elses library for
everything from high math formula to common string operations. The
assumption is that it works until proven false. If you are using the
library for mission critical use (life critical, million dollar
critical) then you would perform extensive testing before it was
trusted.

Maybe I am missing the point with this series sum formula. It just
seems obvious to me to encase it in a method, prove it, then just use
it.

And how it relates to operator overloading mistifies me.

 

[Patricia Shanahan]

Mark Thornton wrote :

Also to Patricia,

The series sum is a pure math operation, and would not need operator
overloading.

Suppose the arithmetic series is a series of BigDecimal? I have yet to
see a version without infix arithmetic operators that is as clear, and
as obviously equivalent to the referenced formula.

And yes, I WOULD create a library with these types of calls. It makes
using them in multiple places consistent. I would encase it even for a
single use as it makes cleaner code at the point of usage.

What the formula is like in the method is up to the author. Black box
testing should prove that the formula implementation is correct. If you
do not have trust in the author, then extend the library class and
override the method with your own implementation.

I believe in defense in depth against errors. Yes, I do black box
testing, but I also want to be able to write the code with low risk of
error, and desk check it with high probability of seeing any errors. In
the case of the Java representation of a mathematical formula, that
includes checking that the code is equivalent to the formula.

Libraries only push the problem back a layer. Someone has to write the
library method. Ideally, at least one colleague will review it. Someone
has to maintain it. Their ability to do so efficiently depends on the
readability of the library implementation.

Patricia

 

[Joshua Cranmer]

I agree. I don't think operator overloading should be taken to anything
like the degree it is done in C++. In particular, I would be strongly
opposed to overloading "=". Almost all the value lies in better
representation of arithmetic expressions whose operands are references
to immutable objects.

What about operator&& or operator,? And C++ didn't go all the way:
imagine operator?: . Now THAT would make for some fun obfuscations.

How do people feel about overloading "[]" and ".length", so that List
and array code would be more similar? An ordered sequence type would
provide implementations for ".length", "[]" as get(), and "[]" as set().

To me, the presence of a pseudo-variable `.length' feels as if it could
be modifiable. I'm not heavily committed one way or the other on
overloading `.length', although I would probably rather see an array get
a .size() or .isEmpty() "function" instead.

I quite often find myself changing my mind about whether an ordered
sequence of data should be a List or an array. That can lead to warts
such as using Arrays.asList so that I can go on using get() and set()
even after turning it into an array. The refactoring would be easier if
I could use the same code for the operations they have in common.

+1

 

[Mark Space]

Plus comparison operators (<, <=, ==, !=, >=, >) and remainder (%) on

== and != are the only ones that bother me. The other comparison
operators have no meaning on reference values, but == and != do.

I admit, I can't think of a good use for == for references (other than
inside a comparison operator to test for identity) but it would be kind
of irregular for the language to treat these differently.

I'm looking for a way around overloading those two, or at least a way to
distinguish testa for identity from a comparison of the object.

The other thing is absolutely everything uses equals() anyway, including
strings, so maybe specifically not overloading == and != might be ok.

And unlike, say num1.greaterThan( num2 ) you don't have to stop and
think about which way the operator (> in this case) should really point.
It's the same in both directions for .equals(). That is, num1.equals(
num2 ) and num2.equals( num1 ).

Just thinking out loud....

 

[Mark Thornton]

Mark Thornton wrote :

Also to Patricia,

The series sum is a pure math operation, and would not need operator
overloading.

And yes, I WOULD create a library with these types of calls. It makes
using them in multiple places consistent. I would encase it even for a
single use as it makes cleaner code at the point of usage.

What the formula is like in the method is up to the author. Black box
testing should prove that the formula implementation is correct. If you
do not have trust in the author, then extend the library class and
override the method with your own implementation.

But that is always the risk in using someone elses library for
everything from high math formula to common string operations. The
assumption is that it works until proven false. If you are using the
library for mission critical use (life critical, million dollar
critical) then you would perform extensive testing before it was trusted.

Maybe I am missing the point with this series sum formula. It just seems
obvious to me to encase it in a method, prove it, then just use it.

I think that James Gosling has observed that people who are not
mathematicians/engineers almost invariably miss the point with regard to
the desireability of operator overloading at least for complex
arithmetic. In part I think it is the expression itself, in STANDARD
form, which is recognised, not the name which you might give it. Others
have said that the language of mathematicians is not
English/French/German or any other natural language but symbolic with
centuries of history. Its representation in software is necessarily
approximate, but words are not the answer. Or at least not the answer
desired by mathematicians.
Does forcing the use of words make the result more comprehensible to non
mathematicians? In my experience the answer is no, the code remains as
black box as ever to those without sufficient maths background.

Mark Thornton

 

[Wojtek]

Patricia Shanahan wrote :

Suppose the arithmetic series is a series of BigDecimal? I have yet to
see a version without infix arithmetic operators that is as clear, and
as obviously equivalent to the referenced formula.

A light shines...

Yes, that would be a bit awkward.

I would probably break down the formula into a series of discrete
steps, each on its own line, along with a lot of comments of what is
really going on.

But that would not look like the formula.

I believe in defense in depth against errors. Yes, I do black box
testing, but I also want to be able to write the code with low risk of
error, and desk check it with high probability of seeing any errors. In
the case of the Java representation of a mathematical formula, that
includes checking that the code is equivalent to the formula.

Libraries only push the problem back a layer. Someone has to write the
library method. Ideally, at least one colleague will review it. Someone
has to maintain it. Their ability to do so efficiently depends on the
readability of the library implementation.

Test, test, test, then test again

 

[Patricia Shanahan]

Mark Thornton wrote:
....

I think that James Gosling has observed that people who are not
mathematicians/engineers almost invariably miss the point with regard to
the desireability of operator overloading at least for complex
arithmetic. In part I think it is the expression itself, in STANDARD
form, which is recognised, not the name which you might give it. Others
have said that the language of mathematicians is not
English/French/German or any other natural language but symbolic with
centuries of history. Its representation in software is necessarily
approximate, but words are not the answer. Or at least not the answer
desired by mathematicians.

....

Although I've spent most of my life as a software or hardware developer,
my bachelor's degree was in mathematics. That may explain some of my
thinking on this subject. To me, the mathematical formula is the
clearest, most understandable representation. The closer the computer
program representation gets to that, the better.

Patricia

 

[Wojtek]

Mark Thornton wrote :

Does forcing the use of words make the result more comprehensible to non
mathematicians? In my experience the answer is no, the code remains as black
box as ever to those without sufficient maths background.

Programming always is abstracted from reality.

And translation between the real world and code can be a real
challenge.

For most projects I can learn enough from the SME to be able to mimic
what they think they want.

But real mathematics is still a mystery to me. I can break down
relatively simple formulas like the series sum above, but I know my
limits.

And I think I have changed my mind about operator overloading, but only
as defined by the language rather than a free-for-all.

So things like:

Double a = new Double(5.0);
Double b = new Double(7.5);
Double c = a + b;

would be allowed as it relates to numbers. Programmer defined operator
overloading would be forbidden like it is now.

 

[Mark Thornton]

== and != are the only ones that bother me. The other comparison
operators have no meaning on reference values, but == and != do.

They are indeed a problem. Apart from comparison to null (another
awkward case) there are no good reasons for using reference equality
with BigInteger/BigDecimal or any of the primitive wrappers.
Nevertheless the language currently allows it, so no doubt some
programmers have done so.

Mark Thornton

 

[Patricia Shanahan]

Mark Thornton wrote :

Programming always is abstracted from reality.

And translation between the real world and code can be a real challenge.

For most projects I can learn enough from the SME to be able to mimic
what they think they want.

But real mathematics is still a mystery to me. I can break down
relatively simple formulas like the series sum above, but I know my limits.

And I think I have changed my mind about operator overloading, but only
as defined by the language rather than a free-for-all.

So things like:

Double a = new Double(5.0);
Double b = new Double(7.5);
Double c = a + b;

would be allowed as it relates to numbers. Programmer defined operator
overloading would be forbidden like it is now.

Without programmer defined operator overloading, the language has to
define all the arithmetic types. Currently, it is missing, as language
features, complex (based on each of float and double), rational, and
interval arithmetic.

Of those, complex is the most basic and essential. Fortran has supported
it, as the equivalent of a Java primitive type, for decades.

Patricia

 

[Mark Thornton]

I would probably break down the formula into a series of discrete steps,
each on its own line, along with a lot of comments of what is really
going on.

Whereas a mathematician would see it as elementary and not requiring
further comment. From memory my copy of A&S lists that formula in
chapter 1 without much comment.

Mark Thornton

P.S. A&S = Abramowitz and Stegun, Handbook of mathematical formula.

 

[Mark Thornton]

Mark Thornton wrote:
...
...

Although I've spent most of my life as a software or hardware developer,
my bachelor's degree was in mathematics. That may explain some of my
thinking on this subject. To me, the mathematical formula is the
clearest, most understandable representation. The closer the computer
program representation gets to that, the better.

Patricia

Agreed,

Mark Thornton
(PhD, Applied Mathematics)

 

[Mark Thornton]

Without programmer defined operator overloading, the language has to
define all the arithmetic types. Currently, it is missing, as language
features, complex (based on each of float and double), rational, and
interval arithmetic.

Of those, complex is the most basic and essential. Fortran has supported
it, as the equivalent of a Java primitive type, for decades.

Patricia

Adding complex (and perhaps rational) as primitives would be the
simplest pragmatic solution and deal with perhaps 90% of the well
justified requirements for operator overloading. Of course it offends
against principal as these types are undeniably composites of other
primitives.

Mark Thornton

 

[Tom Anderson]

Adding complex (and perhaps rational) as primitives would be the
simplest pragmatic solution and deal with perhaps 90% of the well
justified requirements for operator overloading.

I disagree with you and Patricia here: i suspect that many, many more
people would use Vector3D than Complex. Who uses complex numbers anyway?
Just crazy maths types. Vector3D would turn up every time anyone did 3D
graphics or any kind of 3D spatial work.

Unless you're thinking of using Complex as a Vector2D, which you could.
Then, it might be more popular than Vector3D.

Of course it offends against principal as these types are undeniably
composites of other primitives.

Careful - that sounds like an argument for removing every primitive except
boolean! And, if we get closures, even that.

tom

 

[Patricia Shanahan]

Tom Anderson wrote:
....

I disagree with you and Patricia here: i suspect that many, many more
people would use Vector3D than Complex. Who uses complex numbers anyway?
Just crazy maths types. Vector3D would turn up every time anyone did 3D
graphics or any kind of 3D spatial work.

....

Actually, in my experience it is more "practical engineer types" than
"crazy maths types". Of course, anyone who really cares about this is
likely to be someone who thinks in mathematical formulas, but that
applies to a lot of engineers.

Given their origin as a way of simplifying the rules for the numbers of
roots of polynomials, complex numbers turned out to be surprisingly useful.

Patricia