Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: Re: Mata q

From   Kit Baum <>
Subject   st: Re: Mata q
Date   Wed, 13 Apr 2005 07:25:21 -0400

Agree with Nick; surely Mata will have the full precision available to the combination of hardware and OS. Although I have no inside information, I expect what this statement means (coupled with the example displayed on the web site) is that matrix languages (e.g. GAUSS or MATLAB) are generally hideously slow when operating on an element-by-element level as one would in FORTRAN. Those matrix languages are very fast when you use their built-in matrix operations. Version 8 of Stata works the same way -- if you wrote an ado-file to multiply matrices, it would be much slower than saying
mat c = a*b

I believe what Mata's authors are pointing out is that their approach (using compiled-on-the-fly code) is so efficient that even if you directly translate FORTRAN element-by-element code to Mata, it will run like a bandit. This provides a nice intermediate path between using ado-file code to do heavy computation (which can be very slow) and going to the trouble of writing a C plugin. In Stata pre v9, the only way to speed up something like gllamm is to recode some or all of it in C, which makes maintenance and enhancement of the code more difficult. Once such routines can be written in Mata -- a higher-level language than C -- it should be possible to get more speed (and all avaiilable accuracy) without sacrificing readability (or having to figure out how to keep track of those %%^$% pointers!)

Again, just my interpretation of what I think we will see in Mata. I have seen nothing more of it than what is on the website.

Kit Baum, Boston College Economics

On Apr 13, 2005, at 2:33 AM, Renzo wrote:

At the page
it says "Everybody knows that matrix languages evaluate matrix expressions,
such as b=invsym(X'X)*X'y, and Mata is no exception. Because of Mata's
design, however, it is fast enough to work at the element level".

This looks like a disclaimer of some sort about some loss of precision, but
I got quite understand the implications of this.
Can anybody clarify?

How different is it (if any) from the way the same calculation was done in
*   For searches and help try:

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