 |
 |
Richard Wang wrote: > For example, is there a general guideline for using function and > subroutine. I heard a least in one case, when the return object is an > array, subroutine is more efficient because it doesn't generate an > extra copy of array. Are there any other concerns? This doesn't directly answer your question, but I'd like to point out a general concern before thinking of efficiency (and you probably have thought of all this..). I usually use FUNCTIONSs only for mathematical functions and logical functions depending on its arguments. This is just my preference and not really for efficiency. I would like to think that A FUNCTION computes something from something, a SUBROUTINE does something to something, although I know that at a lower level of abstraction those two mean the same thing to the computer. So, IS_UPPERCASE(CHAR) I code as a function, but TO_UPPERCASE(STRING) is a subroutine to me, even though it has only one result value and could be written as a function. I want all the characters in STRING converted to uppercase, not that I want to compute some value from STRING. The intrinsic function TRANSPOSE is rightly a function, but if I had a 2D array that represents some image and holds pixel values, and need to code a procedure to make its mirror image along a diagonal line, I'll code that as a subroutine (even if I needed to preserve the original array). If I needed a procedure that computes some color average of the same image array, that's a function. If the procedure is to compute a "fingerprint" vector from the image array, that's a function, although it may return an array. If the procedure is to do a "fingerprint analysis" on the image (whatever that is), that's a subroutine, although it may do exactly the same thing as the fingerprint function. -- Yasuki Arasaki [log in to unmask]