Oberon vs F-90 
Author Message
 Oberon vs F-90

: I guess Matt is claiming that, since column-major fortran was there
: first, all these row-major languages were delivering a deliberate slap
: in the face to Fortran.  It is an interesting thesis, but I doubt
: anyone could prove it.

I think that designing all those new language that was row-major by default
with out any easy way to change to the other way were certainly
extremely indifferent, almost negligent, to Fortran programmers.  

I don't know if was ever deliberate but I've heard (and seen on usenet) when
numerical programmers want some semi-fortran-oriented feature in a new
language they are dismissed with "Oh why do we even bother dealing with you
neanderthals."  And then they complain that scientists keep on using fortran
long past its time.

: I think it is more likely a philosophical difference.  Fortran has
: historically encouraged users to view memory storage as a column of
: numbers, so columns of 2-D arrays are contiguous.  Many other languages
: have encouraged users to view memory as a string of bytes (characters),
: so rows of 2-D arrays are contiguous ("reading" across, then down).

Why should this really matter?  Unless I as a human will be inspecting
bits in RAM chips through a charge sensitive tunneling electron microscope,
who cares?

: It
: is nothing personal on either side, but it is one subtlety that speaks
: volumes about which users are attracted to which language.

I don't understand.  I don't think one is hardly more "natural" than
another in any *significant* fashion, certainly not enough to warrant
30 years of needless neglect.

--

-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".



Sun, 01 Jun 1997 10:25:33 GMT  
 Oberon vs F-90

Quote:

>I think that designing all those new language that was row-major by default
>with out any easy way to change to the other way were certainly
>extremely indifferent, almost negligent, to Fortran programmers.  

....  (discussion of arbitrariness of matrix order deleted)

Quote:
>I don't understand.  I don't think one is hardly more "natural" than
>another in any *significant* fashion, certainly not enough to warrant
>30 years of needless neglect.

Although I can't speak for Pascal, Oberon, and others, the row-major
matrices in C and C++ are a natural extension of the way pointers and
arrays are related.  If a[i][j] are elements of an array, then a[i] are
pointers, and a is a pointer to a pointer.  The brackets are simply
operators that add the index (times the size of the thing pointed to) to
the pointer and dereference it.

This approach requires that arrays be row-major; the choice was not
arbitrary, nor meant as a slight to Fortran.

Quote:
>--

>-Institute for Nonlinear Science, University of California, San Diego
>-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
>-***     lyapunov.ucsd.edu, username "anonymous".

Jack Bennetto



Sun, 01 Jun 1997 23:20:42 GMT  
 Oberon vs F-90

Quote:

>: I guess Matt is claiming that, since column-major Fortran was there
>: first, all these row-major languages were delivering a deliberate slap
>: in the face to Fortran.  It is an interesting thesis, but I doubt
>: anyone could prove it.

>I think that designing all those new language that was row-major by default
>with out any easy way to change to the other way were certainly
>extremely indifferent, almost negligent, to Fortran programmers.  

Why should the Fortran programmers be relevant to the design of a new,
unrelated, programming language?  Fortran is only a programming language,
like all the others, it doesn't enjoy any special privileges WRT other
programming languages.

Quote:

>I don't know if was ever deliberate but I've heard (and seen on usenet) when
>numerical programmers want some semi-fortran-oriented feature in a new
>language they are dismissed with "Oh why do we even bother dealing with you
>neanderthals."  

I haven't met too many numerical programmers using a language which doesn't
contain the word "Fortran" in its name :-)

Quote:
>And then they complain that scientists keep on using fortran
>long past its time.

I wasn't aware that the Fortran time is over.  But I do agree that F77
looked awfully dusty and an updated version was badly needed.  Fortunately,
F90 compilers seem to be available for quite a large number of systems.

Dan
--
Dan Pop                       | The only reason God was able to make the
CERN, CN Division             | world in 7 days was he didn't have to remain

Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland



Tue, 03 Jun 1997 01:32:01 GMT  
 Oberon vs F-90

: >I think that designing all those new language that was row-major by default
: >with out any easy way to change to the other way were certainly
: >extremely indifferent, almost negligent, to Fortran programmers.  

: ....  (discussion of arbitrariness of matrix order deleted)

: >I don't understand.  I don't think one is hardly more "natural" than
: >another in any *significant* fashion, certainly not enough to warrant
: >30 years of needless neglect.

: Although I can't speak for Pascal, Oberon, and others, the row-major
: matrices in C and C++ are a natural extension of the way pointers and
: arrays are related.  If a[i][j] are elements of an array, then a[i] are
: pointers, and a is a pointer to a pointer.  The brackets are simply
: operators that add the index (times the size of the thing pointed to) to
: the pointer and dereference it.

That's because C confuses float **a (numerical recipes in C fake arrays)
and float a[N1][N2] (multi-dimensional arrays except they're annoyingly
fixed sized), whereby you use elements of both as ``a[i][j]''.

The second doesn't have any internal pointers.

: This approach requires that arrays be row-major; the choice was not
: arbitrary, nor meant as a slight to Fortran.

But if an ''a[i,j]'' had been defined as *(a + i*size1 + j),
which it wasn't, you could have had column major arrays.

: >--

: >-Institute for Nonlinear Science, University of California, San Diego
: >-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
: >-***     lyapunov.ucsd.edu, username "anonymous".

: Jack Bennetto

--

-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".



Tue, 03 Jun 1997 05:06:10 GMT  
 Oberon vs F-90
[...]

Quote:
>Fortran is only a programming language,
>like all the others, it doesn't enjoy any special privileges WRT other
>programming languages.[...]

Well, Fortran was the first language that had a standard definition,
wasn't it.  Doesn't that make it special?

Concerning storage of arrays in various languages, it should be clear to
anyone with half a brain (or with a linear algebra course 101 in their
transcript, whichever ;-) that Fortran did it the right way.  However, it
is not an insurmountable problem in other languages.  Even in a
cross-language environment, it isn't that bad...you just call a subroutine
that works with matrices stored in transposed form.  For example, if you
want to do some operation in C on array A, you call the fortran subroutine
that works with A-transpose rather than A.  Or if it is a BLAS routine,
you use 't' instead of 'n' as the storage-order argument.

At least Fortran-90 didn't start doing things backward too!  :-)

$.02 -Ron Shepard



Tue, 03 Jun 1997 05:19:08 GMT  
 Oberon vs F-90

|>
|> Concerning storage of arrays in various languages, it should be clear to
|> anyone with half a brain (or with a linear algebra course 101 in their
|> transcript, whichever ;-) that Fortran did it the right way.

I don't understand this comment. In my experience, when a
mathematician writes

                     A
                      ij

he means the element of A at row i, column j,
which seems quite a lot like row-major ordering
to me.

|> $.02 -Ron Shepard

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,          | A citizen of NewZealandCorp, a       |
Christchurch, New Zealand          | wholly-owned subsidiary of Japan Inc.|



Tue, 03 Jun 1997 08:00:36 GMT  
 Oberon vs F-90

Quote:
> 1. In my branch of science VAX is about the only platform used,
>    now slowly being replaced by Alpha. For the reason known only
>    to themselves the ETH folks chose to dislike VMS platforms.
>    Recently they released an Amiga Oberon System. For as much as
>    I value Amiga (which I never saw in my life) it strikes me
>    as an interesting choice do disregard Alpha and develop
>    for an Amiga platform. I myself cannot use something that
>    does not exist.

As an Amiga devotee I couldn't let this slip by.  There are over three
million Amigas being used world-wide by very satisfied users.  There is
also currently a bidding war in progress to purchase and continue Amiga
development by at least two other companies.  The Amiga also still
has the best OS even with all the recent Windows 95 e{*filter*}ment.

How many installed Alphas?

Cheers,

  Michael Griebling
  Computer Inspirations



Tue, 03 Jun 1997 20:47:53 GMT  
 Oberon vs F-90

Quote:



> |>
> |> Concerning storage of arrays in various languages, it should be clear to
> |> anyone with half a brain (or with a linear algebra course 101 in their
> |> transcript, whichever ;-) that Fortran did it the right way.

> I don't understand this comment. In my experience, when a
> mathematician writes

>                      A
>                       ij

> he means the element of A at row i, column j,
> which seems quite a lot like row-major ordering
> to me.

Even this is just a naming convention. You may say just as well
that "i" is a column and "j" is a row index. Or, in abstract
mathematical spirit you may define a "column" as something printed
horizontal and a "row" as something vertical. The only thing that
matters is that definitions are consistent in a given piece of work.

Actually, people quite often do not write their matrices in a tablet
format appropriate for algebra 101. In what is called an "index calculus"
they just manipulate indices according to certain rules (e.g., Einstein's
summing convention.) It does not actually matter what printed layout
a person might have had in mind. The result must not depend on this.
"Rows" and "columns" are just names, similar to "covariant" and
"contravariant" indices. One kind is written as subscripts, the other one
as superscripts -- but it does not matter, which one. In fact, there are
two opposite conventions in widespread use. Another example which comes
to mind is "active" and "passive" view of coordinate transformation
in linear algebra (base vector transformation). Once again, the final
result must not depend on a particular view adopted.

Perhaps the core of the discussion refers to the fact that there are many
Fortran programs which explicitly take advantage of one particular memory
layout. In Fortran it is legal to declare a multidimensional array like
      DIMENSION A (10,10)
and to use it later as A (100). What is an array element A (11), you might
ask ? Is it A(10,2) or A(2,10) ? The answer depends on particular memory
ordering. If the first index changes first when traversing memory, then
after elements A(1,1), A(2,1), A(3,1),...., the next element will be A(1,2)
aka A(11,1) aka A(11). If the second index changes first, then the opposite
holds: A(11) is same as A(2,1). Can one argue which answer is the "right"
one, i.e., the one being taught at algebra 101 ? My recollection of
mathematics tells me that it is the worst mathematical sin to mix objects
of different kind. For example, mathematically one cannot add a vector to
a matrix unless a proper mapping between different spaces is introduced.
In math there is nothing like "memory layout", which would automatically
provide for Aij being of the same kind as Vk (A being a matrix and V
a vector). Perhaps the poster should brush up his knowledge of what "matrices"
actually are. Perhaps the correspondence between matrices and linear
operators was not explained at algebra 101 ?

Stings aside, the Fortran equating of A(10,10) and A(100) is just a low-level
trick exploiting particular addressing scheme. Long ago it seemed like a good
idea to provide for such a mapping, and many Fortran utility routines
exploited that fact. But a low-level trick is just that: a low-level trick.
No more than that.

Wojtek



Wed, 04 Jun 1997 00:42:44 GMT  
 Oberon vs F-90

Quote:


>> 1. In my branch of science VAX is about the only platform used,
>>    now slowly being replaced by Alpha. For the reason known only
>>    to themselves the ETH folks chose to dislike VMS platforms.
>>    Recently they released an Amiga Oberon System. For as much as
>>    I value Amiga (which I never saw in my life) it strikes me
>>    as an interesting choice do disregard Alpha and develop
>>    for an Amiga platform. I myself cannot use something that
>>    does not exist.

> As an Amiga devotee I couldn't let this slip by.  There are over three
> million Amigas being used world-wide by very satisfied users.  There is
> also currently a bidding war in progress to purchase and continue Amiga
> development by at least two other companies.  The Amiga also still
> has the best OS even with all the recent Windows 95 e{*filter*}ment.

Glad to hear you like your Amiga. Even more glad to hear that there is hope
for continuation of the Amiga line.

Quote:
> How many installed Alphas?

No idea. Hard-core nuclear physicists run their Fortran programs on either
VAX or Alpha, this is all I can say. I have visited a dozen labs and never
saw a single Amiga, but many Alphas. I am typing this message on one of those
in a window open on a VAX. Note that I did not call ETH decision "wrong",
I called it "interesting".

I hope I will be running my Oberon System on an Alpha one day and you will be
running yours on your Amiga.

Quote:

> Cheers,

>   Michael Griebling
>   Computer Inspirations

Wojtek


Wed, 04 Jun 1997 04:46:26 GMT  
 Oberon vs F-90

Quote:





> > |>
> > |> Concerning storage of arrays in various languages, it should be clear to
> > |> anyone with half a brain (or with a linear algebra course 101 in their
> > |> transcript, whichever ;-) that Fortran did it the right way.

> > I don't understand this comment. In my experience, when a
> > mathematician writes

> >                      A
> >                       ij

> > he means the element of A at row i, column j,
> > which seems quite a lot like row-major ordering
> > to me.

> Even this is just a naming convention. You may say just as well
> that "i" is a column and "j" is a row index. Or, in abstract
> mathematical spirit you may define a "column" as something printed
> horizontal and a "row" as something vertical. The only thing that
> matters is that definitions are consistent in a given piece of work.

Yes, you can call objects by any name you want.  I would be very surprised
to see anybody (mathematician or otherwise) refer to a horizontal list
of numbers as a column, or a vertical one as a row.

By the same "abstract spirit", I am typing on my screen and viewing the results
on my keyboard :-)

Quote:
> Perhaps the core of the discussion refers to the fact that there are many
> Fortran programs which explicitly take advantage of one particular memory
> layout. In Fortran it is legal to declare a multidimensional array like
>       DIMENSION A (10,10)
> and to use it later as A (100).

[Stuff deleted]

Quote:
> In math there is nothing like "memory layout", which would automatically
> provide for Aij being of the same kind as Vk (A being a matrix and V
> a vector).

Mathematics also doesn't have to deal with manipulating large arrays of data
that don't fit in a computer's cache.  If you know nothing about memory layout,
you'll probably write a code that doesn't access memory sequentially, thereby
thrashing the cache, and incurring a huge performance hit.

It would be nice just to write code thinking of elegant mathematics, but the
computer introduces real-world constraints that impact how you design your
algorithms.

Quote:
> Stings aside, the Fortran equating of A(10,10) and A(100) is just a low-level
> trick exploiting particular addressing scheme. Long ago it seemed like a good
> idea to provide for such a mapping, and many Fortran utility routines
> exploited that fact. But a low-level trick is just that: a low-level trick.
> No more than that.

This "trick" was often part of sophisticated memory management schemes to
squeeze the most out of a prized resource--memory.  Computers haven't always
had such big core memory (if you'll excuse the dated term :-), and the
benefits of virtual memory.

Quote:
> Perhaps the poster should brush up his knowledge of what "matrices"
> actually are. Perhaps the correspondence between matrices and linear
> operators was not explained at algebra 101 ?

Perhaps you need to brush up on your knowledge of real-world constraints
on solving mathematical problems.  (Sorry, but you asked for that one :-)

--
Glen Reesor                      Opinions belong to me, not AECL Research



Wed, 04 Jun 1997 03:22:06 GMT  
 Oberon vs F-90

Quote:



>> > |>
>> > |> Concerning storage of arrays in various languages, it should be clear to
>> > |> anyone with half a brain (or with a linear algebra course 101 in their
>> > |> transcript, whichever ;-) that Fortran did it the right way.

>> > I don't understand this comment. In my experience, when a
>> > mathematician writes

>> >                      A
>> >                       ij

>> > he means the element of A at row i, column j,
>> > which seems quite a lot like row-major ordering
>> > to me.

>> Even this is just a naming convention. You may say just as well
>> that "i" is a column and "j" is a row index. Or, in abstract
>> mathematical spirit you may define a "column" as something printed
>> horizontal and a "row" as something vertical. The only thing that
>> matters is that definitions are consistent in a given piece of work.

> Yes, you can call objects by any name you want.  I would be very surprised
> to see anybody (mathematician or otherwise) refer to a horizontal list
> of numbers as a column, or a vertical one as a row.

In many books (mathematical or otherwise) column vectors are printed as rows
to save space. Have you never seen this ?

 [stuff deleted]

Quote:
>> Stings aside, the Fortran equating of A(10,10) and A(100) is just a low-level
>> trick exploiting particular addressing scheme. Long ago it seemed like a good
>> idea to provide for such a mapping, and many Fortran utility routines
>> exploited that fact. But a low-level trick is just that: a low-level trick.
>> No more than that.

> This "trick" was often part of sophisticated memory management schemes to
> squeeze the most out of a prized resource--memory.  Computers haven't always
> had such big core memory (if you'll excuse the dated term :-), and the
> benefits of virtual memory.

I still fail to see why "columns first" is better than "rows first" in
numerical algorithms. The way I see it is the following and please correct
me if I am wrong: if we are dealing with efficiency we need well optimised
array routines. It is up to their implementor to make them efficient. For this
purpose (s)he can exploit low-level tricks, why not ? But why should the
user be bothered by particular details ? All that matters is external speci-
fication. This specification says something like "A is an array, i is the
first index, j is the second index...". All I need to know is how to
interpret the results returned by the subroutine.

Since this posting partly deals with the Oberon language, let me tell you
that math packages are now being developed for Oberon too, though a bit
slowly. I expect Oberon algebra routines to be fast and efficient.
For this purpose their authors will probably use some well-established
tricks, like taking advantage of the specific ordering scheme.
In Oberon parlance these are "implementation details", which remain
hidden under the module interface. (Oberon modules contain both data
declarations and actual code.) Why should I bother what sort of advanced
tricks implementors are going to use ?  A good implementor has his bag
full of tricks and I suppose (s)he can adjust them for both row-major
and column-major cases. Or am I missing something here ? Can you show me
that "row-major" ordering cannot be exploitet while "column-major" can ?

Quote:

>> Perhaps the poster should brush up his knowledge of what "matrices"
>> actually are. Perhaps the correspondence between matrices and linear
>> operators was not explained at algebra 101 ?

> Perhaps you need to brush up on your knowledge of real-world constraints
> on solving mathematical problems.  (Sorry, but you asked for that one :-)

Perhaps you did not notice, that the original posting claimed that the
particular memory layout was supported by abstract matemathics ? I am not
unsympathetic to real-world constraints, cache efficiency and all that.
It is of course important. But for me the original claim went a bit too far.

Quote:
> Glen Reesor                      Opinions belong to me, not AECL Research


Wojtek


Thu, 05 Jun 1997 02:46:29 GMT  
 Oberon vs F-90
[Lots of bla bla bla deleted]

Quote:
> Mathematics also doesn't have to deal with manipulating large arrays of data
> that don't fit in a computer's cache.  If you know nothing about memory layout,
> you'll probably write a code that doesn't access memory sequentially, thereby
> thrashing the cache, and incurring a huge performance hit.

What has this remark to do with the original discussion? It appeared to me
that the discussion concearned just the memory layout. If we were ignoring
the memory layout, the discussion will have never happened!

Quote:
> This "trick" was often part of sophisticated memory management schemes to
> squeeze the most out of a prized resource--memory.  Computers haven't always
> had such big core memory (if you'll excuse the dated term :-), and the
> benefits of virtual memory.

The "sophisticated memory management" can be done either with the
column-wise Fortrans scheme or with the row-wise scheme. I see no point
in saying that one of them is better than the other for memory management.
The problem only occurs if you assume the wrong layout on you code.

Quote:
> Perhaps you need to brush up on your knowledge of real-world constraints
> on solving mathematical problems.  (Sorry, but you asked for that one :-)

Perhaps you need to see how your "real world constraints" changes to
nothing when you change from one "real world language", like Fortran, to
other "real world lenguage" like C. This was the point that was beeing
discussed on this thread. Or will you try to convince us that the
Fortran memory layout is "the way that God meant it"?

Gonzalo Travieso



Fri, 06 Jun 1997 02:07:15 GMT  
 Oberon vs F-90

Quote:



> > Yes, you can call objects by any name you want.  I would be very surprised
> > to see anybody (mathematician or otherwise) refer to a horizontal list
> > of numbers as a column, or a vertical one as a row.

> In many books (mathematical or otherwise) column vectors are printed as rows
> to save space. Have you never seen this ?

Yes, I have seen this.  My point was that I would be surprised to see a
column of numbers *called* a "row" of numbers.

Quote:
> > This "trick" was often part of sophisticated memory management schemes to
> > squeeze the most out of a prized resource--memory.  Computers haven't always
> > had such big core memory (if you'll excuse the dated term :-), and the
> > benefits of virtual memory.

> I still fail to see why "columns first" is better than "rows first" in
> numerical algorithms.

I don't have an opinion on whether column-major or row-major is better.

Quote:
> But why should the
> user be bothered by particular details ? All that matters is external speci-
> fication. This specification says something like "A is an array, i is the
> first index, j is the second index...". All I need to know is how to
> interpret the results returned by the subroutine.

Although I agree with this hide-the-implementation-details philosophy,
I think you're straying from your original hypothesis:

Quote:
> Perhaps the core of the discussion refers to the fact that there are many
> Fortran programs which explicitly take advantage of one particular memory
> layout.

All programs that manipulate matrices take advantage of one particular
memory layout.  If you ignore it, you'll suffer a huge performance hit.
In Fortran the memory layout is column-major.

This discussion on Fortran aside, I must admit that your ranting and raving :-)
about Oberon has tweeked my interest.  Hopefully I'll have time to check it
out in the near future.  However, as with most employers that use Fortran,
I see zero chance that mine would switch to another language.  That's life.

Now, if I could just convince some people here to use some Fortran-*77*
constructs (like else's in IF statements)  :-)

Glen Reesor                      Opinions belong to me, not AECL Research



Thu, 05 Jun 1997 23:44:17 GMT  
 Oberon vs F-90

Quote:
> [stuff deleted]
> One of the participants in the c.l.o newsgroup told that he very rapidly
> prototyped a software system using Oberon. His employer looked at
> the estimated cost of porting the code to their official language
> and gave up. They shipped the "prototype" as a finished product.

> Wojtek

Now, this is an approach that might fly around here as well.  Our company
is going through the throes of becoming a "Total Quality" company.  Any
savings in time becomes very high profile.

The prototype you alluded to: was it delivered together with the Oberon
system?  I ask because we produce embedded products which are usually very
memory-tight.  I don't think we could tolerate or even need the complete
Oberon system.

--------------------------------------------------------------

AlliedSignal Aerospace Canada           my opinions are my own



Fri, 06 Jun 1997 20:21:13 GMT  
 Oberon vs F-90

Quote:



>> This discussion on Fortran aside, I must admit that your ranting and raving
>> about Oberon has tweeked my interest.  Hopefully I'll have time to check it
>> out in the near future.  However, as with most employers that use Fortran,
>> I see zero chance that mine would switch to another language.  That's life.

>You will be most welcome to the Oberon world. Please communicate your
>experience to us. As for the employers: I myself have experienced some

Yes, jump right it.  You'll find we're pretty laid back in the
'comp.lang' scheme of things.  (Hey! When you are the best, there is no
reason to have silly little threads like 'Widespread Oberon competancy
gap' or "Wirth's defence (sic) of Oberon".  We just sit above the fray
and look down at the rest of the world.  Oh, I should mention that we
like to poke & have fun, too.  These parenthetical comments should be
taken as such.)

Quote:
>minor problems. At the end of my project I simply translated my Monte Carlo
>program to Fortran and that was it. No big deal. I was so much ahead using
>Oberon to develop the code and to complete all my simulations, that this
>piece of busy work did not bite me much. At the end I wrote my final report
>using the Oberon wordprocessor and I put all my stingy remarks under
>a hypertext fold, invisible to uninitialized. Just for fun I also included
>a few hypertext buttons. Those guys do not know what they are missing.
>Actually, they punish themselves.

Self-flaggelation is common in religious circles.  It often takes the
likes of Martin Luther or Wojtek Skulski to protest against the common
boundaries or religion.  (Have you posted any notices about the
shortcomings of Fortran on office doors lately?)

Taylor Hutt, with hammer.
A statistically significant family of non-gum chewers lives in the Netherlands.



Fri, 06 Jun 1997 20:31:18 GMT  
 
 [ 36 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Oberon vs F-90

2. Oberon vs F-90

3. Return Receipt: Re: Oberon vs F-90

4. Oberon vs F-90 and my two questions

5. Oberon vs F-90

6. Oberon vs F-90

7. FS: Fortran 90 compilers for Windows 95/NT

8. Fortran 90 vs HPF vs Fortran D

9. Fortran 77 vs Fortran 90/95

10. fortran77 vs fortran 90 or 95

11. fortran 90/95 pointers vs C pointers

12. FORTRAN 90 : Public vs. Private

 

 
Powered by phpBB® Forum Software