Java 7 features

[~kurt]

Circa 1999 Bill Joy told me that was high on his list. Though he was
hoping for a more generic way of doing it so you could handle similar
problems efficiently. That way you could have an array of Complex
but the objects would be lined up right after each other, rather than
scattered around RAM with an array of pointers to them.

Interesting.

Well, even something no so efficient would probably be better than
having to create objects and not be able to use standard operators
on them.

- Kurt

 

[Twisted]

How about complex numbers as a primitive type?

Can anyone spell "feeping creature"?

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Twisted schreef:

Can anyone spell "feeping creature"?

Uh, no?

Not that I’d need complex numbers. Lisp has them, if you want.

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGnM6Ge+7xMGD3itQRAvMhAJoCQ5EDrMWIun6816X2S6mxu3JmFACdH95s
u10R0VjojcIQKj6lwVSpKdg=
=DUVs
-----END PGP SIGNATURE-----

 

[~kurt]

Can anyone spell "feeping creature"?

You would call complex numbers an unnecessary feature considering all the
other BS that Java has built into it? Unnecessary would probably be
along the lines of making it too general supporting hypercomplex numbers
(like quaternions). Really, it would be nice to be able to '+', '-', etc...,
complex primitives just like other numbers.

You computer scientists - don't seem to remember what computers were really
made for....

- Kurt

 

[Lew]

You computer scientists - don't seem to remember what computers were really
made for....

Accessing porn sites?

 

[Joshua Cranmer]

You computer scientists - don't seem to remember what computers were
really made for....

- Kurt

Let's see, the first use I can think of would be to tabulate the 1890
census, so for basic statistics?

Or maybe you're referring to ENIAC, which would be calculating firing
tables for ammunition, so basic classical mechanics?

Calculating tedious logarithms?

Adding/subtracting/multiplying/dividing/exponentiating floating point
numbers?

How about the personal computer -> i.e., basic word processing?

How much of those require computing complex numbers?

 

[~kurt]

Let's see, the first use I can think of would be to tabulate the 1890
census, so for basic statistics?

Didn't know about that one (or didn't remember).

Or maybe you're referring to ENIAC, which would be calculating firing
tables for ammunition, so basic classical mechanics?

That is what I was thinking of.

Calculating tedious logarithms?

Adding/subtracting/multiplying/dividing/exponentiating floating point
numbers?

How about the personal computer -> i.e., basic word processing?

How much of those require computing complex numbers?

Scientific/mathematical work benefits from having complex numbers. Modeling
and simulation, control theory, etc, come to mind immediately. As you have
pretty much pointed out, science and math are what computers were created for.
Everything else is just useless fluff that has not done much more for us
as a whole than find additional ways to become less productive and waste
more time (granted, the easy access to porn is not a waste of time). OK,
word processors are a lot nicer and more useful than the typewriter - I can
admit that.

I know, once C# adds complex numbers, we will finally see it in Java.
I'll have to start pestering Microsoft....

- Kurt

 

[Patricia Shanahan]

~kurt wrote:
....

I know, once C# adds complex numbers, we will finally see it in Java.
I'll have to start pestering Microsoft....

....

I think pestering for complex numbers is a bit misdirected. The more
general problem is all the numeric types other than those that Java
implements as primitives. Here are a few that I can remember:

BigInteger
BigDecimal
general rational numbers
extended precision IEEE 754 (useful e.g. for calculating constants for
64 bit precision functions).
interval arithmetic

Any of these would be more usable with infix notation instead of writing
unreadable stacks of method calls.

There used to be optimization reasons for preferring a built-in type to
a class with infix notation, but with method in-lining I'm not sure they
are still valid.

Patricia

 

[Roedy Green]

Accessing porn sites?

see http://mindprod.com/project/pornviewer.html

 

[Tim Slattery]

Didn't know about that one (or didn't remember).

That's what Herman Hollerith's punched cards were first used for.
Hollerith's company became IBM.

 

[Martin Gregorie]

Didn't know about that one (or didn't remember).


That is what I was thinking of.


Scientific/mathematical work benefits from having complex numbers. Modeling
and simulation, control theory, etc, come to mind immediately. As you have
pretty much pointed out, science and math are what computers were created for.
Everything else is just useless fluff that has not done much more for us
as a whole than find additional ways to become less productive and waste
more time (granted, the easy access to porn is not a waste of time). OK,
word processors are a lot nicer and more useful than the typewriter - I can
admit that.

I know, once C# adds complex numbers, we will finally see it in Java.
I'll have to start pestering Microsoft....

Rather than just adding another primitive data type, I'd prefer a more
general mechanism. IMO allowing user-defined operator overloading would
fit the bill provided only that it was implemented similarly to to the
way Algol 68 did it.

In Java terms that would require something like a modified class
declaration. Something like:

public operator +
{
public Complex op (Complex a, Complex b)
{
.....
}

...ETC...
}


Usage:

Complex a,b,c;
real x,y,z;

a = b + c;
x = y + z;

 

[Stefan Ram]

public operator +
{
public Complex op (Complex a, Complex b)

»+« is the name of that operator, like »println«
is the name of a method. We do not define that method as:

public method println
{ public void method( final java.lang.String string ) ... }

So this would deviate from the hitherto Java design.

My own preference would be the introduction of pair
classes, like:

public class( java.math.Complex, java.math.Complex )
{ public java.math.Complex +()
{ return new java.math.Complex
( this.0.real + this.1.real,
this.0.imah + this.1.imag ); } ... }

The name of this class would be:

»( java.math.Complex, java.math.Complex )«

Such an product class would be allowed, whenever an extension
of each of the factor classes is allowed.

The product class has access to all fields of each factor
class (i.e., java.math.Complex) that an extension would be
allowed to access.

The product class is responsible for all operations on a pair
of complex numbers.

The expression

»a + b«

would behave as if a pair (a, b) of this class would be
constructed and then has »+« invoked on the pair, even though
the implementation is free not to really create such a pair
object on the heap for efficiency.

See also

http://blogs.sun.com/jrose/entry/tuples_in_the_vm

 

[Martin Gregorie]

»+« is the name of that operator, like »println«
is the name of a method. We do not define that method as:

public method println
{ public void method( final java.lang.String string ) ... }

So this would deviate from the hitherto Java design.

My own preference would be the introduction of pair
classes, like:

public class( java.math.Complex, java.math.Complex )
{ public java.math.Complex +()
{ return new java.math.Complex
( this.0.real + this.1.real,
this.0.imah + this.1.imag ); } ... }

The name of this class would be:

»( java.math.Complex, java.math.Complex )«

Such an product class would be allowed, whenever an extension
of each of the factor classes is allowed.

The product class has access to all fields of each factor
class (i.e., java.math.Complex) that an extension would be
allowed to access.

The product class is responsible for all operations on a pair
of complex numbers.

The expression

»a + b«

would behave as if a pair (a, b) of this class would be
constructed and then has »+« invoked on the pair, even though
the implementation is free not to really create such a pair
object on the heap for efficiency.

See also

http://blogs.sun.com/jrose/entry/tuples_in_the_vm

I have no real argument with this approach.

I was thinking that if the operator was defined as a class equivalent
then the base operator 'methods' would define the base use of the
operator (and would be added to the java.lang package) and the 'extends'
keyword could be used to add arbitrary overloading to it by defining
additional methods.

 

[Christian]

~kurt wrote:
In Java terms that would require something like a modified class
declaration. Something like:

public operator +
{
public Complex op (Complex a, Complex b)
{
.....
}

...ETC...
}


Usage:

Complex a,b,c;
real x,y,z;

a = b + c;
x = y + z;

uuuh why so ugly ?

why not just add an interface to the api

public interface Addable<T> {
T add(T t1 , T t2);
}

and allow any implementing class to be used with + operator..

I think we don't really need some more syntax for the bits of operator
overloading that is acceptable and sometimes useful..


Christian

 

[Twisted]

The expression

»a + b«

would behave as if a pair (a, b) of this class would be
constructed and then has »+« invoked on the pair, even though
the implementation is free not to really create such a pair
object on the heap for efficiency.

And as a result, the method better not modify either argument. So your
suggestion effectively implies sneaking in "const" through the back
door. (But what about "notnull"?)

 

[pkriens]

@ Closures

Only if done properly:
- correct return semantics (return from closure == return from
enclosing function)
- full access to local variables of the enclosing scopes
- efficient (i.e. not inner classes)

@ Strings in switch statements
@ Operator overloading for BigDecimal

Seems weird in Java to treat certain objects more equal than others?
Or make it a model where any object can be used or forget it. These
special cases are always error prone and hard to teach.

@ Language-level XML support

And when we are at it, lets add embedded SQL! :-(

@ Reified generics

Well, guess it makes sense if you like generics.

@ Superpackages

The current way they intend to implement it sucks, you get the
information in 2 places (a central new type class file and in each
member class file). It is an interesting idea but the redundancy is
going to hurt. Not sure if it is worth it. Using runtime modules like
OSGi or maybe in the future JSR 277 work fine for me, they also allow
you to change membership in deployment which can be interesting if you
have to support different environments.

@ Removing checked exceptions

Yes! Checked exceptions were the worst idea since stale bread.
Exceptions are perfect, but forcing a programmer to catch 15
exceptions only to wrap them in a 16th exception and throw it again is
dumb. There is a lot of bad API design out there because checked
exceptions.

Kind regards,

Peter Kriens

 

[nebulous99]

No!

Checked exceptions were the worst idea since stale bread.

Very original, and unfortunately very wrong.

Exceptions are perfect, but forcing a programmer to catch 15
exceptions only to wrap them in a 16th exception and throw it again is
dumb. There is a lot of bad API design out there because checked
exceptions.

Actually, there is a lot of catching and rethrowing out there because
of bad API design.

It's good and proper that the compiler tells you you should have a
strategy in place to handle I/O failure when you have finished writing
your I/O code, and things of that nature.

Having to catch and rethrow can be because of a bad API design where
an interface didn't specify likely exceptions.

Or it can actually mean nothing, in cases where a layer change means
the problem and solution language space changes and the exceptions
specific to the lower layer really should be transformed into
exceptions semantically meaningful in the context of the upper layer.

Unfortunately there seems to be no simple way to allow exception
throwing behavior to be parametrized in a generics-like fashion
without the result being a semantic and syntactic nightmare.

 

[Lew]

Very original, and unfortunately very wrong.


Actually, there is a lot of catching and rethrowing out there because
of bad API design.

It's good and proper that the compiler tells you you should have a
strategy in place to handle I/O failure when you have finished writing
your I/O code, and things of that nature.

Meaning that it is good and proper that the API designer contracted the client
to recognize those checked exceptions.

Having to catch and rethrow can be because of a bad API design where
an interface didn't specify likely exceptions.

Or specified too many, to address the OP's example. You are accurate to blame
the API design for this type of error; it's not Java's fault but the API author's.

Or it can actually mean nothing, in cases where a layer change means
the problem and solution language space changes and the exceptions
specific to the lower layer really should be transformed into
exceptions semantically meaningful in the context of the upper layer.

Excellent use case for exceptions.

Unfortunately there seems to be no simple way to allow exception
throwing behavior to be parametrized in a generics-like fashion
without the result being a semantic and syntactic nightmare.

Twisted is absolutely correct down the line, except that I don't really mind
the way exceptions are generified currently. I also hope that the
implementation of closures (another bit of highly-demanded but questionably
practical fluff to add to Java) would address Exceptions in a fashion to avoid
that "nightmare".

Checked exceptions are an interface element put in place by the API designer.
If you don't like the "15 exceptions" that a method throws, blame the
programmer, not the language. It is useful to be able to declare checked
exceptions to force API clients to deal with them.

Every objection I've seen to checked exceptions has been rooted in laziness,
taken entirely from the API client's point of view. From the API author's
POV, checked exceptions are a way to prevent client-programmer laziness and
are invaluable. Let the lazy whine. Guess what? You have to check for
exceptions whether they're checked or not; checked means the compiler helps
you. Stop being lazy and use them properly.

 

[nebulous99]

If you don't like the "15 exceptions" that a method throws, blame the
programmer, not the language. It is useful to be able to declare checked
exceptions to force API clients to deal with them.

Or even blame yourself. If the API designer was at all intelligent
there be a single exception superclass of the 15 that doesn't catch
much else, e.g. it throws 15 varieties of IOException. You can just
catch IOException instead of all of the different subtypes in this
case. Of course if the API designer throws 15 various
TwiddleSticksFoobar related exception varieties and there's no common
TwiddleSticksFoobarException superclass then the API design is
boneheaded. If its client contract has nothing to do with parsing but
simply with accessing an abstract persistent store, a bunch of XML
exception throws clauses is a bad sign -- it should really translate
those into something like a FudgewobblyDataCorruptException clearly
related to its own purpose with the XML exceptions wrapped as "cause"
exceptions, and throw the same exception type if it hits something
that throws NumberFormatException, etc. while reading in the data. All
of these specific exceptions from the data-slurping layer mean "the
file is mangled and unreadable, no longer well-formed, kaputnik" after
all.

 

[Joshua Cranmer]

uuuh why so ugly ?

why not just add an interface to the api

public interface Addable<T> {
T add(T t1 , T t2);
}

and allow any implementing class to be used with + operator..

That means that you would be calling:

Addable<T> T1, T2, T3;
// initialize
T1.add(T2,T3);

For various reasons, operator overloading tends to work better as a
global method with the lhs and rhs as arguments. This is because M1 * 5
logically equals 5 * M1 but 5, being a primitive type, cannot have an
operator*(M) function. The hard part is trying to figure out where to put
this global method given Java's class model.