5:54 a.m.
Hi,
I tried to run simple OLS but the results are not matching. The SPSS results are matching
with text book results.
SPSS results:
Coefficients
Model B Std. Error Beta t Sig.
1 (Constant) 1158559.201 360592.720 3.213 .002
Q 2026114.340 61806.945 .907 32.781 .000
PF 1.225 .104 .339 11.814 .000
LF -3065753.131 696327.318 -.136 -4.403 .000
a Dependent Variable: C
GRETL:
Model 2: OLS, using observations 1-90
Dependent variable: C
Omitted due to exact collinearity: LF
coefficient std. error t-ratio p-value
-----------------------------------------------------------------
const 1.58686e+06 154259 10.29 1.05e-016 ***
Q −32683.7 2587.90 −12.63 2.23e-021 ***
PF 2.16835 0.205182 10.57 2.83e-017 ***
Mean dependent var 1122524 S.D. dependent var 1192075
Sum squared resid 3.44e+13 S.E. of regression 628752.4
R-squared 0.728055 Adjusted R-squared 0.721803
F(2, 87) 116.4586 P-value(F) 2.51e-25
Log-likelihood −1327.813 Akaike criterion 2661.626
Schwarz criterion 2669.126 Hannan-Quinn 2664.651
https://www.dropbox.com/scl/fi/ndhl6sauxeeuufzl2wa6x/gujarati_Table16_1_a...
9:25 a.m.
I agree that se's are large but can we have an option to agree with results of other
softwares? stata, r, spss are all producing similar results.
SPSS resutls wth VIF "in quotations" which are < 5:
Coefficientsa
Model Unstandardized Coefficients Standardized Coefficients t Sig. Collinearity
Statistics
B Std. Error Beta Tolerance VIF
1 (Constant) 1158559.201 360592.720 3.213 .002
Q 2026114.340 61806.945 .907 32.781 .000 .819 "1.221"
PF 1.225 .104 .339 11.814 .000 .763 "1.311"
LF -3065753.131 696327.318 -.136 -4.403 .000 .659 "1.517"
a Dependent Variable: C
Stata report:
regress c q pf lf
Source | SS df MS Number of obs = 90
-------------+---------------------------------- F(3, 86) = 503.12
Model | 1.1966e+14 3 3.9885e+13 Prob > F = 0.0000
Residual | 6.8177e+12 86 7.9276e+10 R-squared = 0.9461
-------------+---------------------------------- Adj R-squared = 0.9442
Total | 1.2647e+14 89 1.4210e+12 Root MSE = 2.8e+05
------------------------------------------------------------------------------
c | Coefficient Std. err. t P>|t| [95% conf. interval]
-------------+----------------------------------------------------------------
q | 2026114 61806.94 32.78 0.000 1903246 2148982
pf | 1.225348 .1037217 11.81 0.000 1.019156 1.43154
lf | -3065753 696327.3 -4.40 0.000 -4450006 -1681500
_cons | 1158559 360592.7 3.21 0.002 441724.7 1875394
------------------------------------------------------------------------------
R report:
Model Coefficients - C
Predictor Estimate SE t p
Intercept 1.16E+06 360592.72 3.21 0.002
Q 2.03E+06 61806.945 32.78 <.001
PF 1.23 0.104 11.81 <.001
LF -3.07E+06 696327.318 -4.4 <.001
11:01 a.m.
Am 06.04.2026 um 11:25 schrieb Ramki S:
I agree that se's are large but can we have an option to agree
with results of other softwares? stata, r, spss are all producing similar results.
Thanks for another interesting test case. Here's my summary of the
situation in (lib)gretl as I understand it. The default numerical
approach for ols estimation is the Cholesky decomposition. If the
variables turn out to be too collinear, I believe gretl automatically
falls back to the QR decomposition which is numerically more robust in
that respect. Whether or not exact collinearity is "announced" to the
user and the corresponding variable is dropped automatically depends on
the threshold for the rank-determination code, and that threshold
appears to be defined in lib/src/gretl_matrix.h, let me quote lines
30-33 here:
/* minimum value of diagonal element of R (as in X = QR) that counts
as non-zero for the purpose of determining the rank of X */
#define R_DIAG_MIN 1.0e-8
So it seems to me that this is currently hard-coded as 1e-8. This is a
very reasonable number I think, but apparently the other programs you
tried are more tolerant here. So for comparison with other software one
may wish to adjust it.
I'm not aware that this is currently possible short of editing this
piece of C source and re-compiling gretl yourself, which is not for the
average user.
Two possible exceptions:
- For the matrix-oriented mols() function you can force the SVD instead
of QR decomp with the script command "set svd on". Not sure whether this
also affects the regular ols estimation command.
- gretl also has the multiple-precision mpols() function (also
matrix-oriented) which may have different thresholds.
Thanks again for pointing to the relevant data, so more testing is
possible. (Can't do that right now, though.)
cheers
sven
12:06 p.m.
Please give us the details of the gretl version you're using. I'm not
seeing the problem you describe here.
Model 1: OLS, using observations 1-90
Dependent variable: C
coefficient std. error t-ratio p-value
------------------------------------------------------------
const 1.15856e+06 360593 3.213 0.0018 ***
Q 2.02611e+06 61806.9 32.78 2.25e-50 ***
PF 1.22535 0.103722 11.81 1.07e-19 ***
LF −3.06575e+06 696327 −4.403 3.06e-05 ***
Mean dependent var 1122524 S.D. dependent var 1192075
Sum squared resid 6.82e+12 S.E. of regression 281559.5
R-squared 0.946093 Adjusted R-squared 0.944213
F(3, 86) 503.1176 P-value(F) 2.10e-54
Log-likelihood −1254.988 Akaike criterion 2517.975
Schwarz criterion 2527.974 Hannan-Quinn 2522.007
Allin Cottrell
On Mon, Apr 6, 2026 at 5:25 AM Ramki S <ramakrishnasalagrama(a)gmail.com> wrote:
>
> I agree that se's are large but can we have an option to agree with results of
other softwares? stata, r, spss are all producing similar results.
2:45 p.m.
Thanks, Ramki. But it's not to do with the gretl version, now I see
what's going on. The CSV file you posted was kinda broken, in that
every value was wrapped in double quotes, so that gretl reads the data
as 100 percent string-valued. (Something that's quite clearly flagged
when you open the file).
Either open the CSV file in a text editor and delete the quote-junk,
or use the airline data as supplied with gretl (greene14_1 under the
Greene tab) and you'll get correct results.
Allin
On Mon, Apr 6, 2026 at 9:12 AM Ramki S <ramakrishnasalagrama(a)gmail.com> wrote:
>
> sorry it is gtk 3 not trk 3, I am using windows 11 and installed gretl 64 bit.
4:40 p.m.
Thanks a lot. I am surprised with this little issue. But when other softwares are cleanly
handling the quotes, why gretl is not doing it. I would prefer there should be some option
to ignores the quotes. Now I am getting the correct results.
Followup:
I am finding it difficult to post anything like code or output here due to this forum
format. Is there any option to shift to stackoverflow so that it is really easy to post
code, data, output everything in neat format.
5:56 p.m.
Am 06.04.2026 um 18:40 schrieb Ramki S:
Thanks a lot. I am surprised with this little issue. But when other
softwares are cleanly handling the quotes, why gretl is not doing it. I would prefer there
should be some option to ignores the quotes. Now I am getting the correct results.
Did you change the file on Dropbox in the meantime? I'm not seeing those
quotes when I download the csv file, everything is perfectly numeric and
fine. Anyway, in my subjective opinion gretl is quite good in the
import/export department. Of course, there's always room for
improvement, but last time I had to work with commercial econometrics
software, I was kind of surprised at the lack of supported file formats,
compared to gretl.
Followup:
I am finding it difficult to post anything like code or output here due to this forum
format. Is there any option to shift to stackoverflow so that it is really easy to post
code, data, output everything in neat format.
It's true that in a mailing list the formatting options are limited. It
usually works, though, if you use a fixed-width font for
copied-and-pasted tables and so on.
Quite some time ago there was a discussion about stackoverflow, but the
shift wasn't made, and while I was kind of in favor of it back in the
time, I certainly wouldn't try to move there now that it's dying due to
AI. (There have been lots of web comments about "nobody" asking or
answering questions there anymore.)
Having said that, we also use the issue tracker system on the
sourceforge page, which is more like an actual web forum instead of a
mailing list, and comes with some formatting options. See
https://sourceforge.net/p/gretl/feature-requests/ or
https://sourceforge.net/p/gretl/bugs/. Your case studies are actually
better suited for this mailing list (and so you chose the right outlet),
but if you feel you need better formatting, you can also post over there
instead. We read and follow those trackers as well.
thanks
sven
6:08 p.m.
I also agree with your opinion about stackoverflow. Even though I asked really meaningful
questions, after a few hours, AI is automatically closing the questions giving some weird
reasons.
7:43 p.m.
On Mon, Apr 6, 2026 at 12:40 PM Ramki S <ramakrishnasalagrama(a)gmail.com> wrote:
Thanks a lot. I am surprised with this little issue. But when other softwares are cleanly
handling the quotes, why gretl is not doing it.
I wouldn't describe ignoring quotes in a CSV file as "cleanly
handling" them. By convention they indicate string values.
Followup:
I am finding it difficult to post anything like code or output here due to this forum
format. Is there any option to shift to stackoverflow so that it is really easy to post
code, data, output everything in neat format.
I find that posts to the gretl list are more easily read at
mail-archive: https://mail-archive.com/gretl-users@gretlml.univpm.it/
Allin
11
days inactive
11
days old
12 comments
4 participants
participants (4)
-
Cottrell, Allin -
Marcin Błażejowski -
Ramki S -
Sven Schreiber