Julia: Use a name other than `full` for returning original array from a factorization
ref discussion in #12137. Calling this operation full and returning anything other than a dense array from full is fishy to me. I think it's different enough to warrant a separate name, though I'm not sure what that name should be. Maybe this is an uncommon enough operation that we just force the user to know what type it came from and use convert. Or we come up with something new, ifactorize maybe? Suggestions welcome.
tkelman
All 17 comments
prod?
andreasnoack
on 15 Jul 2015
Another possibility is to bring back dense() for returning dense matrices and allow full() to return something else.
jiahao
on 15 Jul 2015
factorproduct
ViralBShah
on 15 Jul 2015
@ViralBShah I don't think factor should be in the method name when Factor is part of the name of the type for which the method is defined.
andreasnoack
on 15 Jul 2015
collapse? condense?
Sacha0
on 16 Jun 2016
In the number theory package "pari", this function is named factorback (but it's not in the linear algebra context).
rfourquet
on 16 Jun 2016
Matrix/Array
StefanKarpinski
on 16 Jun 2016
@StefanKarpinski I think we are looking for something generic and it would be weird if Matrix(CHOLMOD.Factor) -> SparseMatrixCSC.
andreasnoack
on 16 Jun 2016
That's a fair point. AbstractMatrix?
StefanKarpinski
on 16 Jun 2016
Yes. I think that could work.
andreasnoack
on 16 Jun 2016
Are factorization types already subtypes of AbstractMatrix though?
tkelman
on 16 Jun 2016
No and it even has a name https://github.com/JuliaLang/julia/issues/1412. It wouldn't work if that was the case.
andreasnoack
on 16 Jun 2016
Ah my bad. In that case I guess it's alright - calling a constructor of an abstract type always seems a little odd to me but it should be mostly unambiguous here.
tkelman
on 16 Jun 2016
With #17066 merged, close?
Sacha0
on 21 Jul 2016
I think #17082 will close this with the deprecation. Right now things have been reimplemented in terms of convert, but using full for this operation isn't deprecated yet, correct?
tkelman
on 14 Sep 2016
Correct. With #17684 and #17900 in, #17660 should now be viable (will confirm there). #17660 should enable reinstatement of #17079, which should in turn enable #17082 and close this issue. Best!
Sacha0
on 14 Sep 2016
Deferring till after 0.6 (the sparse map[!]/broadcast[!] work is higher priority). Best!
Sacha0
on 15 Dec 2016
Related issues
sbromberger
·
3Comments
felixrehren
·
3Comments
StefanKarpinski
·
3Comments
omus
·
3Comments
musm
·
3Comments
Most helpful comment
Deferring till after 0.6 (the sparse
map[!]/broadcast[!]work is higher priority). Best!