Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Dr. Krishnan Chittur]

Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote:

: Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article
: > The fact remains (and will for some time) that many scientific
: programmers
: > are scientists FIRST and programmers SECOND.  
........
: > So one of my reasons for Fortran still being around: you can write
: > a reasonable program which runs reasonably efficiently just by more
: > or less typing in an expression of a simple algorithm.  Fortran's "mental
: > model" of the computer is very simple.

Well said! ... I still have to find an environment that will allow
me to develop a GUI as simply as I can write Fortran Code to 
do calculations ... if there is one, please let me know.

There is this debate in the Chemical Engineering Community about
whether we should teach Fortran at all ... We are currently on the
side that says "yes" we should.  

More than Fortran itself, what we are trying to do is to teach
the elements of programming ... the idea that you should plan the
project, have an idea of what you want the program to do,
design the "structure" ... and then write the code ... when you
want to say "calculate the square root" ... find out if you need
to write the program or use something that is supplied by 
compiler or perhaps a set of callable routines written by someone
else ... 

In a programming course, students also learn how to develop a  
"set of routines" .. one problem is that at the time they are
learning to program, often they do not have the background
in math ... for example it is difficult at the freshman level
to have students attempt to write Fortran Code to solve say
linear algebraic problems ... 

Anyway ... Fortran is still around, will be around for 
a while ... students MUST know how to deal with it's
many strange properties ... 4 to 6 weeks exposing them
to elements of fortran 77 is worth the time ... 

Fortran 90 and F are I think a step in the right direction,
let's see how it develops ... 

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Area Industrial y Electromec�nica]

I agree with you completely

Jose Jimenez, msme

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Rick Hawkins]

In article <5ve7c6$f4m$1@info.uah.edu>,
Dr. Krishnan Chittur <chitturk@email.uah.edu> wrote:

>Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote:
>
>: Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article
>: > The fact remains (and will for some time) that many scientific
>: programmers
>: > are scientists FIRST and programmers SECOND.  
>........
>: > So one of my reasons for Fortran still being around: you can write
>: > a reasonable program which runs reasonably efficiently just by more
>: > or less typing in an expression of a simple algorithm.  Fortran's "mental
>: > model" of the computer is very simple.

>Well said! ... I still have to find an environment that will allow
>me to develop a GUI as simply as I can write Fortran Code to 
>do calculations ... if there is one, please let me know.

yes!!!  learning c++ after not using c for ten years took some work.
Fortran after 12 years didn't; I could sit back donw and code.

I'm not going to knock c++; it's wonderful for where it belongs.  But
for my fairly simple models that just need numbers pounded into
submission, and which won't be reused, Fortran is *much* easier, if for
no other reason than high-level I/O.  I was spending 2/3 of my time in
c++ either writing pieces builit into fortran, or looking for libraries
with the pieces.  I think I switched when i couldn't find a max(), and
couldn't figure out the single example of writing a function with
variable number of arguments (actually, i used smalltalk for a while in
between, but that's another story).

Also, the bit on needing to define new classes for array bounds
checking, rather than a compiler switch, was maddening . . .

rick
-- 
R E HAWKINS
rhawkins@iastate.edu

These opinions will not be those of ISU until they pay my retainer.

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Oleg Krivosheev]

Hi,

rhawkins@iastate.edu (Rick Hawkins) writes:

> 
> In article <5ve7c6$f4m$1@info.uah.edu>,
> Dr. Krishnan Chittur <chitturk@email.uah.edu> wrote:
> 
> >Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote:
> >
> >: Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article
> >: > The fact remains (and will for some time) that many scientific
> >: programmers
> >: > are scientists FIRST and programmers SECOND.  
> >........
> >: > So one of my reasons for Fortran still being around: you can write
> >: > a reasonable program which runs reasonably efficiently just by more
> >: > or less typing in an expression of a simple algorithm.  Fortran's "mental
> >: > model" of the computer is very simple.
> 
> >Well said! ... I still have to find an environment that will allow
> >me to develop a GUI as simply as I can write Fortran Code to 
> >do calculations ... if there is one, please let me know.
> 
> yes!!!  learning c++ after not using c for ten years took some work.
> Fortran after 12 years didn't; I could sit back donw and code.

well, if you're talking about F77, yes. FYI, there are already
F90 and F95 here. I doubt you can program in F95 without
learning - just as you did with C++.

> I'm not going to knock c++; it's wonderful for where it belongs.  But
> for my fairly simple models that just need numbers pounded into
> submission, and which won't be reused, Fortran is *much* easier, if for
> no other reason than high-level I/O.  I was spending 2/3 of my time in
> c++ either writing pieces builit into fortran, or looking for libraries
> with the pieces.  I think I switched when i couldn't find a max(), and
> couldn't figure out the single example of writing a function with
> variable number of arguments (actually, i used smalltalk for a while in
> between, but that's another story).

hmm...

cannot find max() in c++?
couldn't figure how to write function with variable numbers
of arguments?

there is something wrong with your C++ installation
or with your C/C++ book.

OK

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Rick Hawkins]

In article <vi8k9ge42bw.fsf@drabble.fnal.gov>,
Oleg Krivosheev  <kriol@fnal.gov> wrote:

>rhawkins@iastate.edu (Rick Hawkins) writes:

>> yes!!!  learning c++ after not using c for ten years took some work.
>> Fortran after 12 years didn't; I could sit back donw and code.

>well, if you're talking about F77, yes. FYI, there are already
>F90 and F95 here. I doubt you can program in F95 without
>learning - just as you did with C++.

I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops 20
back then.

>> I'm not going to knock c++; it's wonderful for where it belongs.  But
>> for my fairly simple models that just need numbers pounded into
>> submission, and which won't be reused, Fortran is *much* easier, if for
>> no other reason than high-level I/O.  I was spending 2/3 of my time in
>> c++ either writing pieces builit into fortran, or looking for libraries
>> with the pieces.  I think I switched when i couldn't find a max(), and
>> couldn't figure out the single example of writing a function with
>> variable number of arguments (actually, i used smalltalk for a while in
>> between, but that's another story).

>cannot find max() in c++?

I tried.  I looked.  I'm convinced it must be there, but . . .

>couldn't figure how to write function with variable numbers
>of arguments?

In the two books that I had, there was a single example, whihc managed
not to explain. I  wasn't just the issue of variable number of
arguments, but of arbitrarily large variable numbers 
(i wanted my max()!  :)


>there is something wrong with your C++ installation
>or with your C/C++ book.

I assume it's the books; the compiler was either DEC cc or gcc; i forget
now.

rick


-- 
R E HAWKINS
rhawkins@iastate.edu

These opinions will not be those of ISU until they pay my retainer.

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Oleg Krivosheev]

Hi, Rick


rhawkins@iastate.edu (Rick Hawkins) writes:

> 
> 
> In article <vi8k9ge42bw.fsf@drabble.fnal.gov>,
> Oleg Krivosheev  <kriol@fnal.gov> wrote:
> 
> >rhawkins@iastate.edu (Rick Hawkins) writes:
> 
> >> yes!!!  learning c++ after not using c for ten years took some work.
> >> Fortran after 12 years didn't; I could sit back donw and code.
> 
> >well, if you're talking about F77, yes. FYI, there are already
> >F90 and F95 here. I doubt you can program in F95 without
> >learning - just as you did with C++.
> 
> I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops 20
> back then.

well, that's exactly what i was asking about - there were NO
F90/F95 twelve years ago ! If you're using F90 now, you learned
it somehow. Either i misunderstood something or our claim

"> >> Fortran after 12 years didn't; I could sit back donw and code."

is wrong.

> >cannot find max() in c++?
> 
> I tried.  I looked.  I'm convinced it must be there, but . . .
> 
> >couldn't figure how to write function with variable numbers
> >of arguments?
> 
> In the two books that I had, there was a single example, whihc managed
> not to explain. I  wasn't just the issue of variable number of
> arguments, but of arbitrarily large variable numbers 
> (i wanted my max()!  :)

sorry, i have only min ;)

well, try example below for min with
arbitrary larger number of arguments. Hope it can help

#include <assert.h>
#include <stdio.h>
#include <stdarg.h>

double
dmin( int nofargs, ... ) {

  double res = 1.0e+38, arg;
  int j;
  va_list ap;
  
  assert( nofargs > 1 );

  va_start(ap, nofargs );

  for( j = 0; j < nofargs; ++j ) {
    arg=va_arg( ap, double );
    if ( arg < res ) {
      res = arg;
    }
  }
  va_end(ap);
  return res;
}

int
main( void ) {

  printf( "%e\n", dmin( 2, 1.0, 2.0 ) );
  
  printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) );
  
  printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) );

  return 0;
}


> >there is something wrong with your C++ installation
> >or with your C/C++ book.
> 
> I assume it's the books; the compiler was either DEC cc or gcc; i forget
> now.

code above works fine with gcc on Sparc/Solaris 2.5 box

regards

OK

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Gary L. Scott]

Oleg Krivosheev wrote:

> Hi, Rick
>
> rhawkins@iastate.edu (Rick Hawkins) writes:
>
> >
> >
> > In article <vi8k9ge42bw.fsf@drabble.fnal.gov>,
> > Oleg Krivosheev  <kriol@fnal.gov> wrote:
> >
> > >rhawkins@iastate.edu (Rick Hawkins) writes:
> >
> > >> yes!!!  learning c++ after not using c for ten years took some
> work.
> > >> Fortran after 12 years didn't; I could sit back donw and code.
> >
> > >well, if you're talking about F77, yes. FYI, there are already
> > >F90 and F95 here. I doubt you can program in F95 without
> > >learning - just as you did with C++.
> >
> > I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops
> 20
> > back then.
>
> well, that's exactly what i was asking about - there were NO
> F90/F95 twelve years ago ! If you're using F90 now, you learned
> it somehow. Either i misunderstood something or our claim
>
> "> >> Fortran after 12 years didn't; I could sit back donw and code."
>
> is wrong.

However, a very large percentage of Fortran 90 features (even some of
the new intrinsics) have been in some FORTRAN 77 compilers for
minicomputers as extensions since the late 70's/early 80's.  The main
exceptions being array syntax and "non-sequence" derived types.  So some
of us have had a long time to learn them.  I've used the following since
around 1981:

block do/end do (also for/end for, loop/end loop)
! comment
free form source (almost identical to the current standard)
variable # calling arguments (not F90/not keyword arguments/kinda messy)

"Purdue" bit manipulation intrinsics
direct physical memory address access ("Cray pointer" substitute?/not
F90)
; record separator
I'm sure others that I can't recall right now...

That's why I have such a hard time believing how long it took to get
some of them standardized and why some of them are still not in the
standard (but are rumored).

>
>
> > >cannot find max() in c++?
> >
> > I tried.  I looked.  I'm convinced it must be there, but . . .
> >
> > >couldn't figure how to write function with variable numbers
> > >of arguments?
> >
> > In the two books that I had, there was a single example, whihc
> managed
> > not to explain. I  wasn't just the issue of variable number of
> > arguments, but of arbitrarily large variable numbers
> > (i wanted my max()!  :)
>
> sorry, i have only min ;)
>
> well, try example below for min with
> arbitrary larger number of arguments. Hope it can help
>
> #include <assert.h>
> #include <stdio.h>
> #include <stdarg.h>
>
> double
> dmin( int nofargs, ... ) {
>
>   double res = 1.0e+38, arg;
>   int j;
>   va_list ap;
>
>   assert( nofargs > 1 );
>
>   va_start(ap, nofargs );
>
>   for( j = 0; j < nofargs; ++j ) {
>     arg=va_arg( ap, double );
>     if ( arg < res ) {
>       res = arg;
>     }
>   }
>   va_end(ap);
>   return res;
> }
>
> int
> main( void ) {
>
>   printf( "%e\n", dmin( 2, 1.0, 2.0 ) );
>
>   printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) );
>
>   printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) );
>
>   return 0;
> }
>
> > >there is something wrong with your C++ installation
> > >or with your C/C++ book.
> >
> > I assume it's the books; the compiler was either DEC cc or gcc; i
> forget
> > now.
>
> code above works fine with gcc on Sparc/Solaris 2.5 box
>
> regards
>
> OK

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Rick Hawkins]

In article <vi8oh5keyy1.fsf@drabble.fnal.gov>,
Oleg Krivosheev  <kriol@fnal.gov> wrote:

>Hi, Rick

hi

>rhawkins@iastate.edu (Rick Hawkins) writes:

>> In article <vi8k9ge42bw.fsf@drabble.fnal.gov>,
>> Oleg Krivosheev  <kriol@fnal.gov> wrote:

>> >rhawkins@iastate.edu (Rick Hawkins) writes:

>> >> yes!!!  learning c++ after not using c for ten years took some work.
>> >> Fortran after 12 years didn't; I could sit back donw and code.

>> >well, if you're talking about F77, yes. FYI, there are already
>> >F90 and F95 here. I doubt you can program in F95 without
>> >learning - just as you did with C++.

>> I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops 20
>> back then.

>well, that's exactly what i was asking about - there were NO
>F90/F95 twelve years ago ! If you're using F90 now, you learned
>it somehow. Either i misunderstood something or our claim

Back then I used F77 and almost F77 (seems to me that DEC FORTRAN on
TOPS 20 was somewhere between 66 and 77.  But hey, we had a
preproccessor fof this c++ thing :).   That was about 83-84.  I used
some c back then, too.

Rolling ahead to 95, learing c++ took work.  I recoded a summer's worth
of c++ and smalltalk to fortran 77 in a day and a half, not having
looked at fortran since 84.

Roll ahead to a couple of weeks ago, i picked up a F90 book, read a
couple of chapters, and am happily using lots of it.

>sorry, i have only min ;)

>
>well, try example below for min with
>arbitrary larger number of arguments. Hope it can help

I'm definitely saving this one.  Thanks.  There's a coupel of future
pojects that will need objects, which will probably mean some c++.
-- 
R E HAWKINS
rhawkins@iastate.edu

These opinions will not be those of ISU until they pay my retainer.

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Xingzeng Liu]

It should be known that C++ and C are totally different languages. I
think for every one, to learn C++ is much more difficult than to learn
others. If you can learn C, FORTRAN, or PASCAL with 2 weeks, then I
think to learn C++ at least needs you 1 month. And you still need more
than 1 month to practice it, to know the real style of C++. 

I use C++ for 5 years. I think C++ is a very good language. It is much
suitable to do large complex simulations. It is reported in CERN that
their large C++ simulation software (transfered from their original
FORTRAN code) is faster than FORTRAN code. 

But for some small problem, C++ is not so good. And the depency of the
non-standard library is also a big problem for C++. The super point in
C++ is their ability to reuse. And there are so many different library
of the basic object library. You may find you loss yourself when work in
another platform.  It is also very weak in numerical computation. So now
I try to use FORTRAN 90. In my point of view, the new features such as
Module, type etc. much improve the convenice in writing programs.

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[const]

Oleg Krivosheev wrote:
> 
> [skipped]
> 
> sorry, i have only min ;)
> 
> well, try example below for min with
> arbitrary larger number of arguments. Hope it can help
> 
> #include <assert.h>
> #include <stdio.h>
> #include <stdarg.h>
> 
> double
> dmin( int nofargs, ... ) {
> 
>   double res = 1.0e+38, arg;
>   int j;
>   va_list ap;
> 
>   assert( nofargs > 1 );
> 
>   va_start(ap, nofargs );
> 
>   for( j = 0; j < nofargs; ++j ) {
>     arg=va_arg( ap, double );
>     if ( arg < res ) {
>       res = arg;
>     }
>   }
>   va_end(ap);
>   return res;
> }
> 
> int
> main( void ) {
> 
>   printf( "%e\n", dmin( 2, 1.0, 2.0 ) );
> 
>   printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) );
> 
>   printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) );
> 
>   return 0;
> }
> 
> [skipped]
> 
    OK, just to be pedantic, the previous  example shows very fine
the  difference  between  fortran and  C    in computations. Since
min/max are  standard fortran functions, it  can be  supposed they
are maximally   optimized  with no  regards  to   number  of their
arguments (just because the compiler takes care of them).
    In the  contrary,   in the example,  we  have overhead of  the
arguments  number  evaluation and overhead of  implementation (not
necessarily    this   one,  generally   almost    any  non-trivial
non-built-in operation has  some overhead -   there has been  some
reason   to  add  into  C  libraries  memcpy,   memcmp  and so  on
functions).
    Moreover the idea of such an implementation contains two great
places   to  make   bugs and definitely     any  user  of  such an
implementation will be  doing the bugs  endlessly. Firstly, it  is
the  programmer who should worry about  conformity of the declared
number of  arguments to the actual  one. In such cases, generally,
adding or  removing  actual arguments, people  tend   to forget to
correct the  declared number. Secondly,  there is no  way for type
checking and  for type conversions, usage  of 1 instead of  1.0 in
the arguments list will cause very nasty problems.
    Using  C++ and not C, most  probably, I would try to implement
the min function in the following way:

inline double min(double v1, double v2) {
  return v1<v2 ? v1 : v2;
}
inline double min(double v1, double v2, double v3) {
  double v=min(v1,v2); return v<v3 ? v : v3;
}
inline double min(double v1, double v2, double v3, double v4) {
  double v=min(v1,v2,v3); return v<v4 ? v : v4;
}
inline double min(double v1, double v2, double v3, double v4, double v5)
{
  double v=min(v1,v2,v3,v4); return v<v5 ? v : v5;
}
// and so on

    Such  a way  doesn't seem elegant enough and it only  emulates
arbitrary number of min-function arguments but it solves the types
and the  number-conformity problems.   Trying to  use  non-defined
min(huge-arguments-number),   a programmer  just gets  compilation
error and can easily extend the  set of his min-functions. And the
last but not least: the following example compiled with -O3 option
with Sparc C++ 4.2 patch 104631-03 and
  started  on SunOS 5.5.1 SUNW,Ultra-2 produces
    dmin: 3.04 seconds
    overloaded min: 1.11 seconds
  started on SunOS 5.5.1 SUNW,SPARCstation-4 produces:
    dmin: 9.32 seconds
    overloaded min: 4.89 seconds
and compiled  with -O option with HP  C++  A.03.72; and started on
HP-UX A.09.05 9000/715 produces:
    dmin: 4.63 seconds
    overloaded min: 1.58 seconds

#include <sys/times.h>
#include <limits.h>
#include <iostream.h>

extern double dmin(int, double, ...);
//------------------------------------------------------
inline double min(double v1, double v2) {
  return v1<v2 ? v1 : v2;
}
inline double min(double v1, double v2, double v3) {
  double v=min(v1,v2); return v<v3 ? v : v3;
}
inline double min(double v1, double v2,
		  double v3, double v4) {
  double v=min(v1,v2,v3); return v<v4 ? v : v4;
}
inline double min(double v1, double v2,
		  double v3, double v4, double v5) {
  double v=min(v1,v2,v3,v4); return v<v5 ? v : v5;
}
//------------------------------------------------------
int main(void) {
  struct tms ts;
  clock_t clk, start;
  unsigned loop_len=6000000;
  unsigned loop;
  double dummy=0;

  start=times(&ts);
  loop=loop_len;
  while (loop--)
    dummy=dmin(5,1.0,2.0,3.0,dummy,(double)loop);
  clk=times(&ts)-start;
  cout << "    dmin: "
       << double(clk)/CLK_TCK << " seconds" << endl;

  start=times(&ts);
  loop=loop_len;
  while (loop--)
    dummy=min(1.0,2.0,3.0,dummy,loop);
  clk=times(&ts)-start;
  cout << "    overloaded min: "
       << double(clk)/CLK_TCK << " seconds" << endl;

  return 0;
}
//------------------------------------------------------
#include <stdarg.h>

double dmin(int nofargs, double d, ...)  {
  va_list ap; va_start(ap,d);

  while (--nofargs) {
    double v=va_arg(ap,double);
    if (v<d)
      d=v;
  }

  va_end(ap); return d;
}
//-----------------------------------------------------
//                     End of File
//-----------------------------------------------------

//------------------------------------------------------------------
// Opinions expressed here are my own only
//
// Constantine Antonovich,               Tel.  : ++972-8-942-3819
// software engineer,                    Fax   : ++972-8-942-3955
// Orbotech Ltd., P.O.Box 215,           Email: const@orbotech.co.il
// Yavne 81102, Israel
//------------------------------------------------------------------

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Oleg Krivosheev]

Hi,

Constantine Antonovich: <const@orbotech.co.il> writes:

> 
> Oleg Krivosheev wrote:
> > 
> > [skipped]
> > 
> > sorry, i have only min ;)
> > 
> > well, try example below for min with
> > arbitrary larger number of arguments. Hope it can help
> > 
> > #include <assert.h>
> > #include <stdio.h>
> > #include <stdarg.h>
> > 
> > double
> > dmin( int nofargs, ... ) {
> > 
> >   double res = 1.0e+38, arg;
> >   int j;
> >   va_list ap;
> > 
> >   assert( nofargs > 1 );
> > 
> >   va_start(ap, nofargs );
> > 
> >   for( j = 0; j < nofargs; ++j ) {
> >     arg=va_arg( ap, double );
> >     if ( arg < res ) {
> >       res = arg;
> >     }
> >   }
> >   va_end(ap);
> >   return res;
> > }
> > 
> > int
> > main( void ) {
> > 
> >   printf( "%e\n", dmin( 2, 1.0, 2.0 ) );
> > 
> >   printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) );
> > 
> >   printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) );
> > 
> >   return 0;
> > }
> > 
> > [skipped]
> > 
>     OK, just to be pedantic, the previous  example shows very fine
> the  difference  between  fortran and  C    in computations. Since

gu ?

> min/max are  standard fortran functions, it  can be  supposed they
> are maximally   optimized  with no  regards  to   number  of their
> arguments (just because the compiler takes care of them).

well, FYI, being standard means only that - being standard.
Compiler is free to optimize or to insert 5min  loop
into min/max function.

>     In the  contrary,   in the example,  we  have overhead of  the
> arguments  number  evaluation 

sure...

if you know how do not evaluate number of arguments
for functions (not min/max in particular) with arbitrary
number of arguments, please share your knowledge with us.

> and overhead of  implementation (not
> necessarily    this   one,  generally   almost    any  non-trivial
> non-built-in operation has  some overhead -   there has been  some
> reason   to  add  into  C  libraries  memcpy,   memcmp  and so  on
> functions).

what do you mean "overhead"? Can you clarify ?

>     Using  C++ and not C, most  probably, I would try to implement
> the min function in the following way:
> 
> inline double min(double v1, double v2) {
>   return v1<v2 ? v1 : v2;
> }
> inline double min(double v1, double v2, double v3) {
>   double v=min(v1,v2); return v<v3 ? v : v3;
> }
> inline double min(double v1, double v2, double v3, double v4) {
>   double v=min(v1,v2,v3); return v<v4 ? v : v4;
> }
> inline double min(double v1, double v2, double v3, double v4, double v5)
> {
>   double v=min(v1,v2,v3,v4); return v<v5 ? v : v5;
> }

please, don't change the nature of the problem - Rick
was asking about min/max function with ARBITRARY
number of arguments.

>     Such  a way  doesn't seem elegant enough and it only  emulates
> arbitrary number

nope. it's not. If the problem is to provide function
which can handle arbitrary number of arguments,
it cannot be solved by providing function(s) which
can handle limited number of arguments. Try to reread
logic textbook next time.

>   started  on SunOS 5.5.1 SUNW,Ultra-2 produces
>     dmin: 3.04 seconds
>     overloaded min: 1.11 seconds
>   started on SunOS 5.5.1 SUNW,SPARCstation-4 produces:
>     dmin: 9.32 seconds
>     overloaded min: 4.89 seconds
> and compiled  with -O option with HP  C++  A.03.72; and started on
> HP-UX A.09.05 9000/715 produces:
>     dmin: 4.63 seconds
>     overloaded min: 1.58 seconds

well, you compare apples and oranges.

You provided solution for related but
another problem than Rick was asking for.

still, you know better way to handle
functions with arbitrary number of
arguments (using C++, templates, exceptions
whatever), please, share it with us.

OK

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Vanesch P.]

Dr. Krishnan Chittur (chitturk@email.uah.edu) wrote:
: Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote:

: : Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article
: : > The fact remains (and will for some time) that many scientific
: : programmers
: : > are scientists FIRST and programmers SECOND.  
: ........
: : > So one of my reasons for Fortran still being around: you can write
: : > a reasonable program which runs reasonably efficiently just by more
: : > or less typing in an expression of a simple algorithm.  Fortran's "mental
: : > model" of the computer is very simple.

: Well said! ... I still have to find an environment that will allow
: me to develop a GUI as simply as I can write Fortran Code to 
: do calculations ... if there is one, please let me know.

I think this is an essential point.  FORTRAN is well-suited to do
calculations and hard-core scientific computation.  But more 
complex structures (a GUI is program-wise a lot more complicated
than a scientific calculation) are not dealt too well with in
fortran I think.  I've seen this in the high-energy community.
Both elements are present there: complex software systems and
hard-core scientific computing.  Well, I've seen quite a mess
in the FORTRAN implementation (rather ad hoc) of the complicated
datastructures that had to be manipulated.  It would have been
much better done (and the tendency now is - finally - to switch
to things like C++) in a language suited for the task.

On the other hand, I've also seen the opposite.  A collegue of mine
wrote a MONSTER program in C++ to do some straightforward matrix
manipulations.  The graphical user interface launches tens and tens
of windows in which one can manipulate parameters, look at graphs etc...
He worked for almost a year on the thing.  He is a computer scientist,
btw, I'm not.  I'm an engineer and physicist.
It takes about 10 minutes to even start up the thing, getting your
X-terminal cluttered with all those windows.
I've done the same thing in F77, but with an ASCII steering file,
in about a month... and guess what ?  my program tackles systems 
he can't even dream of handling in just a few hours (his can't do it,
it just runs out of 1 GB swap space !!) I get a nice ASCII file
with my results. For smaller systems, my program is about 20 times
faster, with less memory, than his, on the same system.

I think every language has its uses.  FORTRAN is old and 
very elementary on the conceptual level.  For most modern
computing applications (graphics, process steering, multi-user
things etc) it is simply too elementary.
But for applications where these elementary concepts are
sufficient (such as scientific computing - which is usually
advanced on the scientific level and very simple on the 
computational level) it allows indeed to write a reasonably simple
program that behaves resonably well by someone who has some
reasonable knowledge of computers but is not a computer scientist, 
without involving a lot of abstract computer-think.

But if the project is too ambitious, and the abstract computer
think is really needed, well... I don't think it is a good idea
to do it in FORTRAN.


cheers,
Patrick.

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Jeffrey Templon]

pvanesch@vub.ac.be (Vanesch P.) writes:

> I think this is an essential point.  FORTRAN is well-suited to do
> calculations and hard-core scientific computation.  But more 
> complex structures (a GUI is program-wise a lot more complicated
> than a scientific calculation) are not dealt too well with in
> fortran I think.  I've seen this in the high-energy community.
> Both elements are present there: complex software systems and
> hard-core scientific computing.  Well, I've seen quite a mess
> in the FORTRAN implementation (rather ad hoc) of the complicated
> datastructures that had to be manipulated.  It would have been
> much better done (and the tendency now is - finally - to switch
> to things like C++) in a language suited for the task.

I agree that there are problems that get too complex for Fortran, at
least for Fortran-77.  I'm not sure these limitations apply to
Fortran-90, given the appearance of derived types and allocatable arrays.
Perhaps F90 is not enough, but I think C++ is not the answer for
people who aren't professional programmers.  Ada looks like it might
be easier for a normal human to work with and read, but I haven't spent
much time playing with it.

						JAT

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Gary L. Scott]

The problem of developing a GUI in Fortran is one of designing an
appropriate API for Fortran.  This used to be done quite commonly
(language-specific API bindings).  I have developed "graphical user
interfaces" in Fortran that were highly functional (a little slow, it
was 10 years ago) and very easy to develop because the API was designed
"appropriately".  The problem is really one of UNIX/Windows APIs being
"low-level" C-oriented APIs.  It is great that Fortran is being extended
in ways which allow it to be able to call other languages and APIs
designed for other languages, however, I shouldn't have to.  OS or
compiler vendors should supply language tailored API bindings.  It's
more work for them, but a lot less work for me, as an application
developer who just wants to produce a useful product without the hassle
of inter language communication which requires me to essentially know
two (or more) languages, usually one of which has an appalling syntax
that makes me cringe).  I vote for a reduction in complexity (the
K.I.S.S. principle) in the area of OS API calls from Fortran (or PASCAL
or COBOL or PL/1 or <insert legacy language here>. Is anybody
listening?  Come on, there's only 1500 or so WIN API calls, how much
work could that be...).

Jeffrey Templon wrote:

> pvanesch@vub.ac.be (Vanesch P.) writes:
>
> > I think this is an essential point.  FORTRAN is well-suited to do
> > calculations and hard-core scientific computation.  But more
> > complex structures (a GUI is program-wise a lot more complicated
> > than a scientific calculation) are not dealt too well with in
> > fortran I think.  I've seen this in the high-energy community.
> > Both elements are present there: complex software systems and
> > hard-core scientific computing.  Well, I've seen quite a mess
> > in the FORTRAN implementation (rather ad hoc) of the complicated
> > datastructures that had to be manipulated.  It would have been
> > much better done (and the tendency now is - finally - to switch
> > to things like C++) in a language suited for the task.
>
> I agree that there are problems that get too complex for Fortran, at
> least for Fortran-77.  I'm not sure these limitations apply to
> Fortran-90, given the appearance of derived types and allocatable
> arrays.
> Perhaps F90 is not enough, but I think C++ is not the answer for
> people who aren't professional programmers.  Ada looks like it might
> be easier for a normal human to work with and read, but I haven't
> spent
> much time playing with it.
>
>                                                 JAT

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Jenn-Ching Luo]

Gary L. Scott <scottg@flash.net> wrote in article
<341F22C2.C46CE5F4@flash.net>...
> The problem of developing a GUI in Fortran is one of designing an
> appropriate API for Fortran.  .....
> .................................................. 
>                                       however, I shouldn't have to.  OS
or
> compiler vendors should supply language tailored API bindings.  It's
> more work for them, but a lot less work for me, as an application
> developer who just wants to produce a useful product without the hassle
> of inter language
> 


Just like most of developers, I started programming Windows Applications in
C++ for a short period. I personal like to use Fortran, and I gave up C++
for Windows programming. There is no trouble and problem to call WIN API
from Fortran.

If compiler (i.e. Fortran) vendors can provide more info, examples, or
documents for programming Windows applications (not quick win) in Fortran,
that certainly may help Fortran programmers.



Jenn-Ching Luo
http://www.Equation.com/People/Luo.htm

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Gary L. Scott]

Jenn-Ching Luo wrote:

> Gary L. Scott <scottg@flash.net> wrote in article
> <341F22C2.C46CE5F4@flash.net>...
> > The problem of developing a GUI in Fortran is one of designing an
> > appropriate API for Fortran.  .....
> > ..................................................
> >                                       however, I shouldn't have to.
> OS
> or
> > compiler vendors should supply language tailored API bindings.  It's
>
> > more work for them, but a lot less work for me, as an application
> > developer who just wants to produce a useful product without the
> hassle
> > of inter language
> >
>
> Just like most of developers, I started programming Windows
> Applications in
> C++ for a short period. I personal like to use Fortran, and I gave up
> C++
> for Windows programming. There is no trouble and problem to call WIN
> API
> from Fortran.
>
> If compiler (i.e. Fortran) vendors can provide more info, examples, or
>
> documents for programming Windows applications (not quick win) in
> Fortran,
> that certainly may help Fortran programmers.
>
> Jenn-Ching Luo
> http://www.Equation.com/People/Luo.htm

This is highly dependent upon your compiler's support for extensions to
the standard call syntax.  If you're calling Windows APIs, you're
probably not programming in "standard compliant" Fortran (when you use
these extensions).  Some people don't mind or require this.  I prefer
the simpler call syntax of "standard" Fortran.

Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Jeffrey Templon]

"Igor Chudov @ home" <ichudov@algebra.com> writes:

> Brian Thomson <thomson@vnet.ibm.com> wrote:

> * a FORTRAN optimizer knows that A and B cannot be modified by the

 [ ... ]

> * In C++ there is no such guarantee (unless you supply one
> * outside the language via a #pragma), and it makes a noticeable
> * difference in these matrix algorithms that are a big part of
> * scientific programming.
> 
> Well, the programmer of a Matrix class has to know what he is doing.
> Making C++ code efficient may be harder than writing efficient fortran
> code, but it is not impossible.

This is a good point, but perhaps not in the way that Igor intended.
One of the main reasons I tend to push Fortran (or something similar,
like Ada or Python ... although maybe not everyone would see what
I mean by "similar" here ;-) is that with stuff like C++, you *do*
have to know what you are doing, or you will make a mess of it.
The fact remains (and will for some time) that many scientific programmers
are scientists FIRST and programmers SECOND.  Turning the average
physicist/programmer (at least in my field) loose with a C++ compiler
is like giving your car keys to your eight-year-old.  A few of
them would actually be able to drive, but most of them would cause
big damage trying.

So one of my reasons for Fortran still being around: you can write
a reasonable program which runs reasonably efficiently just by more
or less typing in an expression of a simple algorithm.  Fortran's "mental
model" of the computer is very simple.

						JAT

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Joseph M. O'Leary]

Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article
<m34t7q3bcc.fsf_-_@studbolt.physast.uga.edu>...
> One of the main reasons I tend to push Fortran (or something similar,
> like Ada or Python ... although maybe not everyone would see what
> I mean by "similar" here ;-) is that with stuff like C++, you *do*
> have to know what you are doing, or you will make a mess of it.
> The fact remains (and will for some time) that many scientific
programmers
> are scientists FIRST and programmers SECOND.  Turning the average
> physicist/programmer (at least in my field) loose with a C++ compiler
> is like giving your car keys to your eight-year-old.  A few of
> them would actually be able to drive, but most of them would cause
> big damage trying.
> 
> So one of my reasons for Fortran still being around: you can write
> a reasonable program which runs reasonably efficiently just by more
> or less typing in an expression of a simple algorithm.  Fortran's "mental
> model" of the computer is very simple.

I agree with you. I spent the first 4 years of my professional career
working a large scale VAX/VMS Over-the-Horizon Radar project that was
written almost totally in FORTRAN.  When I say large scale, I'm talking
about something that required 2 VAX 6000/430 mainframes and, employed about
70 or 80 concurrent processes

Then I spent about a year and a half working on a Visual C++/Windows NT
project that replaced a large portion of the older project -- mainly the UI
code.   The difference between the 2 software development styles was like
night and day.  In the old system, you had to know beforehand exactly how
much memory your app (or process) required.  It was all allocated when the
process started.  If you data outgrew that size, the process crashed. 

Also, since it was in FORTRAN, the code read like...well like BASIC.  It
was very easy to pick up and very straightforward.  All code paths were
very structured, hierarchical, and BIG.  (Huge).  I think we documented
very well what we did and wrote some very clean code.  We didn't try to
force old, procedural programming techniquest on to an object-oriented
langauge.  We accomplished the same task with probably less than one-third
as many lines of code as the FORTRAN.

Still, I don't envy the long-time FORTRAN programmer who has to switch from
maintaining the old code base to maintaining the new one, even if it is
much less code to look at.  It requires quite a philosophical shift.  

Joe O'

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[James F Cornwall]

Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote:


: Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article
: <m34t7q3bcc.fsf_-_@studbolt.physast.uga.edu>...
: > One of the main reasons I tend to push Fortran (or something similar,
: > like Ada or Python ... although maybe not everyone would see what
: > I mean by "similar" here ;-) is that with stuff like C++, you *do*
: > have to know what you are doing, or you will make a mess of it.
: > The fact remains (and will for some time) that many scientific
: programmers
: > are scientists FIRST and programmers SECOND.  Turning the average
: > physicist/programmer (at least in my field) loose with a C++ compiler
: > is like giving your car keys to your eight-year-old.  A few of
: > them would actually be able to drive, but most of them would cause
: > big damage trying.
: > 
: > So one of my reasons for Fortran still being around: you can write
: > a reasonable program which runs reasonably efficiently just by more
: > or less typing in an expression of a simple algorithm.  Fortran's "mental
: > model" of the computer is very simple.

: I agree with you. I spent the first 4 years of my professional career
: working a large scale VAX/VMS Over-the-Horizon Radar project that was
: written almost totally in FORTRAN.  When I say large scale, I'm talking
: about something that required 2 VAX 6000/430 mainframes and, employed about
: 70 or 80 concurrent processes

Oh, God - I spent more time than I care to remember working on the 
OTH-B project, too.  My aspect was sending the ionospheric "weather" 
forecasts to your system (using an ancient Univac terminal protocol  
<U200> bastardized to talk to a VAX...).  Our code was a hodgepodge 
of Fortrans (IV, V, & 77) and assmbler code, much of it created by 
scientist/programmers as described above.

Given a choice between any flavor Fortran and any flavor of C, FORTRAN
wins hands down for me and my style of thinking.  The language does 
what it needs to do and still keeps things simple enough to be usable 
for those of us below the stratosphere.....

Just my $0.02 worth, YMMV.   :-)

Jim Cornwall
(ex-USAF, now working on groundwater modeling...Using Fortran!)

: Then I spent about a year and a half working on a Visual C++/Windows NT
: project that replaced a large portion of the older project -- mainly the UI
: code.   The difference between the 2 software development styles was like
: night and day.  In the old system, you had to know beforehand exactly how
: much memory your app (or process) required.  It was all allocated when the
: process started.  If you data outgrew that size, the process crashed. 

: Also, since it was in FORTRAN, the code read like...well like BASIC.  It
: was very easy to pick up and very straightforward.  All code paths were
: very structured, hierarchical, and BIG.  (Huge).  I think we documented
: very well what we did and wrote some very clean code.  We didn't try to
: force old, procedural programming techniquest on to an object-oriented
: langauge.  We accomplished the same task with probably less than one-third
: as many lines of code as the FORTRAN.

: Still, I don't envy the long-time FORTRAN programmer who has to switch from
: maintaining the old code base to maintaining the new one, even if it is
: much less code to look at.  It requires quite a philosophical shift.  

: Joe O'