|Re: [eigen] Initial implementation of tensor support|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
[cc'd list again]
> OTOH, for the internal:: stuff, having internal::cxx11:: is probably a
> good idea; I currently use internal::tensor::, but I use that also for
> not directly tensor related stuff, so in that case, a namespace would
> probably be a good idea.
> the current trend is to only have a single internal:: namespace and if
> an internal class or function is related to a given Xxx public feature,
> then we put xxx in the internal function/class name.
I'll do that then.
> 2) I'm unsure about what API design for the more advanced features
> should be used. For this reason, I'd like to have some kind of
> brainstorming session (perhaps on IRC?) with interested parties and then
> write an API design document of what kind of API is wanted in the long
> run. Once that's fixed (probably after posting a first draft to the
> mailing list first), there'd be a goal that I can write code towards
> (and perhaps other people would be interested in contributing).
> Regarding API decisions, it seems that only concerns the following
> planed features: "sub-tensors/slices", partial reductions, products for
> which the equivalent API in Core is really restricted to tensors of rank
> 1 and 2.
> For sub-tensors, a new API is already planed to support more complex
> indexing as in MatLab and it should also work for tensors:
Ah cool, I didn't know that. I'll take a closer look. Regardless, a
brainstorming session would probably be a good idea to create something
that's also consistent.