Re: [eigen] Initial implementation of tensor support

[ Thread Index | Date Index | More 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.


Mail converted by MHonArc 2.6.19+