Am 07.04.20 um 18:41 schrieb Sven Schreiber:

> 1) drawnormwis(): This function does a random draw from > Normal-inverse-Wishart distributions for Bayesian stuff and currently > exists hidden in the SVAR addon (see > https://sourceforge.net/p/gretl/git/ci/master/tree/addons/SVAR/SVAR_compa...)

just one suggestion. The function name may be modified to make more clear what it's for. We already have the built-in function iwishart(). So why not name the proposed function drawnormiwishart()? Personally I would even name it drawnormal_iwishart() for readability purposes.

> 2) multiplot(): I'm attaching an unfinished but working prototype. Many > many things could be added here, this is a bit like Pandora's box (or > the work of Sisyphus?). But maybe having _something_ is better than > nothing? Feedback please! I could have a look at it during the next 2 days.

Am 07.04.20 um 23:17 schrieb Sven Schreiber: > Am 07.04.2020 um 21:00 schrieb Artur Tarassow: >> Am 07.04.20 um 18:41 schrieb Sven Schreiber: > >>> 1) drawnormwis(): This function does a random draw from >>> Normal-inverse-Wishart distributions for Bayesian stuff and currently >>> exists hidden in the SVAR addon (see >>> https://sourceforge.net/p/gretl/git/ci/master/tree/addons/SVAR/SVAR_compa...) >>> > >> >> just one suggestion. The function name may be modified to make more >> clear what it's for. We already have the built-in function iwishart(). >> So why not name the proposed function drawnormiwishart()? Personally I >> would even name it drawnormal_iwishart() for readability purposes. > > I agree the name is suboptimal, but maybe we should rather try to > describe what it is for: Namely re-drawing for a multi-equation system. > Perhaps something like 'syscoeffdraw'? That would also leave the door > open for other underlying distributions in the future. (Would that be a > likely or sensible generalization?) But then it's unclear that its using some Bayesian approach, I guess.

On Sat, 25 Apr 2020, Sven Schreiber wrote: > Am 09.04.2020 um 07:13 schrieb Artur Tarassow: >> Am 07.04.20 um 23:17 schrieb Sven Schreiber:

>>> I agree the name is suboptimal, but maybe we should rather try to >>> describe what it is for: Namely re-drawing for a multi-equation system. >>> Perhaps something like 'syscoeffdraw'? That would also leave the door >>> open for other underlying distributions in the future. (Would that be a >>> likely or sensible generalization?) >> >> But then it's unclear that its using some Bayesian approach, I guess. > > [sorry for the delay] Also true. > We should settle on some name now. > My next proposal is a shortened version of Artur's: normiwishart() Actually, we could go for a name that emphasises the _purpose_ of the function. How about multieq_draw(); then of course we need to explain thoroughly what it does and how in the docs, but IMO the name is nice and easy to remember.

On Sat, 25 Apr 2020, Sven Schreiber wrote: >> Actually, we could go for a name that emphasises the _purpose_ of the >> function. How about multieq_draw(); then of course we need to explain >> thoroughly what it does and how in the docs, but IMO the name is nice >> and easy to remember. > > Hehe, I think I "incepted" you, see three replies earlier. I don't like > the underscore too much though (but it's not a full veto). syseqdraw? > multieqdraw? MultiEqDraw()?

Am 25.04.2020 um 16:04 schrieb Artur Tarassow: > Am 25.04.20 um 15:42 schrieb Riccardo (Jack) Lucchetti: >> On Sat, 25 Apr 2020, Sven Schreiber wrote: >>> Hehe, I think I "incepted" you, see three replies earlier. I don't >>> like >>> the underscore too much though (but it's not a full veto). syseqdraw? >>> multieqdraw? >> >> MultiEqDraw()? That would be CamelCase - see below. > I am more or less  indifferent wrt to the function name as such. It > should be meaningful and intuitive. > > However, we _should_ to be consistent as possible regarding naming > conventions. Unfortunately we've missed to define some conventions for > the "extra" package which is authored by different people at the > beginning. Currently we have almost all possible naming styles in > "extra". Yeah, almost - we don't have camel case in extra and I think Allin stated that he doesn't like that. And of course Jack's gap_filler is the only underscore around, and it would be easy to introduce an official alias 'gapfiller'. I agree some convention might be good, to an extent. But we already have a loose de-facto standard that you can see when looking at the list of gretl functions: No CamelCase, no underscores, nothing too long, uppercase only when it's an acronym (although it's actually inconsistent then to have kpsscrit, bkfilt, bkw, ghk ...). (Note that personally I like CamelCase, but that's not the point.)

On Sat, Apr 25, 2020 at 11:57 AM Sven Schreiber <svetosch(a)gmx.net&gt; wrote: > Am 25.04.2020 um 16:04 schrieb Artur Tarassow: >> However, we _should_ to be consistent as possible regarding naming >> conventions. Unfortunately we've missed to define some conventions for >> the "extra" package which is authored by different people at the >> beginning. Currently we have almost all possible naming styles in "extra". > Yeah, almost - we don't have camel case in extra and I think Allin > stated that he doesn't like that. And of course Jack's gap_filler is the > only underscore around, and it would be easy to introduce an official > alias 'gapfiller'. > > I agree some convention might be good, to an extent. But we already have > a loose de-facto standard that you can see when looking at the list of > gretl functions: No CamelCase, no underscores, nothing too long, > uppercase only when it's an acronym (although it's actually inconsistent > then to have kpsscrit, bkfilt, bkw, ghk ...). Consistency is good, and maybe trumps other considerations. But I think function packages are/should be allowed latitude relative to built-in functions. There are no underscores in names of built-ins (I think) but they seem fine to me for readability in function packages. I guess one could make the same argument for Camel Case. My main objection would be to names that are (a) too long (though they can be longer than the names of built-ins) or (b) hard to read because they use run-in wording without either underscores or Camel-Casing to clarify.

Am 25.04.2020 um 21:24 schrieb Cottrell, Allin: > On Sat, Apr 25, 2020 at 11:57 AM Sven Schreiber <svetosch(a)gmx.net&gt; wrote: >> >> I agree some convention might be good, to an extent. But we already have >> a loose de-facto standard that you can see when looking at the list of >> gretl functions: No CamelCase, no underscores, nothing too long, >> uppercase only when it's an acronym (although it's actually inconsistent >> then to have kpsscrit, bkfilt, bkw, ghk ...). > > Consistency is good, and maybe trumps other considerations. But I > think function packages are/should be allowed latitude relative to > built-in functions. There are no underscores in names of built-ins (I > think) but they seem fine to me for readability in function packages. Well, the thing with 'extra' is that it is supposed to be a collections of things that might become a built-in at some point. At least that was my understanding.

In that sense the naming convention of builtins should be kept in mind at least for those functions that are performance-critical and therefore might move to core-C-gretl. It would seem to me that MultiEqDraw or what it's called might belong to that category. Others do not.

On Sat, 25 Apr 2020, Sven Schreiber wrote: >> Actually, we could go for a name that emphasises the _purpose_ of the >> function. How about multieq_draw(); then of course we need to explain >> thoroughly what it does and how in the docs, but IMO the name is nice >> and easy to remember. > > Hehe, I think I "incepted" you, see three replies earlier. I don't like > the underscore too much though (but it's not a full veto). syseqdraw? > multieqdraw? MultiEqDraw()?