mat: consider reconciling option passing in factorise methods

[kortschak]

At the moment there are three factorisation methods that take options, the methods on Eigen, EigenSym, GSVD and SVD. These take different approaches to specifying options for factorisation.

I'm not too sure whether these can be reconciled, or whether doing so would be a net benefit, but it is worth considering.

@btracey @vladimir-ch Views?

[vladimir-ch]

Using ORed bitfields for specifying various options feels quite low level and out-of-place in a matrix package but it 1) works, 2) does not look terrible, and most importantly 3) unlike just true/false the individual bits have names that appear at the call site. So I might prefer the SVD approach over Eigen.

[btracey]

I agree with @vladimir-ch that ORed bit-fields are out of place. It's not clear to me that reconciling the Factorize methods is a goal, but if it is I think the way to do it is to use the approach we took in samplemv. There, we moved the options into the struct type, and rectified the signatures. So, it would be

type SVD struct {
    UKind SVDKind
    VKind SVDKind 
   // contains filtered or unexported fields
}

func (svd *SVD) Factorize(a Matrix) (ok bool){...}

and be used as

svd := &mat.SVD{UKind: svd.Thin, VKind: svd.None}.Factorize(a)

In samplemv this is clearly a good idea because we wanted the types to all satisfy the same interface. It's not clear that is a useful feature here. I think if we do do this then we should make them satisfy the same interfaces though, in case that turns out to be useful. In particular, Cholesky should be FactorizeSym rather than just Factorize. One upside to this is that we could make the zero-values take the default (UKind and VKind default to Thin, vectors in EigenSym is true, etc.). This way a user who doesn't want to think about anything can use

svd := &mat.SVD{}.Factorize(a)

and it will work as expected.

[kortschak]

There was more to that sentence.

[btracey]

I don't follow

[btracey]

Assuming you meant @vladimir-ch 's sentence, there was also more to my post?

[kortschak]

I was responding to the first sentence, yes.

I don't think that there is a good justification for a common interface, but I do think there is a good reason for a general consistency in the approach taken to passing options. The first would be there to ensure code reusability between the factorising types, which I think is a non-goal since one factorisation is not the same as another factorisation (and the result accessors would be different anyway - so they should be part of the interface too if it existed which means there would not be a common interface). The existence of a consistent user interface (the signature vibe) means that learning one means that the user has the concepts necessary for rapidly learning others (the only difference being the exact semantics of the constants/parameters).