HDTenEightyP/NetNews huggingface dataset:
From: burley@geech.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: Small Language Wanted
Date: 28 Aug 92 15:54:38 GMT
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
In-reply-to: mbk@lyapunov.ucsd.edu's message of 27 Aug 92 23:00:31 GMT

In article <17jmqfINNmrc@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:

   How does C know when compiling foo.c the difference :

   cc -c foo.c
   cc -o foo foo.o -lm

   vs.

   cc -c foo.c
   cc -c pow.c
   cc -o foo foo.o pow.o -lm

   ???

   Or is this a resolved problem?

It's resolved, in essentially the same way as:

prog.f:
      PRINT *,MAX(3,4)
      END

max.f:
      INTEGER FUNCTION MAX(I,J)
      MAX = I+J
      END

g77 -c prog.f
g77 -o prog prog.o ...

vs.

g77 -c prog.f
g77 -c max.f
g77 -o prog prog.o max.o ...

In Fortran, the lack of "EXTERNAL MAX" or equivalent means you've referred
to MAX the intrinsic in prog.f, independent of whether you've got an external
function named MAX.  In C, the use of "#include <math.h>" means you've
referred to the "built-in" pow(), independent of whether you've got an external
function named pow().  Of course, C doesn't have to keep the built-in names
separate from the external names like Fortran, so in Fortran you can always
be sure that prog.f invokes MAX the intrinsic while other program units could
still invoke MAX your external function, while in C, you might or might not
get away with that, depending on the system you're using (i.e. it's not
portable).

   Question:  Do you know which real live C compilers that people can buy or
   steal which do in fact perform the optimizations that we're talking about?

Well, I know GNU C has code to replace things like memcpy() with machine
code, sometimes depending on things like small amount of data being copied,
so it could use the same mechanism to handle pow() if it wanted.  But I haven't
looked at this for some time.  And I don't know if that code is enabled on any
machines anyway, though it might be.
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
From: JRBANGA@poppy.ucdavis.edu (JULIO RODRIGUEZ BANGA)
Newsgroups: comp.lang.fortran
Subject: OOP, reusability and Fortran
Date: 26 Aug 92 20:30:48 GMT
Organization: University of California, Davis
X-News-Reader: VMS NEWS 1.20


 Hi there.

 In these days we hear and read a lot of stuff about reusability using object
oriented programming languages like C++. Well, scientists have been reusing
Fortran modules for a long, long time. Some computer science experts seem to
have discovered reusability last night. 
 
 I use Fortran because I get my work done and, what is most, I reuse my modules
all the time. Who needs C++ (for numerical work)? Long life to Fortran.

 Regards,   Julio.
Xref: sparky comp.lang.fortran:3278 comp.std.c:2537
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Newsgroups: comp.lang.fortran,comp.std.c
Subject: Re: Small Language Wanted
Date: 30 Aug 92 07:32:38 GMT
Organization: Computer Science, University of Melbourne, Australia

burley@geech.gnu.ai.mit.edu (Craig Burley) writes:

>In article <1992Aug28.181327.25214@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>
>   I apologise for posting this incorrect statement.  In fact, all library
>   function names in ANSI standard C are reserved - the user can't define
>   his own.  So the above comment only applies to old K&R implementations
>   which allow the user to do so.  (It's what I get for remembering an old
>   public review copy of the C standard better than the final version.)
>
>Hmm, I don't remember this being true.  I thought pow, for example, was
>a reserved word only if one #include'd <math.h>, and so on.  It's hard to
>be sure without trying to grok the standard right now, but the (occasionally
>inaccurate) "ANSI C: A Lexical Guide" seems to suggest that pow is not a
>reserved word in the way if or for is, unless #include <math.h> is present.
>And, okay I pulled out the standard, and it seems to agree with this; pow
>is reserved only if you #include <math.h>.

If you don't #include <math.h>, then "pow" is not a "reserved word";
but I think that it *is* reserved as an external identifier.
Thus something like
	static double pow(double x,double y) { ... }
should be fine, but to omit the "static" as in
	double pow(double x,double y) { ... }
could cause problems.
[Maybe someone with copy of the standard in front of them can confirm this.]

Note that it makes sense to prevent users from redefining standard library
functions, because doing so could have all sorts of undesireable side-effects.
For example, suppose you redefine pow as
	extern double exp(double), log(double);
	double pow(double x, double y) {
		return exp(y * log(x));
	}
So far, so good. But what if exp happened to be implemented in the
standard library as
	double exp(double x) {
		return pow(2.7182818284, x);
	}
? Now pow() will call exp() which will call pow() which will call exp()...

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: jhauser@redwood.CS.Berkeley.EDU (John Hauser)
Newsgroups: comp.lang.fortran
Subject: Re: Ignoring Least Significant Bit in a Real Compare
Date: 26 Aug 1992 00:06:00 GMT
Organization: University of California at Berkeley
Distribution: usa
NNTP-Posting-Host: redwood.cs.berkeley.edu

In article <3634@execu.execu.com> mike@execu.execu.com (Mike McCants) writes:
 >In article <1992Aug24.185047.27463@news.eng.convex.com> joelw@convex.com (Joel Williamson) writes:
 >>>I am working on a 60-bit CDC machine in Fortran-4.
 >>>      REQ = .FALSE.
 >>>      IF (ABS(X1-X2) .LT. EPS) REQ = .TRUE.
 >
 >>In article <1992Aug21.203055.29668@aero.org> wae@aero.org (William A. Emanuelsen) writes:
 >>try:
 >>	J = I1 .OR. I2
 >                ^^
 >Inclusive or?!
 >Exclusive or [.XOR. or XOR(I1,I2)?] is correct.
 >
 >>	REQ = (J.EQ.1) .OR. (J.EQ.0)

Neither is correct.  (Hint:  3 XOR 4 = 7.)

----------------------------------------------------------------------------
Boycott redwood.  Boycott Louisiana-Pacific.  Keep the forests.  YYYYYYYYYYY
John Hauser---jhauser@cs.berkeley.edu  YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
Newsgroups: comp.lang.fortran
From: rchrd@netcom.com (Richard Friedman)
Subject: Re: Looking for tools to explore FORTRAN77 programs
Date: Sun, 30 Aug 92 19:13:40 GMT
Organization: Applied Parallel Rsrch (Berkeley)

stngiam@athena.mit.edu (Shih-Tung Ngiam) writes:

>>>I'm looking for  program tools  which are  capable of finding out the
>>>calling structure and the use of common  variables within a big, mul-
>>>tiple file  FORTRAN77 program.  
>>
>>We use the product 'FORTRAN-lint' from Information Processing Techniques, and
>>are very happy with it.  It runs on several different platforms.  The number
>>for IPT is (415) 494-7500.

>   I called IPT up.  Unfortunately, $3900 for a single-user license is
>somewhat beyond our budget.  Are there any more economical alternatives?

You might want to investigate FORGE 90. Single user workstation licenses
start at $1850.  Runs on most UNIX workstations with some form of X windows.
FORGE 90 provides a complete interprocedural analysis of industrial
strength Fortran 77 programs.  Send me email for more info. If I say
more about it, the holy self-righteous will flame all over me for
advertising our products in the light of day.
-- 
/\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=/\
\/Richard Friedman (510)528-7055  |  rchrd@netcom.com    
/\Applied Parallel Rsch (Berkeley)|                          /\
\/=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\/

Newsgroups: comp.lang.fortran
From: john@spectre.unm.edu (John Prentice)
Subject: Re: Fortran 90 Advocacy
Date: Tue, 25 Aug 92 23:22:42 GMT
Organization: Dept. of Math & Stat, University of New Mexico, Albuquerque
Keywords: GNU, NAG

In article <17e86cINNma7@darkstar.UCSC.EDU> sla@fast.ucsc.edu (Steve Allen) writes:
>How can Fortran 90 be advocated best?  How can it get enough momentum to
>justify its introduction into High School computer classrooms?

For the kinds of computing most kids do in high school, actually C or C++
are probably better choices.  I am thinking of graphics and other 
non-scientific coding.  So I don't know that the fact that F90 compilers
are not as cheap as say Turbo C is such a damaging thing.  To be sure,
I would love to see Turbo Fortran 90, but I am not holding my breath.
As for kids growing up brainwashed about C or C++, I am not all that
worried.  I am just happy that they are learning about computers and
will trust age and experience to teach them that no one languague is
perfect for all applications.  The truth is, they will eventually need
to be fluent in several languages if they are going to compete in the
modern world of computing (be it scientific or otherwise).

As for the problem of convincing organizations to buy F90 compilers, you
can lead a horse to water, but you can't make him drink.  Those 
organizations that are serious about scientific computing will buy
F90 compilers, as well as C++ compilers and other modern language
compilers.  Those organizations that aren't serious risk becoming 
the has beens of scientific computing.  

John
-- 
John K. Prentice                      
Quetzal Computational Associates    
3200 Carlisle N.E., Albuquerque, NM   87110-1664; 505-889-4543
john@spectre.unm.edu -or- jkprent@cs.sandia.gov -or- john@aquarius.unm.edu
Newsgroups: comp.lang.fortran
Subject: Re: Scientists as Programmers (was Re: Smal
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Mon, 31 Aug 1992 23:31:48 GMT
 <1992Aug31.163405.2169@newshost.lanl.gov> <1992Aug31.164354.3518@newshost.lanl.gov>
Organization: University of Auckland, New Zealand.

jlg@cochiti.lanl.gov (Jim Giles) writes:

[about subroutine calls]

>The *real* cost is in
>register scheduling (including canonical interface protocols) around
>the call, as well as a break in optimization basic-blocks (and many `live'
>values must be assumed `killed' by the call).  Herman Rubin was right
>to begin with, procedure calls are, and will remain for a long time, 
>among the most expensive of operations.  Calls would be expensive even if
>the specific branch instructions used to implement and return from them
>were *free*.

Depends on the architecture you are using. On a MIPS, for example, the
ucode optimizer does global register optimization across function calls,
so a subroutine call is relatively cheap.

On more conventional systems, try and avoid using global variables in
loops with subroutine calls. This should keep the optimizer happy (and
your code clearer, too).
-- 
Thomas Koenig, ecmtwhk@ccu1.aukuni.ac.nz, ib09@rz.uni-karlsruhe.de
The joy of engineering is to find a straight line on a double logarithmic
diagram.
From: djm@hpfcso.FC.HP.COM (Dan Magenheimer)
Date: Tue, 25 Aug 1992 15:53:51 GMT
Subject: Re: CALLING UNIX (PORTABLY) FROM FORTRAN
Organization: Hewlett-Packard, Fort Collins, CO, USA
From: gjlai@csie.nctu.edu.tw (Guan-Joe)
Subject: How to convert FORTRAN to C?
Organization: Computer Science & Information Engin., Chiao-Tung U, Taiwan, ROC
X-Newsreader: Tin 1.1 PL5
Date: Mon, 31 Aug 1992 16:59:32 GMT

Hi, 
	Does anybody know how to get the converter for FORTRAN to C, under UNIX system? Thanks very much.

	Best Regards, G.J. Lai,  e-mail: gjlai@csie.nctu.edu.tw
From: macq@miguel.llnl.gov (Don MacQueen)
Newsgroups: comp.lang.fortran
Subject: f77 parse error (Sun 4)
Date: 4 Sep 92 19:53:27 GMT
Organization: Lawrence Livermore National Laboratory

I have a fortran subroutine that I got from somebody.
It is from a complete code that was up and running
under VMS.

When I try to compile with f77 Sun fortran 1.4 on a
Sun sparcstation IPC (Sun OS 4.1.2) I get this error
message:

Bad parse, return code 1

What is this all about? I can't see anything wrong with
the code.

Thanks for any suggestions
-- 
---------------------------------------------------
Don MacQueen                   macq@miguel.llnl.gov
Lawrence Livermore Nat. Lab.
7000 East Ave., L-307          (510) 423-1062
Livermore, CA 94550
---------------------------------------------------
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Small Language Wanted
Organization: Los Alamos National Laboratory
Date: Thu, 27 Aug 1992 17:26:42 GMT

In article <9224014.17999@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
|> [...]
|> >: > And arrays, C has no true array type
|> >: > like Fortran does (One must use pointers to pointers ... to pointers).
|> >: Did you ever try:     int a[12][34];
|> >: And             :     a[x][y] = somewhat;
|> >
|> >Yes, but try to use "a" in a subroutine.
|> 
|> void subroutine(int a[12][34]) {...}
|> 
|> If there are problems, could you please explain them better?

try:

   void subroutine(n, m, a[n][m]) {...}

Like for writing something as trivial as a matrix multiply routine
which can multiply conformable arrays of any size:

   void mat_mult(i, j, k, a[i][k], b[i][j], c[j][k])
   {... /* returns `a' since arrays are passed by reference */ ...}

Actually, this could be done by eliminating a *single* constraint in 
the C standard - that is, the one which requires array sizes in declarations
to be constant-expressions instead of allowing expressions in globals and/or 
preceeding parameters.  I don't have the rationale document in from of me,
so I don't know why they left that constraint in (or if the explained at
all).

-- 
J. Giles
Newsgroups: comp.lang.fortran
From: koski@cc.tut.fi (Koski Aapo)
Subject: Dynamic memory allocation in F77
Organization: Tampere University of Technology, Finland
Date: Thu, 27 Aug 92 08:47:50 GMT



Hi,

We are trying to use a dynamic memory allocator written in C with
FORTRAN main program. The allocator looks like this:

void C_ALLOCATE(size,ptr)
int *size;
char **ptr;
{
  *ptr = (char *)malloc((unsigned)(*size));
  if (*ptr==NULL) *size=0;
  else {
    memset(*ptr,'\0',*size);
  }
}


And the program to free the allocated memory:

void C_FREE(ptr)
char **ptr;
{
  free(*ptr);
}


The memory for arrays is allocated in main program and memory
addresses are passed to subroutines with reference %Ref. The
memory is allocated OK with this routine above and we are able
to write into the allocated memory area.

When debugging the memory immediatly after the assignment statement
the memory block contains right value, but after a while something
changes the data. 

It seems to me, that the allocated memory block is not reserved. Is
something able to write on this block after allocation ?

The hardware & software we're using:

	Stardent 3000
	TitanOS 4.1 and it's F77 & C compilers


Any information on this topic is appreciated

	- Aapo Koski
From: cflatter@nrao.edu (Chris Flatters)
Newsgroups: comp.lang.fortran
Subject: Re: Scientists as Programmers (was Re: Smal
Date: 27 Aug 92 21:51:04 GMT
Reply-To: cflatter@nrao.edu
Organization: NRAO


In article 4585@mulga.cs.mu.OZ.AU, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>minch@lotka.stanford.edu (Eric Minch) writes:
>
>>... in my experience FORTRAN-writing scientists  
>>can whip out working algorithms just fine. The problem comes when they  
>>have to deal with data structures more complex than arrays, programs  
>>longer than about a thousand lines, and mainly when turning algorithms  
>>into maintainable production code. I've sometimes wished that  
>>scientists were taught in a language with no I/O statements.
>
>Maybe you should try teaching Haskell to upcoming scientists.
>Haskell is a pure functional programming language (with lazy evaluation)
>that has no statements that cause side-effects. I/O is programmed by
>considering the program as a function from input to output, or more
>generally a program is a function from one operating system state to
>another (roughly speaking).
>
>Personally I think that a clear separation of functions which have side-effects
>from those that don't is a very good thing, but there is still a need for
>those in the former class. ML is probably a better alternative as a
>fuctional language if efficiency is much of a concern.

How about Sisal.  Its I/O facilities are primitive (to say the least)
but it is demonstrably at least as fast as FORTRAN.

	Chris Flatters
	cflatter@nrao.edu
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Does your f77 compiler accepts this?
Date: 26 Aug 92 00:17:10 GMT
Organization: Los Alamos National Laboratory

In article <1992Aug25.213754.7260@ibr.cs.tu-bs.de>, i2041101@rzphy1.rz.tu-bs.de (Paulini) writes:
|> [...]
|> (X,X) is a constant if 'X' is defined in a PARAMETER-declaration. Then
|> 
|> 	WRITE (*,*) (X,X)
|> 
|> is legal, otherwise not.

Not quite.  A complex constructor of the pattern `(a,b)' is legal only
if `a' and `b' are *both* literals.  Yes, the extension of allowing them
to be variables (or at least parameters) is desirable, but the committee 
chose not to do so.  This constraint is still in Fortran 90.

Too bad, I thought the above statement should be legal too.

-- 
J. Giles
From: ddewolfe@dragon.acadiau.ca (Dave DeWolfe)
Newsgroups: comp.lang.fortran
Subject: Fortran Compiler for sale
Keywords: fortran
Date: 27 Aug 92 11:57:44 GMT
Organization: Acadia University

For sale - Lahey F77L 4.1 large model, not the personal one.  Includes
editor, make, graphics libraries, vax extensions, debugger, etc.
$200.00 Canadian.  Deal of the century.



--
Dave DeWolfe                    |  e-mail:
Acadia Center for               |  dave.dewolfe@acadiau.ca 
       Estuarine Research       |  (902) 542-7988  FAX (902) 542-1454
Acadia University               |  "Practice random kindness and senseless
Wolfville, N.S.  B0P 1X0 Canada |  "acts of beauty . ." - Anne Herbert
-- 

--
Dave DeWolfe                    |  e-mail:
Acadia Center for               |  dave.dewolfe@acadiau.ca
From: jhauser@redwood.CS.Berkeley.EDU (John Hauser)
Newsgroups: comp.lang.fortran
Subject: Re: Ignoring Least Significant Bit in a Real Compare
Date: 25 Aug 1992 23:59:54 GMT
Organization: University of California at Berkeley
NNTP-Posting-Host: redwood.cs.berkeley.edu

In article <92234.181300HDK@psuvm.psu.edu> HDK@psuvm.psu.edu (H. D. Knoble) writes:
>Similarly when computing the greatest
>integer less than or equal to an argument X, one would not want for
>example, 1 for FLOOR(X=1.999999999999999).

Speak for yourself.  This ``one'' prefers FLOOR(1.999999999999999) = 1.

----------------------------------------------------------------------------
Boycott redwood.  Boycott Louisiana-Pacific.  Keep the forests.  YYYYYYYYYYY
John Hauser---jhauser@cs.berkeley.edu  YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
Newsgroups: comp.lang.fortran
From: cpr4k@holmes.acc.Virginia.EDU (Christian P. Roberts)
Subject: Re: Wanted: Free Source Codes
Reply-To: cpr4k@holmes.acc.Virginia.EDU (Christian P. Roberts)
Organization: Academic Computing Center - U.Va.
Distribution: usa
Date: Wed, 2 Sep 1992 13:48:09 GMT

In article <1992Sep1.222008.350@leland.Stanford.EDU>,
ppark@leland.Stanford.EDU (Chan Su Park) writes:
|> Hello.  I am looking for source codes for fortran subroutines that
perform
|> various matrix manipulations and that can be obtained free of
charge.
|> I heard that LINPACK (a computer package) used to give away its
codes
|> but I could not find LINPACK here at Stanford.
|> 

Send a message to netlib@ornl.gov with requests:

    send index
    send index from linpack
    send index from lapack
    send index from eispack

etc.  for the information on the packages, and a list of routines
available.  The first line will get you the overall index with
instructions on use of the facility.  Once you know the routines
you want, you can request them in a similar message, for example,

    send only ssvdc from linpack


--

Chris Roberts                     Academic Computing Center
cpr4k@virginia.edu                University of Virginia           
(804) 982-4693                    Charlottesville, Virginia 22903
From: mbk@lyapunov.ucsd.edu (Matt Kennel)
Newsgroups: comp.lang.fortran
Subject: Re: Scientists as Programmers (was Re: Smal
Date: 31 Aug 92 06:32:17 GMT
Organization: Institute For Nonlinear Science, UCSD
NNTP-Posting-Host: lyapunov.ucsd.edu
X-Newsreader: Tin 1.1 PL3

cflatter@nrao.edu (Chris Flatters) writes:
: In article IAy@mentor.cc.purdue.edu, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
: >Also, mathematicians especially use lots of operators.  Despite what the CS
: >gurus say, allowing the introduction of additional functions is not the
: >same thing.  Also, mathematicians and scientists are accustomed to using
: >whatever syntax they like, as long as it does not lead to confusion.  But
: >the CS people insist that only the standard operators are to be allowed to
: >use infix notation, and all others must be prefix, except in reverse Polish
: >systems, in which all must be postfix.  
: 
: Restrictions on the introduction of new operators arise from practical
: considerations.  The introduction of a new infix operator changes the
: syntax of the language significantly.

Yes, that's exactly the point.

: 	Chris Flatters
: 	cflatter@nrao.edu

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".
Newsgroups: comp.lang.fortran
From: russell@sun.soe.clarkson.edu (David Russell)
Subject: F77, array passing question, dimensions.
Organization: Clarkson University
Date: Wed, 26 Aug 1992 03:20:18 GMT

   Given an array dimensioned to lets say 10 in a calling routine,
and given the fact that only the first three values are needed in
the called routine, is there any advantage or disadvantage to
dimensioning the array to only 3 in the called routine.

real x(10)
...
call sub(x)
end
subroutine sub(x)
real x(3)
....
return
end

ie. Is there any savings in time, space, performance,......
--
David M. Russell, Mechanical Eng. Dept.
Clarkson University, Potsdam, NY 13676
(315) 268-9806 
russell@sun.soe.clarkson.edu
Newsgroups: comp.lang.fortran
From: ppark@leland.Stanford.EDU (Chan Su Park)
Subject: Wanted: Free Source Codes
Organization: DSG, Stanford University, CA 94305, USA
Date: Tue, 1 Sep 92 22:20:08 GMT

Hello.  I am looking for source codes for fortran subroutines that perform
various matrix manipulations and that can be obtained free of charge.
I heard that LINPACK (a computer package) used to give away its codes
but I could not find LINPACK here at Stanford.

I would greatly appreciate any suggestions.  Thanks in advance!

Chan Su Park


Newsgroups: comp.lang.fortran,comp.std.c
From: atbowler@thinkage.on.ca (Alan Bowler)
Subject: Re: Small Language Wanted
Organization: /etc/organization
Date: Wed, 2 Sep 1992 00:59:11 GMT

In article <1992Sep1.130600.25488@siia.mv.com> drd@siia.mv.com (David Dick) writes:
>
>I believe the real rationale for reserving these words was so that
>certain computer hardware vendors could "inline" the functions and
>boost their performance.  The fact that programmers who know what
>they're doing could no longer replace pieces of the libraries for
>debugging or *performance* reasons, was apparently of no consequence.
>
>IMHO, the "safety" provided by this reservation is far outweighed by
>the crippling of standard programming practice.
>

I don't see any evidence that "programmer's who know what they are
doing" can't still do replacements for debugging an performance
reasons.  If they know what they are doing, then they know how the
implementation they are working with performs, from this they can
figure out how to do the replacements.  If they don't know how to do a
replacement they they clearly don't know enough to be decsribed as
"knowing what they are doing".