Java Generic programming using subclassing

[Paul O'Grady]

I have two classes which are wrappers for a (1D or 2D) array of
primitives (one type only). I want to unify these classes (because they
only differ in the data type stored), by the provision of an abstract
base class (Parent).

class A extends Parent{
float [] data ;
...
}

class B extends Parent {
int [] data ;
...
}


abstract class Parent {
private int numRows = 0 ;
private int numCols = 0 ;

/* Methods */
public abstract void getItem(int Row) throws InvalidRowException,
InvalidColException ;
public abstract void getItem(int Row, int Col) throws
InvalidRowException, InvalidColException ;
public abstract void setItem(int Row) throws InvalidRowException,
InvalidColException, InvalidValueException ;
public abstract void setItem(int Row, int Col) throws
InvalidRowException, InvalidColException, InvalidValueException ;
public abstract void copy() ;

public abstract void reSize(int addNumRows) ; //increase 1D or 2D array
size by adding addNumRows new rows
public abstract boolean isEmpty() ;
public abstract boolean contains() ;
public abstract int findItemPos() ;

public abstract void sort(int sortType) ; //For now, only sort for 1D arays

public int getNumRows()
{
return numRows ;
}

public int getNumCols()
{
return numCols ;
}
}



The problem is that the getItem() functions will return different types,
and the setItem() function will accept different types. I thought I
could get around this by overloading and overiding the methods
respectively. Howewer, when I attempt to compile this code, I get an
error saying the return types are incompatable. Ditto with the Copy
method. What am I doing wrong?



Tks

 

[Marcin Grunwald]

The problem is that the getItem() functions will return different types,
and the setItem() function will accept different types. I thought I
could get around this by overloading and overiding the methods
respectively. Howewer, when I attempt to compile this code, I get an
error saying the return types are incompatable. Ditto with the Copy
method. What am I doing wrong?

You cann't overload methods based on their return value.
Overloading works only with method arguments.

You are tring to do something like: java.util.ArrayList, java.util.Vector,
maybe check theese classes first.

 

[Paul O'Grady]

You cann't overload methods based on their return value.
Overloading works only with method arguments.

You are tring to do something like: java.util.ArrayList, java.util.Vector,
maybe check theese classes first.

Hi Marcin,

Thks for the feedback. I was trying to avid using ArrayList - because
the collection framework ADT hold objects rather than native types. I
think this is likely to have a performance hit. However, even if I use
an ArrayList, I am still stuck (true asumption?) with having to cast
objects back to different types. The real problem however, with using
ArrayList is that (AFAIK), I will not be able to edit items in the array
if I add them as Inrteger (or Float) objects. I really don't see why
something as simple as this is such a big deal (or at least, it appears
so to me as a newbie). In C++, I could just use class templates. I know
this is now supported in Java 5, but I am using java 1.4

Help !!!!

 

[John McGrath]

The real problem however, with using ArrayList is that (AFAIK), I will
not be able to edit items in the array if I add them as Inrteger (or
Float) objects.

That is really not an issue. If you store a primitive type, you "edit" it
by replacing the value of the primitive type. If you store references to
immutable objects, you edit them by replacing the value of the reference
to the immutable object. So anything you can do with a primitive type,
you can do with an object.

I really don't see why something as simple as this is such a big deal
(or at least, it appears so to me as a newbie). In C++, I could just
use class templates. I know this is now supported in Java 5, but I am
using java 1.4

Java 5's generic types are not really the same thing as C++'s templates.

The C++ templates are more flexible, and a *lot* more complicated. When
you use a template with a given type parameter, the compiler automatically
generates a new class using that type.

On the other hand, Java generics are used by the compiler to perform type
checking, and the compiler automatically supplies the down-casting. There
is no need to automatically generate new classes when a generic type is
used. The runtime classes know nothing about the generic type parameters.

 

[John C. Bollinger]

Thks for the feedback. I was trying to avid using ArrayList - because
the collection framework ADT hold objects rather than native types. I
think this is likely to have a performance hit.

You're right, but you don't know the size of the performance hit without
testing, and therefore you have no clue as to whether it's anything you
need to worry about.

However, even if I use
an ArrayList, I am still stuck (true asumption?) with having to cast
objects back to different types.

Not necessarily. You do have to cast (or use Java 1.5 generics) to get
anything more specific than Object, but if every object is sure to be
either a Float or an Integer then you can cast all of them to Number and
use its floatValue() and intValue() methods as appropriate.

The real problem however, with using
ArrayList is that (AFAIK), I will not be able to edit items in the array
if I add them as Inrteger (or Float) objects.

That's not a problem with ArrayList, it's the nature of Integer and
Float objects. You can replace such list elements with different ones,
but you cannot change the values that the existing objects represent.
If you think about it, this is *no* different from using primitives --
you can never *change* a primitive value itself, you can only replace it
with a different one. The only hangup, then, is the potential expense
of creating Integers and Floats to wrap your values. If you're going to
need to do this a lot then worry about it; otherwise don't.

I really don't see why
something as simple as this is such a big deal (or at least, it appears
so to me as a newbie).

The Jakarta Commons library contains collection classes for primitive
types, which might help you along your way. I think you are
underestimating the simplicity of what you want to do, however.
Metaprogramming can be tricky to do well, and is certainly tricky for a
language to support. A language that makes it _appear_ simple
implements its support well.

In C++, I could just use class templates. I know
this is now supported in Java 5, but I am using java 1.4

Java generics have some significant differences from C++ templates. Two
significant ones are that whereas C++ templates define families of
potentially many classes, Java generic classes are individual classes
(advantage Java); and that Java generics work only with reference-type
type parameters, not primitive type parameters (advantage C++).

 

[Paul O'Grady]

John C. Bollinger wrote:

Not necessarily. You do have to cast (or use Java 1.5 generics) to get
anything more specific than Object, but if every object is sure to be
either a Float or an Integer then you can cast all of them to Number and
use its floatValue() and intValue() methods as appropriate.

</snip>

Thanks for that John. This is the way I'm goiug to go. I will use a
vector of numbers, so I can use one class to use both floats and ints.
One last question however, before I implement this is:

(This stems from my C/C++ background - excuse me if I'm being too
*anal*ytic). I want to represent the 2D array as a memory slice (i.e. a
"stretched out" iD array. I want to alloc memory (well not directly) to
a contiguos block, and then use array indexing to partition the slice
into seperate colums. I'll have a class like this:

class MemBlock {
Number[] data ; //Contiguous block
int numCols ;
int numRows ;
int currCol ; //This will be the variable that indicates which
"column" is being referred to
}

so I can write some thing like this:

a = new MemBlock(1000,10) ; // numrows, numcols respectively
b = a ; // (Thinking in C, if these were pointers, then I have just
assigned the base address of the array a to b )

b.currCol = 5 ; //This asigns b to the 5th "column" in the "memory block"

The theory is I can then use variable b as a reference to the 5th colum
in MemBlock a.

Is this vaild in Java, and will any other references to the MemBlock
variable be released (or garbage collected) when the variable goes out o
f scope. ?

Thanks in advance for your comments.

 

[John C. Bollinger]

One last question however, before I implement this is:

(This stems from my C/C++ background - excuse me if I'm being too
*anal*ytic). I want to represent the 2D array as a memory slice (i.e. a
"stretched out" iD array. I want to alloc memory (well not directly) to
a contiguos block, and then use array indexing to partition the slice
into seperate colums.

Sorry, you can't do that.

That is to say, Java nowhere guarantees that the elements of an array
are stored contiguously in memory. Now chances are that any Java
implementation you ever use _will_ store the elements of a 1D array
contiguously in memory, but you can't assume it. It doesn't matter,
though, because you can't test it either. Please recognize also that
Java arrays are full-fledged objects in their own right, with their own
classes distinct from their component type. This is unlike in C and
C++, where arrays are just a convenient alternative syntax for pointers.

You certainly can use a 1D sequential data structure (e.g. an array or a
List) as a backing store for data access via two or more indices, but
you should consider what you expect to gain by doing so. Before the
word "performance" escapes your fingers, let me warn you that the
strongly prevailing opinion in this forum is in agreement with the maxim
that "premature optimization is the root of all evil". In point of
fact, all modern Java VMs implement some form of just-in-time
compilation to native code, and these compilers are quite good at
optimization, especially when they see patterns they recognize. People
are notoriously bad at predicting where performance bottlenecks will
occur, so unless you have a known performance problem and a profile to
show what's causing it, you should avoid writing contorted code intended
to sidestep performance problems.

I'll have a class like this:

class MemBlock {
Number[] data ; //Contiguous block
int numCols ;
int numRows ;
int currCol ; //This will be the variable that indicates which
"column" is being referred to
}

so I can write some thing like this:

a = new MemBlock(1000,10) ; // numrows, numcols respectively
b = a ; // (Thinking in C, if these were pointers, then I have just
assigned the base address of the array a to b )

Try not to think in C (or C++); it will get you into trouble when you
are trying to write Java. You may be using a valid model, but I'm not
sure. Let's look in a bit more detail:

MemBlock a = new MemBlock(1000, 10);

Presuming that you give the MemBlock class a suitable constructor, this
statement will instantiate a new MemBlock object and assign a reference
to it to variable "a".

MemBlock b = a;

This copies the reference stored in variable "a" to variable "b". The
two variables now both refer to the same object, and can be used
interchangeably to examine or mutate that object.

b.currCol = 5 ; //This asigns b to the 5th "column" in the "memory block"

I'm not sure I follow you there, but do note that in the context of the
previous statements, that one is equivalent to

a.currCol = 5;

I.e. you have only created one MemBlock object, to which variables "a"
and "b" both refer, and changes you make to it through one copy of the
reference will be visible through the other.

The theory is I can then use variable b as a reference to the 5th colum
in MemBlock a.

This sounds pretty unlikely. There is no distinction at this point
between the object "b" refers to and the one that "a" refers to. It is
probably more useful, in fact, to call it "the MemBlock to which a
refers" than to call it "MemBlock a", because there is no special
association between an object and any particular copy of its reference.

If you're going to care about distinct "banks" within your memory block
then why not use a standard Java 2D array in the first place? Each
major index of the 2D array then will refer to a distinct 1D array, with
its own reference that you can use to construct a view of just that part
of the array. The 1D subarrays can even be of different lengths if that
happens to be useful.

You may also want to look into List.subList(), which can provide a
(mutable!) view of a portion of a List.

All in all I get the feeling that you're trying to write C in Java,
which can be done but is rarely advantageous. I'd advise you to spend
some time learning the typical Java idioms for the kind of tasks you're
trying to code -- where they differ from C idioms it's generally because
they work better in Java, one way or another, than the C-like
alternatives (not because Java programmers are weak-minded or lazy).

Is this vaild in Java, and will any other references to the MemBlock
variable be released (or garbage collected) when the variable goes out o
f scope. ?

I don't see anything that looks illegal, but I don't think the code you
describe will have the effects you describe. As for garbage collection,
you rarely, if ever, have to worry about it: no object will ever be
collected while there is still a hard reference (the only kind we've
discussed so far) to it reachable from any live thread via a chain of
hard references. Once it ceases to be so reachable an object becomes
eligible for garbage collection, and will in fact be collected before
the VM throws any OutOfMemoryError (but otherwise is not guaranteed ever
to be collected).

 

[Paul O'Grady]

One last question however, before I implement this is:

(This stems from my C/C++ background - excuse me if I'm being too
*anal*ytic). I want to represent the 2D array as a memory slice (i.e.
a "stretched out" iD array. I want to alloc memory (well not directly)
to a contiguos block, and then use array indexing to partition the
slice into seperate colums.

Sorry, you can't do that.

That is to say, Java nowhere guarantees that the elements of an array
are stored contiguously in memory. Now chances are that any Java
implementation you ever use _will_ store the elements of a 1D array
contiguously in memory, but you can't assume it. It doesn't matter,
though, because you can't test it either. Please recognize also that
Java arrays are full-fledged objects in their own right, with their own
classes distinct from their component type. This is unlike in C and
C++, where arrays are just a convenient alternative syntax for pointers.

You certainly can use a 1D sequential data structure (e.g. an array or a
List) as a backing store for data access via two or more indices, but
you should consider what you expect to gain by doing so. Before the
word "performance" escapes your fingers, let me warn you that the
strongly prevailing opinion in this forum is in agreement with the maxim
that "premature optimization is the root of all evil". In point of
fact, all modern Java VMs implement some form of just-in-time
compilation to native code, and these compilers are quite good at
optimization, especially when they see patterns they recognize. People
are notoriously bad at predicting where performance bottlenecks will
occur, so unless you have a known performance problem and a profile to
show what's causing it, you should avoid writing contorted code intended
to sidestep performance problems.

I'll have a class like this:

class MemBlock {
Number[] data ; //Contiguous block
int numCols ;
int numRows ;
int currCol ; //This will be the variable that indicates which
"column" is being referred to
}

so I can write some thing like this:

a = new MemBlock(1000,10) ; // numrows, numcols respectively
b = a ; // (Thinking in C, if these were pointers, then I have just
assigned the base address of the array a to b )

Try not to think in C (or C++); it will get you into trouble when you
are trying to write Java. You may be using a valid model, but I'm not
sure. Let's look in a bit more detail:

MemBlock a = new MemBlock(1000, 10);

Presuming that you give the MemBlock class a suitable constructor, this
statement will instantiate a new MemBlock object and assign a reference
to it to variable "a".

MemBlock b = a;

This copies the reference stored in variable "a" to variable "b". The
two variables now both refer to the same object, and can be used
interchangeably to examine or mutate that object.

b.currCol = 5 ; //This asigns b to the 5th "column" in the "memory
block"

I'm not sure I follow you there, but do note that in the context of the
previous statements, that one is equivalent to

a.currCol = 5;

I.e. you have only created one MemBlock object, to which variables "a"
and "b" both refer, and changes you make to it through one copy of the
reference will be visible through the other.

The theory is I can then use variable b as a reference to the 5th
colum in MemBlock a.

This sounds pretty unlikely. There is no distinction at this point
between the object "b" refers to and the one that "a" refers to. It is
probably more useful, in fact, to call it "the MemBlock to which a
refers" than to call it "MemBlock a", because there is no special
association between an object and any particular copy of its reference.

If you're going to care about distinct "banks" within your memory block
then why not use a standard Java 2D array in the first place? Each
major index of the 2D array then will refer to a distinct 1D array, with
its own reference that you can use to construct a view of just that part
of the array. The 1D subarrays can even be of different lengths if that
happens to be useful.

You may also want to look into List.subList(), which can provide a
(mutable!) view of a portion of a List.

All in all I get the feeling that you're trying to write C in Java,
which can be done but is rarely advantageous. I'd advise you to spend
some time learning the typical Java idioms for the kind of tasks you're
trying to code -- where they differ from C idioms it's generally because
they work better in Java, one way or another, than the C-like
alternatives (not because Java programmers are weak-minded or lazy).

Is this vaild in Java, and will any other references to the MemBlock
variable be released (or garbage collected) when the variable goes out
o f scope. ?

I don't see anything that looks illegal, but I don't think the code you
describe will have the effects you describe. As for garbage collection,
you rarely, if ever, have to worry about it: no object will ever be
collected while there is still a hard reference (the only kind we've
discussed so far) to it reachable from any live thread via a chain of
hard references. Once it ceases to be so reachable an object becomes
eligible for garbage collection, and will in fact be collected before
the VM throws any OutOfMemoryError (but otherwise is not guaranteed ever
to be collected).

Many thanks for all that John. I am beginning to see the way forward. I
may come back with some more questions if I get stuck. Many thanks once
again.

 

[Tony Morris]

Sorry, you can't do that.

That is to say, Java nowhere guarantees that the elements of an array
are stored contiguously in memory.

Perhaps you overlooked?
http://java.sun.com/j2se/1.5.0/docs/api/java/nio/ByteBuffer.html#allocateDirect(int)
Granted, no guarantee is made.

If you're going to care about distinct "banks" within your memory block
then why not use a standard Java 2D array in the first place?

Java does not have multi-dimensional arrays.

 

[John C. Bollinger]

Perhaps you overlooked?
http://java.sun.com/j2se/1.5.0/docs/api/java/nio/ByteBuffer.html#allocateDirect(int)
Granted, no guarantee is made.

I wasn't thinking about that at all. But that's probably because even
after looking at it I have no idea what it is about it that you think is
relevant to the question.

Java does not have multi-dimensional arrays.

Can you describe a data object that you would consider to be a
multi-dimensional array? Java has multi-dimensional array syntax, which
is used to create and manipulate objects that are 1D arrays of 1D arrays
nested to depth n. This particular model is exactly what I was thinking
of when I made the above recommendation to the OP. Do you have
preferred terminology for discussing it?

 

[Patricia Shanahan]

I wasn't thinking about that at all. But that's probably
because even after looking at it I have no idea what it
is about it that you think is relevant to the question.



Can you describe a data object that you would consider to
be a multi-dimensional array? Java has multi-dimensional
array syntax, which is used to create and manipulate
objects that are 1D arrays of 1D arrays nested to depth
n. This particular model is exactly what I was thinking
of when I made the above recommendation to the OP. Do
you have preferred terminology for discussing it?

I would call it "an array of arrays", just as I would call
an array whose elements are String references "an array of
String references".

I prefer to keep the term "multi-dimensional array" for
structures such as a Fortran array with more than one dimension:

integer myarray(10,20)

declares one array with two dimensions. Elements are
referenced as myarray(i,j), with two indices in a single
array reference. Although the memory layout is specified, at
the source language level the rows and columns have equal
status. The array is inherently rectangular.

Patricia

 

[John C. Bollinger]

I prefer to keep the term "multi-dimensional array" for
structures such as a Fortran array with more than one dimension:

integer myarray(10,20)

declares one array with two dimensions. Elements are
referenced as myarray(i,j), with two indices in a single
array reference. Although the memory layout is specified, at
the source language level the rows and columns have equal
status. The array is inherently rectangular.

Fair enough. I was discounting the Fortran model in this regard because
it doesn't strongly enforce any difference between arrays of the same
type but different rank. Nevertheless, I certainly wouldn't try to
argue that Fortran doesn't have multi-dimensional arrays. On the other
hand, I'm not persuaded that it's useful to argue that Java doesn't have
them too. That the Java data structures in question can also be viewed
as a series of nested 1D arrays doesn't carry much weight with me, and
that the syntax for accessing their elements emphasizes the nested view
carries only a little more. It's the "two indices" part that I find
persuasive, and I see the question of "a single array reference" as a
matter of ambiguous semantics.

Shall I really describe a double[][][][] as an "array of arrays of
arrays of arrays of double"? It's accurate, to be sure, but I don't see
how calling the same thing a "4-D array of doubles" is any less so when
taken in context. Would it really make a difference if Java 1.6
provided an indexing syntax that allowed me to write "double d =
darray[1,2,3,4];"? Or suppose I use a preprocessor that converts that
form into the standard Java syntax. Have I then created my own
derivative language that has multidimensional arrays where Java does not?

I'm very much in favor of precise language for technical discourse, and
in that regard the "array of array of ..." terminology earns some
points, but I don't think that religiously avoiding calling the things
multidimensional arrays contributes anything to the discussion. In
context, the meaning is absolutely clear.

 

[Patricia Shanahan]

Shall I really describe a double[][][][] as an "array of arrays of
arrays of arrays of double"? It's accurate, to be sure, but I don't see
how calling the same thing a "4-D array of doubles" is any less so when
taken in context. Would it really make a difference if Java 1.6
provided an indexing syntax that allowed me to write "double d =
darray[1,2,3,4];"? Or suppose I use a preprocessor that converts that
form into the standard Java syntax. Have I then created my own
derivative language that has multidimensional arrays where Java does not?

The big difference, in my mind, is whether you have an
inherently rectangular structure, or a bunch of arrays of
independent length. The syntax for indexing does also
strongly suggest an array of arrays, not a multidimensional
array, but that is less important.

The two taken together make multidimensional arrays a
reality in Fortran, but something that can be emulated, by
arrays of arrays with equal subarray lengths, in C and Java.

My reason for pushing on this is that I think having
multidimensional arrays adds to the expressiveness of a
language. There is something to be said for telling the
compiler, as well as subsequent programmers, "This is a
rectangular structure with these dimensions". I'm afraid
that too many programmers who have only seen
arrays-of-arrays will think that is all there is to
multidimensional arrays, making it harder to get the real
thing into languages.

Patricia

 

[John C. Bollinger]

My reason for pushing on this is that I think having multidimensional
arrays adds to the expressiveness of a language. There is something to
be said for telling the compiler, as well as subsequent programmers,
"This is a rectangular structure with these dimensions". I'm afraid that
too many programmers who have only seen arrays-of-arrays will think that
is all there is to multidimensional arrays, making it harder to get the
real thing into languages.

I'm not holding out any hope of ever seeing multi-dimensional arrays of
the kind you describe in Java, but I will attempt to monitor my language
in referring to the data types that Java offers as a rough analog. Feel
free to give me a virtual poke if I slip up .

 

[Lee Fesperman]

Shall I really describe a double[][][][] as an "array of arrays of
arrays of arrays of double"? It's accurate, to be sure, but I don't see
how calling the same thing a "4-D array of doubles" is any less so when
taken in context. Would it really make a difference if Java 1.6
provided an indexing syntax that allowed me to write "double d =
darray[1,2,3,4];"? Or suppose I use a preprocessor that converts that
form into the standard Java syntax. Have I then created my own
derivative language that has multidimensional arrays where Java does not?

The big difference, in my mind, is whether you have an
inherently rectangular structure, or a bunch of arrays of
independent length. The syntax for indexing does also
strongly suggest an array of arrays, not a multidimensional
array, but that is less important.

The two taken together make multidimensional arrays a
reality in Fortran, but something that can be emulated, by
arrays of arrays with equal subarray lengths, in C and Java.

My reason for pushing on this is that I think having
multidimensional arrays adds to the expressiveness of a
language. There is something to be said for telling the
compiler, as well as subsequent programmers, "This is a
rectangular structure with these dimensions". I'm afraid
that too many programmers who have only seen
arrays-of-arrays will think that is all there is to
multidimensional arrays, making it harder to get the real
thing into languages.

No disrespect intended (I am really delighted that you have returned to the group!), but
I think you've gone overboard in calling rectangular structures the 'real thing'. It
quite reasonable for Java to use the term, multidimensional array, and it provides
perfectly good syntax to support it. Java has been accepted as an important member of
the major high-level languages and should be allowed to use this terminology without
having to cater to other languages.

I have written a great deal of Fortran in the past. Java's structures are quite clean as
opposed to the rather 'dirty' nature of Fortran's 'reality'. I have used the low level
nature (exposed implementation) of multidimensional arrays in Fortran to get around its
(earlier?) lack of dynamic allocation, as well as other kludges. I hardly see Fortran as
an example of how to do it right. I'm sure you know that Fortran's array subscripting
capability was built to accomodate the architecture of an ancient CPU.

It is quite trivial to create a Java class that provides this functionality (rectangular
array) with a Fortran-like syntax for accessing the array. With 1.5 generics, this could
be a powerful class. In those cases the normal solution is --- "roll your own." However,
it is not required since Java provides reasonable capabilities natively.

 

[beliavsky]

I have written a great deal of Fortran in the past. Java's structures are quite clean as
opposed to the rather 'dirty' nature of Fortran's 'reality'. I have used the low level
nature (exposed implementation) of multidimensional arrays in Fortran to get around its
(earlier?) lack of dynamic allocation, as well as other kludges. I hardly see Fortran as
an example of how to do it right. I'm sure you know that Fortran's array subscripting
capability was built to accomodate the architecture of an ancient

CPU.

Fortran has had dynamic memory allocation since the 1990 standard,
using ALLOCATABLE arrays, automatic arrays, and POINTERs. It also has
operations on arrays and array sections, as in Matlab.

 

[beliavsky]

Fair enough. I was discounting the Fortran model in this regard because
it doesn't strongly enforce any difference between arrays of the same

type but different rank.

In Fortran 90/95/2003 many consider it good style to pass assumed shape
arrays to functions and subroutines in modules, in which case
mismatched ranks are caught at compile time. The program below, for
example, will not compile:

module mat_mod
contains
function twice(x) result(x2)
real, intent(in) :: x,
end function twice
end module mat_mod

program xx
real :: x(10)
x = 1.0
call twice(x) ! illegal -- x must have rank 2
end program xx

 

[Lee Fesperman]

Fortran has had dynamic memory allocation since the 1990 standard,
using ALLOCATABLE arrays, automatic arrays, and POINTERs. It also has
operations on arrays and array sections, as in Matlab.

Thanks for the update. That's why I put the "(earlier?)" in there. I haven't used
Fortran since ... you don't want to know ;^)

 

[John C. Bollinger]

In Fortran 90/95/2003 many consider it good style to pass assumed shape
arrays to functions and subroutines in modules, in which case
mismatched ranks are caught at compile time. The program below, for
example, will not compile:

module mat_mod
contains
function twice(x) result(x2)
real, intent(in) :: x,
end function twice
end module mat_mod

program xx
real :: x(10)
x = 1.0
call twice(x) ! illegal -- x must have rank 2
end program xx

Yes, but my point is that in Fortran, one can just as easily write
twice() as

function twice(y)
real :: y(2, *)
! do something
end function twice

That _will_ compile, and in the context of twice() y is a 2-D array,
even though the actual argument with which it is associated is a 1-D
array. This is before even considering issues like use of EQUIVALENCE
to alias array variables of different rank. Hence my assertion
(rephrased) that Fortran multi-dimensional arrays don't offer everything
a Java programmer would expect.

 

[Patricia Shanahan]

Yes, but my point is that in Fortran, one can just as easily write
twice() as

function twice(y)
real :: y(2, *)
! do something
end function twice

That _will_ compile, and in the context of twice() y is a 2-D array,
even though the actual argument with which it is associated is a 1-D
array. This is before even considering issues like use of EQUIVALENCE
to alias array variables of different rank. Hence my assertion
(rephrased) that Fortran multi-dimensional arrays don't offer everything
a Java programmer would expect.

Java features also don't offer everything a Fortran
programmer would expect. (Multi-dimensional arrays,
operations on arrays and array slices, complex as a first
class arithmetic type). That is why we have more than one
programming language.

For most of the programming I do now, Java is clearly better
than Fortran. If I had to write a non-trivial linear algebra
program, I would seriously consider Fortran, especially
Fortran 90 and later.

Patricia