Statalist The Stata Listserver

[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: RE: st: mata: how function can return several results

From (William Gould, Stata)
Subject   Re: RE: st: mata: how function can return several results
Date   Wed, 18 Oct 2006 10:26:07 -0500

Nick Cox <> caught me in a slip of the tongue 
(well, fingers) when, discussing a Mata program, I wrote -polymorphic-
rather than -transmoprhic-, e.g., 

        function whatever(....)
                 polymorphic matrix    x


rather than, 

        function whatever(....)
                 transmorphic matrix   x


Nick wrote, 

> Bill's forgotten his own term, which is "transmorphic". 
> The jury's still out on the misbegotten Latin-Greek 
> hybrid "transmorphic". Oh well, "television" stuck. 

Here's the history behind that slip and Nick's comment.

During the development of Mata, what is now called a -transmorphic matrix- 
was called a -polymorphic matrix-.

An argument was made that someday we might want matrices in which every
element could be of a different type.  Right now, Mata requires the types be
the same:  a matrix is a -real matrix-, or a -complex matrix-, or a -string
matrix-, etc., meaning each and every element is real, complex, or string.

The argument for a single matrix containing different types was not made by 
me and, as a matter of fact, I argued against it.  We need not get into that
discussion right now.  Nevertheless, I gave in as far as as admitting the
POSSIBILITY we might want to add matrices containing different types

Those on the winning side were not gracious.  They then argued that
-polymorphic- was just the right term to describe the matrices they 
were arguing for.  I needed to find a new word for what I was calling
-polymorphic-, they said.

At this point, the loss of the word was more irritating to me than 
the loss of the argument, and I briefly reconsidered reopening the 
argument just get the word back.  Being a mature person, however,
and unlike those arguing against me, I did not.

One of the ring-leaders of the opposite side of the debate suggested
-transmorphic-.  I found that word acceptable, but I decided to ask Nick 
what he thought.  "Oh, no, no, no," Nick said.  "Oh, dear."

"What's the problem?" I asked.

Nick went on to explain to me that trans- is a LATIN prefix and -morphic
is a GREEK suffix -- do I have that right, Nick, or is it the other way
around? -- and evidently he found something disturbing about that.
He mumbled something about television.  

"There's something on television?"

"No, no, no.  The WORD television."

"Oh, you mean like hexadecimal!"

"Yes, exactly!"

"I like hexadecimal numbers."

I thanked Nick for clarifying the situation for me, although he went on 
endlessly in favor of -metaphorphic-.  Well, Nick is a geographer.  Meta-
sounds so damn slow.

The irony is that I ultimately won the argument against matrices with
different types.  The argument for such matrices was based on the statement
about how convenient it would be to be able to create a vector the first
element of which could be a string (such as a title), the second element a
real scalar (such as the number of observations), the third element a matrix
(such as a VCE), and so on.  Much better than referring to results[1],
results[2], and results[3], however, is results.title, results.obs, and
results.vce.  Structures were what they wanted, not matrices with elements of
different types.  And notice that I still get my way about every element of a
matrix having the same type.  I could have a vector of results[], with
results[1].title and results[2].title, results[1].obs and results[2].obs, and
results[1].vce and results[2].vce.

I had a reason for wanting matrices of elements of the same type.  Matrices
with elements of different types would slow Mata down, bring Mata to its
knees, if you will excuse the mixed metaphore, which you should as long as you
are excusing the mix of languages.

-- Bill
*   For searches and help try:

© Copyright 1996–2021 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index