Why Java's math expression (power) is so inconvenient and error prone?

Posted: 2006-10-31 3:02:00

java-programmer, Why Java's math expression (power) is so inconvenient and error prone? Hi,

My program need a lot of calculation of power. In many programming
languages,

2**3 = 8; //or
2^3 = 8;

The syntax is clean and easy. But in Java,

Math.pow(2, 3) = 8; //It is so long, and complicated and error prone

Again, in many languages,

EXP(1) = 2.7 //e value

But in Java,

Math.pow(Math.E, 1) = 2.7 //You see, so complicated

Normally, in one calculation, 2**3 or EXP(3.5) is only part of
expression, like "a + b**3 + EXP(-a)". In Java, it will be very long and
error prone!

Posted: 2006-10-31 3:03:00

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? Hi,

My program need a lot of calculation of power. In many programming
languages,

2**3 = 8;

The syntax is clean and easy. But in Java,

Math.pow(2, 3) = 8; //It is so long, and complicated and error prone

Again, in many languages,

EXP(1) = 2.7 //e value

But in Java,

Math.pow(Math.E, 1) = 2.7 //You see, so complicated

Normally, in one calculation, 2**3 or EXP(3.5) is only part of
expression, like "a + b**3 + EXP(-a)". In Java, it will be very long and
error prone!

Posted: 2006-10-31 3:43:00

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? Shawn wrote:
> Hi,
>
> My program need a lot of calculation of power. In many programming
> languages,
>
> 2**3 = 8; //or
> 2^3 = 8;

That may be short but your example illustrates the problem: lack of a
universal standard symbol (in ascii). Of course 2^3 already means
something else in Java.

>
> The syntax is clean and easy. But in Java,
>
> Math.pow(2, 3) = 8; //It is so long, and complicated and error prone

It may be longer but not error prone. You can eliminate the repeated use
of Math with static import:

import static java.lang.Math.*

then

pow(2,3)

>
> Again, in many languages,
>
> EXP(1) = 2.7 //e value
>
> But in Java,
>
> Math.pow(Math.E, 1) = 2.7 //You see, so complicated

Math.exp(1)

or with a static import, just

exp(1)

Mark Thornton

Posted: 2006-10-31 5:27:00

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? Shawn wrote:
> Hi,
>
> My program need a lot of calculation of power. In many programming
> languages,
>
> 2**3 = 8;
>
> The syntax is clean and easy. But in Java,
>
> Math.pow(2, 3) = 8; //It is so long, and complicated and error prone
>
> Again, in many languages,
>
> EXP(1) = 2.7 //e value
>
> But in Java,
>
> Math.pow(Math.E, 1) = 2.7 //You see, so complicated
>
> Normally, in one calculation, 2**3 or EXP(3.5) is only part of
> expression, like "a + b**3 + EXP(-a)". In Java, it will be very long and
> error prone!

Error prone? All the above answers look correct. Can you tell us how it
is error prone?

It looks like you have come from C and are expecting non-object-oriented
code. Simple, get over it.

If it is so inconvenient then why don't you write a wrapper around the
Math class to make things a little easier. For example:

public class MathFunctions {

public static double exp(double someVal) {
return Math.pow(Math.E, someVal);
}
}

Now all you have to do is call MathFunctions.exp(1);

You can shorten the class name if you want.

If that is still too difficult I suggestion you learn about the
advantages of an Object-Oriented programming language.

Lionel.

Posted: 2006-10-31 5:50:00

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone?

I appreciate Mark Thornton's reply:

import static java.lang.Math.*;

Then pow(2,3) or exp(1) is ready for service. Obviously, I didn't know
this trick.

In comparison, a wrapper class is a waste at all.

Posted: 2006-10-31 5:53:00

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? Shawn wrote:
>
>
> I appreciate Mark Thornton's reply:
>
> import static java.lang.Math.*;
>
> Then pow(2,3) or exp(1) is ready for service. Obviously, I didn't know
> this trick.
>
> In comparison, a wrapper class is a waste at all.

So if there is an exp method then why were you using pow in the first
place. Please read the documentation in future.

Posted: 2006-10-31 9:47:00

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? Lionel wrote:
>> My program need a lot of calculation of power. In many programming
>> languages,
>>
>> 2**3 = 8;
>>
>> The syntax is clean and easy. But in Java,
>>
>> Math.pow(2, 3) = 8; //It is so long, and complicated and error prone
>>
>> Again, in many languages,
>>
>> EXP(1) = 2.7 //e value
>>
>> But in Java,
>>
>> Math.pow(Math.E, 1) = 2.7 //You see, so complicated

> Error prone? All the above answers look correct. Can you tell us how it
> is error prone?

I agree with that.

> It looks like you have come from C and are expecting non-object-oriented
> code. Simple, get over it.

Actually C is very similar to Java. C does not have an
exponentation operator like Fortran and VB.

> If that is still too difficult I suggestion you learn about the
> advantages of an Object-Oriented programming language.

Hm.

I would not consider the Math static methods so fantastic
object oriented ...

Arne

Posted: 2006-10-31 19:45:00

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? Shawn, you have no idea how right you are ... Unfortunately, there are
many domains where Java is very unsuitable, just think of how silly it
is that you need to do s1.equals(s2) instead of s1 = s2. Any idea how
much you need to compare strings in a business app? Or the fact that
you can not switch on a String or other object type for some mysterious
rationale?

Lets face it, Java is not a very elegant language. They had objects, so
everything had to become a class, well almost. For some weird
optimization reason we have /primitive types/ and they shout you right
in the face at the most inconventient times. Operator overloading was
killed (which would have allowed you to do 2^3) because it was abused
heavily in C++.

I think that part of the problem is that languages are designed by
language experts. Notice how their first goal usually is to become
self-hosting. Obviously constructions that are needed to write parsers
tend to overwhelm the minds of the language designers. SQL, XML,
business logic, engineering problems, mathematics, are not really in
the forefront of their minds I think.

Interestingly, a key figure in the Java Language Specification is
creating a new language (while working for Sun!) for exactly your
mentioned reason: the unreadability of Java for domain specific
languages, where math is their focus, they want to replace Fortran. Guy
Steele gave a very interesting talk about fortress on the OOPSLA 2006
last week in Portland (domain specific languages seem to becoming big
anyway).

http://research.sun.com/projects/plrg/

Interestingly, they have operator overloading. They argue (justly imho)
that operator overloading was a problem in C++ because there were so
few operators to choose from in ASCII. However, today we have Unicode
allowing us to use symbols with well defined meanings: 鈭? 鈭? 鈭?
鈯?鈮? 鈭? etc. These symbols are a lot easier to read for domain
experts than "all we have is method calls". And if people want to abuse
it ... hey it is their life and job. Any decent programmer will use
overloading operators to stay within the intended meaning.

Though a language is syntactic sugar, it is imho important. The closer
the language is to the domain, the easier it is to understand what it
does in your domain. An extreme form of non-domain specific languages
is XML when used for humans. Reading an ant script or XSLT program is
horrendously hard because the expressions are so far removed from what
you are doing. Not only is this error prone, it is also harder to write
and read.

For example, just think of the sillyness that we have thousands if not
millions of programmers writing business applications that involve
transactions, data sources, databases, and many small data entities.
Java is very unsuitable for those applications because it does not
natively support any of those things, they must all be implemented as
classes. They all have to be encoded as method calls. This wastes many
man years everyday and uncounted cost due to increased errors and hard
to understand code. Did you ever try to discuss a domain problem with
your customer together with the Java code?

Also on the OOPSLA 2006 was a presentation of Intentions. They had as
example system that had 400 pages of requirements and domain knowledge
for a 20.000 page system. Why do we need to expand this 50x? Their
solution was to create a domain specific language that could reduce the
expansion to around 2000 pages.

Java missed a surprising number of important concepts, and the lanugage
designers have no excuse because most of the near fatal misses were
available in Smalltalk (functions and blocks as objects [closures],
operator overloading, abstracted primitive integers, well designed
collections, etc. It is interesting though to see how many Smalltalkers
nowaday are working in Java and JCP moving the language forward!).

However, the Java language was close to C++ and corrected some of the
glaring mistakes of C++, add a couple of hundred million advertising
campaign and you have an explanation why Java became popular.

Don't get me wrong, I make a living in Java code and it is definitely
less error prone than C++. It clearly was an improvement. I do not want
to leave Java because the amount of libraries is awesome, and some are
actually decent! However, I hope that the industry will support more
languages that are more domain oriented. It would be nice if these
languages could be build on the Java library and VM so we can use the
languages without a great cost during runtime. I definetely see a trend
here. My only fear is that computer science students have lost the
ability to write parsers because XML is so convenient for the
programmer and who cares about the customer ... :-)

Kind regards,

Peter Kriens

Shawn wrote:
> Hi,
>
> My program need a lot of calculation of power. In many programming
> languages,
>
> 2**3 = 8; //or
> 2^3 = 8;
>
> The syntax is clean and easy. But in Java,
>
> Math.pow(2, 3) = 8; //It is so long, and complicated and error prone
>
> Again, in many languages,
>
> EXP(1) = 2.7 //e value
>
> But in Java,
>
> Math.pow(Math.E, 1) = 2.7 //You see, so complicated
>
> Normally, in one calculation, 2**3 or EXP(3.5) is only part of
> expression, like "a + b**3 + EXP(-a)". In Java, it will be very long and
> error prone!

Posted: 2006-10-31 20:19:00

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone?
Lionel wrote:

> If that is still too difficult I suggestion you learn about the
> advantages of an Object-Oriented programming language.

One of them is to have no operator overloading? Come on. This has
nothing to do with OO or not OO.
BTW, do you write
new StringBuffer().append("foo").append(i).toString()
instead of
"foo" + i
?

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? pkriens wrote:
> Shawn, you have no idea how right you are ... Unfortunately, there are
> many domains where Java is very unsuitable, just think of how silly it
> is that you need to do s1.equals(s2) instead of s1 = s2. Any idea how
> much you need to compare strings in a business app?

This might be a reasonable argument if only there weren't so many ways
to compare strings. The usual default comparison (selected by computer
scientists) is also frequently the wrong choice in business applications.

>
> Lets face it, Java is not a very elegant language. They had objects, so
> everything had to become a class, well almost. For some weird
> optimization reason we have /primitive types/ and they shout you right
> in the face at the most inconventient times. Operator overloading was
> killed (which would have allowed you to do 2^3) because it was abused
> heavily in C++.
Except that the C inheritance meant that the ^ operator was already in
use for numeric types and thus not available for exponentiation.

> Interestingly, a key figure in the Java Language Specification is
> creating a new language (while working for Sun!) for exactly your
> mentioned reason: the unreadability of Java for domain specific
> languages, where math is their focus, they want to replace Fortran.
I don't consider Fortran to be all that readable either; we are just
used to it.

> Interestingly, they have operator overloading. They argue (justly imho)
> that operator overloading was a problem in C++ because there were so
> few operators to choose from in ASCII. However, today we have Unicode
> allowing us to use symbols with well defined meanings: 鈭? 鈭? 鈭?
> 鈯?鈮? 鈭? etc. These symbols are a lot easier to read for domain
> experts than "all we have is method calls".
Those operators only have well defined meanings in mathematics. One of
the problems with overloading in C++ was its use for all sorts of non
mathematical purposes. This problem started right at the beginning with
the example set by overloading << for output. Unicode would have allowed
a more appropriate symbol, but it would still be a new coinage for that
symbol, not an existing well defined meaning.

> it ... hey it is their life and job. Any decent programmer will use
> overloading operators to stay within the intended meaning.
Essentially mathematics is the only domain where operators have a well
defined meaning of long standing (centuries). However very few languages
are written just for mathematicians. So it is all but inevitable that
any language which permits significant operator overloading will find it
being extensively used for purposes where the relationship of the
operator to action is not immediately obvious or "within the intended
meaning".

>
> However, the Java language was close to C++ and corrected some of the
> glaring mistakes of C++, add a couple of hundred million advertising
> campaign and you have an explanation why Java became popular.
And that massive set of standard libraries.

Mark Thornton

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? pkriens wrote:
> However, today we have
> Unicode allowing us to use symbols with well defined meanings: 鈭? 鈭?
> 鈭? 鈯?鈮? 鈭? etc. These symbols are a lot easier to read for domain
> experts than "all we have is method calls".

You're not reinventing this are you?
http://tinyurl.com/y59nkm
;-)

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? pkriens wrote:
> Shawn, you have no idea how right you are ... Unfortunately, there are
> many domains where Java is very unsuitable, just think of how silly it
> is that you need to do s1.equals(s2) instead of s1 = s2. Any idea how
> much you need to compare strings in a business app?

And ?

.equals and == has different semantics in Java.

It is not that difficult to learn.

And when you are beyond beginner level, then the typing process
is insignificant in the development so number of keystrokes does not
matter.

> Or the fact that
> you can not switch on a String or other object type for some mysterious
> rationale?

That is not something unique for Java. It is rather common in
languages.

> I think that part of the problem is that languages are designed by
> language experts. Notice how their first goal usually is to become
> self-hosting. Obviously constructions that are needed to write parsers
> tend to overwhelm the minds of the language designers. SQL, XML,
> business logic, engineering problems, mathematics, are not really in
> the forefront of their minds I think.

I think you are rigth on that one.

Languages are a backyard of computer science academia.

> Though a language is syntactic sugar, it is imho important. The closer
> the language is to the domain, the easier it is to understand what it
> does in your domain. An extreme form of non-domain specific languages
> is XML when used for humans. Reading an ant script or XSLT program is
> horrendously hard because the expressions are so far removed from what
> you are doing. Not only is this error prone, it is also harder to write
> and read.

The strictness and easy validation of XML makes it very non error prone.

But it can be hard to read. Especially with a lot of namespace stuff.

> For example, just think of the sillyness that we have thousands if not
> millions of programmers writing business applications that involve
> transactions, data sources, databases, and many small data entities.
> Java is very unsuitable for those applications because it does not
> natively support any of those things, they must all be implemented as
> classes. They all have to be encoded as method calls. This wastes many
> man years everyday and uncounted cost due to increased errors and hard
> to understand code. Did you ever try to discuss a domain problem with
> your customer together with the Java code?

I am not aware og any mainstream languages that has support for those.

> Java missed a surprising number of important concepts, and the lanugage
> designers have no excuse because most of the near fatal misses were
> available in Smalltalk (functions and blocks as objects [closures],
> operator overloading, abstracted primitive integers, well designed
> collections, etc. It is interesting though to see how many Smalltalkers
> nowaday are working in Java and JCP moving the language forward!).

Scary considering how well SmallTalk did commercially.

Arne

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? "Arne Vajh鴍" <email***@***.com> wrote in message
news:454802e3$0$49209$email***@***.com...
>> For example, just think of the sillyness that we have thousands if not
>> millions of programmers writing business applications that involve
>> transactions, data sources, databases, and many small data entities.
>> Java is very unsuitable for those applications because it does not
>> natively support any of those things, they must all be implemented as
>> classes. They all have to be encoded as method calls. This wastes many
>> man years everyday and uncounted cost due to increased errors and hard
>> to understand code. Did you ever try to discuss a domain problem with
>> your customer together with the Java code?
>
> I am not aware og any mainstream languages that has support for those.

Didn't Cobol?

:)

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? It is easy to get lost in details with these discussions and start
comparing language features. I am not promoting to go to Smalltalk. I
only want to make clear that Java is just not very expressive because
it has only a few crufty constructs making programs overly verbose (or
crufty as I call it). XML is the extreme form of this where you have to
wrestle through the cruft to see the relevant content, but Java is
often not much better.

Cruft makes programs hard to read and understand and that is bad imho.

It is easy to stab at the lack of adoption for Smalltalk. Theirs is a
sad story of too early, lack of focus, and too much out of mainstream.
However, I do not think anybody that has looked at the language can
look at Java with dry eyes. :-)

> .equals and == has different semantics in Java.
I therefore used '=' in the post because in the mathematical sense it
is equality and not assignment. (Smalltalk used the arrow for
assignment).

> And when you are beyond beginner level, then the typing process
> is insignificant in the development so number of keystrokes does not
> matter.
No the typing is not that much of an issue, it is the READING that is
important! Having to hold 5 pages into mind or 1 makes a difference.

> [Switching on strings ] That is not something unique for Java. It is rather common in
> languages.
Yes, stupidity is widespread. But what is the rationale? The result is
that people start using if () then else if() then else ... ad nausuem
which is easy to get wrong and hard to read and probably less eficient
than the compiler could have done it. Or better with the right language
that has blocks/closures, a method could be made that performs the
switch.

Kind regards,

Peter Kriens

Arne Vajh鴍 wrote:
> pkriens wrote:
> > Shawn, you have no idea how right you are ... Unfortunately, there are
> > many domains where Java is very unsuitable, just think of how silly it
> > is that you need to do s1.equals(s2) instead of s1 = s2. Any idea how
> > much you need to compare strings in a business app?
>
> And ?
>
> .equals and == has different semantics in Java.
>
> It is not that difficult to learn.
>
> And when you are beyond beginner level, then the typing process
> is insignificant in the development so number of keystrokes does not
> matter.
>
> > Or the fact that
> > you can not switch on a String or other object type for some mysterious
> > rationale?
>
> That is not something unique for Java. It is rather common in
> languages.
>
> > I think that part of the problem is that languages are designed by
> > language experts. Notice how their first goal usually is to become
> > self-hosting. Obviously constructions that are needed to write parsers
> > tend to overwhelm the minds of the language designers. SQL, XML,
> > business logic, engineering problems, mathematics, are not really in
> > the forefront of their minds I think.
>
> I think you are rigth on that one.
>
> Languages are a backyard of computer science academia.
>
> > Though a language is syntactic sugar, it is imho important. The closer
> > the language is to the domain, the easier it is to understand what it
> > does in your domain. An extreme form of non-domain specific languages
> > is XML when used for humans. Reading an ant script or XSLT program is
> > horrendously hard because the expressions are so far removed from what
> > you are doing. Not only is this error prone, it is also harder to write
> > and read.
>
> The strictness and easy validation of XML makes it very non error prone.
>
> But it can be hard to read. Especially with a lot of namespace stuff.
>
>
> > For example, just think of the sillyness that we have thousands if not
> > millions of programmers writing business applications that involve
> > transactions, data sources, databases, and many small data entities.
> > Java is very unsuitable for those applications because it does not
> > natively support any of those things, they must all be implemented as
> > classes. They all have to be encoded as method calls. This wastes many
> > man years everyday and uncounted cost due to increased errors and hard
> > to understand code. Did you ever try to discuss a domain problem with
> > your customer together with the Java code?
>
> I am not aware og any mainstream languages that has support for those.
>
> > Java missed a surprising number of important concepts, and the lanugage
> > designers have no excuse because most of the near fatal misses were
> > available in Smalltalk (functions and blocks as objects [closures],
> > operator overloading, abstracted primitive integers, well designed
> > collections, etc. It is interesting though to see how many Smalltalkers
> > nowaday are working in Java and JCP moving the language forward!).
>
> Scary considering how well SmallTalk did commercially.
>
> Arne

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? Luc The Perverse wrote:
> "Arne Vajh鴍" <email***@***.com> wrote in message
> news:454802e3$0$49209$email***@***.com...
>>> For example, just think of the sillyness that we have thousands if not
>>> millions of programmers writing business applications that involve
>>> transactions, data sources, databases, and many small data entities.
>>> Java is very unsuitable for those applications because it does not
>>> natively support any of those things, they must all be implemented as
>>> classes. They all have to be encoded as method calls. This wastes many
>>> man years everyday and uncounted cost due to increased errors and hard
>>> to understand code. Did you ever try to discuss a domain problem with
>>> your customer together with the Java code?
>> I am not aware og any mainstream languages that has support for those.
>
> Didn't Cobol?
>
Only for CODASYL databases (i.e. IDMS) and via a preprocessor which made
these statements look like standard COBOL.

COBOL 85 didn't have native support for any of these things or a
preprocessor. The nearest it came was the COPY statement, which is just
"include" with some limited name substitution.

The current language specification doesn't extend the language beyond
COBOL 85 in any of these areas.

--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

java-programmer >> Why Java's math expression (power) is so inconvenient and error prone? I must admit that I prefer exponentiation as an operator rather than a
function call. It suits the mathematicians better, of whom I was one,
and it also guarantees the correct right-associativity of the operator,
which is otherwise up to the programmer in function-call land.