Hmm, maybe what I wrote was not clear -- I never meant to argue for
splitting into submodules. Using multipe dispatch seems like a much
nicer solution to me, ie something like
factorize(matrix, Cholesky)
which would perform a Cholesky factorization, returning an instance of
the applicable type (depending on whether matrix is sparse, etc). The
general syntax I could imagine is
factorize(matrix, factorization)
where factorization may or may not be an actual concrete type (most
often not), but simply a kind of factorization (SVD, eigen, LU, QR).
The fly in the ointment is that currently Julia cannot dispatch on
values directly (like the EQL specializer in CLOS), only on parametric
types, eg
factorize(matrix, Val{Cholesky})
Maybe it would then make sense to create an abstract type Cholesky,
which can be a supertype to all kinds of Cholesky factorizations. But of
course please keep in mind that I have been using Julia for less than a
couple of months so my perspective on interface design may not be that
valuable.
Best,
Tamas
On Tue, Apr 28 2015, Josh Langsfeld <[email protected]> wrote:
> I don't know why it hasn't been mentioned (it was hinted at by Tamas) but
> it seems to me the clear solution is for most of Base to actually be moved
> into submodules like 'LinAlg'. Then to use those names, people need to call
> 'using LinAlg' or 'using Sparse', etc... Somebody mentioned how 'cholfact'
> might be confusing to generic programmer, but a generic programmer should
> never even see the name unless he or she goes looking for it.
>
> I would be highly skeptical of any attempt to make the standard library a
> single gigantic list of function names that everyone can understand the
> purpose of by glancing at.
>
> On Tuesday, April 28, 2015 at 9:45:39 AM UTC-4, Yuuki Soho wrote:
>>
>> I think one should go over all the names in Base and see if there's some
>> rules that can be applied sanely to come up with better naming scheme.
>>
>> If you introduce factorize(MyType,...) and want to be consistent about
>> this kind of things you might end up changing a lot of the functions in
>> base. E.g.
>>
>> sqrtm -> sqrt(Matrix,...)
>> hist2d -> hist(Dimension{2},...)
>> ...
>>
