Re: GSL in octave

[Susi Lehtola]

On 07/20/2016 01:00 PM, Julien Bect wrote:
> A now few more questions and remarks...
>
> 1) When I install the package I have this warning:
>
> warning: doc_cache_create: unusable help text found in file
> 'legendre_sphPlm_array'

Yes, I don't really understand where this comes from. I think my most 
recent addition of most of the _array functions also resulted in some 
"unusable help text". Help is appreciated.

> 2) There is a test script name test_ellint.m, I don't what it is
> supposed to do, but it doesn't work any more:
>
> > > test_ellint
> file_name = test_sf.c
> source_id = -1
> source_msg = Aucun fichier ou dossier de ce type
> error: feof: invalid stream number = -1
> error: called from
>     READ_TEST_SF_ellint at line 72 column 3
>     test_ellint at line 134 column 1
>
> You removed test_sf.c in a previous changeset, so I assume this file
> should be removed too?

Yes, I thought I had removed it, but obviously didn't.

> 3) In the changeset "It's better to use row vectors instead" (really...
> can't you try to write more explicit commit messages ?) you modify all
> templates in such a way that all functions now return row vectors.  This
> is a little unexpected (and not documented).  For instance,
>
> debye_1 (rand (3, 3))
> ans =
>
>    0.91844   0.84803   0.93841   0.88165   0.99141   0.79339 0.85979
> 0.84939   0.94766
>
> whereas I would have expected a 3 x 3 output.

Well, obviously that will have to be documented, or changed. The reason 
why I made this change and the assumption that size doesn't matter is 
that otherwise you'll get into huge problems when you have more than one 
argument. If you give this function a row and a column vector as 
arguments, then you should get out a matrix. However, if the two 
arguments are matrices, then the output should be a rank-4 tensor, which 
becomes very quickly challenging.

And the biggest functions in octave-gsl have four arguments, which means 
the result with four matrix arguments will be a rank-8 tensor, which 
wouldn't fit into memory.

> 4) Just an idea: for functions with several arguments, it would be
> really nice (but I don't how hard) to implement broadcasting:
>
> conicalP_0 ([1 4 3]', [2 3])  # should return a 3 x 2 matrix as a result

See answer above.

> 5) In the changeset "Autogenerate PKG_ADD...",  you generate PKG_ADD
> from bootstrap, which is good since it eliminates redundancies.
>
> But shouldn't you then remove PKG_ADD from the repo and add a clean rule
> for PKG_ADD in the Makefile?

Probably, and also drop the missing functions from the autogenerated 
list upon build.

> 6) PKG_ADD should perhaps be generated by configure itself, as suggested
> by Sebastian, in which case it would make more sense to put it in src, I
> think.

Sure.

--
Susi Lehtola
Fedora Project Contributor
address@hidden