this is not a new bug / odd behavior, but perhaps it's not on the radar
anymore, because it might be a Windows-only thing. It still happens
"often" (not always), that when you search for a word in the script
editor, the window content is moved such that the next match is just in
the next line below the bottom of the window, so not visible without
This is with recent snapshots and releases, and I think both on Windows
7 and 10.
Maybe tricky to fix, and of course not release-critical.
one of these questions that could have been asked years ago:
The 'hausman' command does a very specific thing, namely test a _pooled_
OLS specification in panel data. In contrast, the better-known Hausman
test of RE vs. FE, and also that of OLS vs. IV/TSLS is automatically
done if applicable.
Why then isn't the Hausman test after pooled OLS done automatically as
well? And related: Why are there no $test and $pvalue accessors after
the 'hausman' command? (At least it's not in the doc.)
My preference would be to deprecate the 'hausman' command, do the test
of the pooled specification automatically, and extend the $hausman
accessor to that case.
AFAICS the text search in the built-in script editor is case
insensitive, while hansl is. Could we get a tick box in the search
window switching between one and the other? Or is it more complicated to
change the underlying search engine (from gtk, I suppose)?
the date of modification in the folder browser from gretl is always unknown (see below).
I have this problem every since I remember... but if that could be solved somehow, that would be nice (windows 7, 64bit).
I've just noticed in some oldish code that gretl accepts the ln()
function which isn't documented (nor syntax colored).
? eval ln(2)
? eval log(2)
Is this a fully valid alias or actually a deprecated function? (In which
case a deprecation warning might be useful.)
I have a daily time series (weekdays) that has some missing data in dates of holidays. When I insert the CSV file a window prompt asks me if it is a time series and then to select if it is daily. I select daily with 5 days per week and give the starting date but then gretl creates its own date index assuming all the weekdays are available and hence there is a mismatch of the time index and the time series. Why gretl totally ignores the date series provided in the csv file and it just thinks it is one more time series variable? I would like to be able to create time series graphs using the correct time/date and not the one gretl assumes. Can I do this?
This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute, alter or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmissions cannot be guaranteed to be secure or without error as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message which arise during or as a result of e-mail transmission. If verification is required, please request a hard-copy version. This message is provided for information purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments in any jurisdiction. Securities are offered in the U.S. through PIMCO Investments LLC, distributor and a company of PIMCO LLC.
The individual providing the information herein is an employee of Pacific Investment Management Company LLC ("PIMCO"), an SEC-registered investment adviser. To the extent such individual advises you regarding a PIMCO investment strategy, he or she does so as an associated person of PIMCO. To the extent that any information is provided to you related to a PIMCO-sponsored investment fund ("PIMCO Fund"), it is being provided to you in the individual's capacity as a registered representative of PIMCO Investments LLC ("PI"), an SEC-registered broker-dealer. PI is not registered, and does not intend to register, as a municipal advisor and therefore does not provide advice with respect to the investment of the proceeds of municipal securities or municipal escrow investments. In addition, unless otherwise agreed by PIMCO, this communication and any related attachments are being provided on the express basis that they will not cause PIMCO LLC, or its affiliates, to become an investment advice fiduciary under ERISA or the Internal Revenue Code.
[moving this to devel now]
Am 24.10.2017 um 15:13 schrieb Artur Tarassow:
> Am 24.10.2017 um 14:36 schrieb Sven Schreiber:
>> Because each call to randgen1() should be giving you a new random
>> number, if you know what I mean. In the original code (now in
>> SBslow()) this looks different.
> Good point, Sven. I was also thinking about the purpose for the 2nd
> draw. It's actually taken from K. Sheppard's code.
Please show us. From a quick look at what he has online it didn't seem
to me that way.
> Are there any theoretical points on this? Of course drawing another time
> costs computational time...
Well it's quite a different thing. And yes, a side effect is more
> Yes, we have to call SB() each time. I guess that incorporating the
> MC-part (calling SB many times) into the function environment could
> speed up things due to reduced transfer costs (copy/return).
As I said, by using the 'const' declaration most of the copy should be
gone I'd hope.
> its current form, SB() is very flexible and not limited to some specific
> purpose (some specific time-series model or so).
Well, you could add an optional argument 'numdraws' or something. If
numdraws==1 (the default) everything stays as it is now. Otherwise you
return a matrix with the number of columns equal to numdraws. This might
save you some function call overhead.
> Still, the MATLAB example shares the same architecture and is so much
Yes, it is an interesting comparison in any case. Maybe Matlab is doing
some just-in-time compilation, don't know.