On Wed, Apr 1, 2009 at 4:59 PM, Mike Tegtmeyer <tegtmeye@eecis.udel.edu> wrote:
So my .02 is that vectors and matrices need to be two different things. Having them as a single entity is not a good idea because:
- unnecessarily complicates implementation as there are many operations
make sense on a vector but not on a matrix and vice versa
Well thought out implementation will just branch into two at a given
On Wed, 1 Apr 2009, Kornel Kisielewicz wrote: that point. Just because it can, doesn't necessarily mean that it should. If the implementation branches for 1D matrix and "everything else", then the unification is in name only. There are too many operations are only meaningful for 1D matrices and vice versa. I'm having a hard time justifying to myself why they should fall under a common abstraction. To me, an analogy is std::vector and std::list, even though they have similar operations, then have different usage patterns. I think it makes much more sense that they are top-level entities instead of having a common std::sequence with a template argument that specifies the underlying memory layout and branching the two implementations under the hood.
- vectors and matrices are _really_ disjoint when it comes to common
usage
patterns. (in my world anyway)
In CG it's multiplying vectors and matrices all the time, what do you suggest by disjoint?
I'm not saying that you couldn't, for example, multiply a vector and matrix. I'm speculating that one of the reasons that a matrix interface is more controversial than a vector is because how the intended audience uses them is much more varied. Someone who uses matrices for transforms in graphics is usually (broad brush here) different from folks who care about triangle matrices, what makes a good triangle matrix implementation, and how a useful matrix library to them would have compile-time enforcement of symmetric matrices etc. I guess my 'disjoint' comment: that this disparity (er religious wars??) typically don't come up in 1D vectors.
- Vector operations are much more likely to take advantage of SIMD than matrix operations - no point attempting to unify the un-unifiable
That's where specializations enter.
Again my comment about being in name only.
It's not the first and not the second time I would be writing such classes, the main difference would be compatibility, a higher level of genericness and the need of implementing some more obscure operations that I never bothered with. I still think it's in scope, as long as I focus on what's important, and not week-long tries of reducing the constant of an algorithms complexity.
Sorry, I wasn't suggesting that you weren't up for the task. If you could pull it off, fantastic. I just would caution that if your library gains some interest, it is likely that you will get bogged down by the same stylistic, "I could do better", and "this isn't elegant for _my_ usage pattern" clashes that have plagued every other attempt to have a unified matrix library.
The across compilers thing here is the major problem, however that is to be addressed with the performance suite. Also, the goal for this SoC is not to write *the optimal* implementation. It's to write an implementation that will be optimal enough to be optimized without full rewriting.
Absolutely. I just have run into the same issues. In general, we really have to justify any abstraction penalty to the community you are attempting to target. And that abstraction penalty can very much be compile-time and learning curve. I'll argue most of this community knows how to write explicit SIMD instructions and need convincing to use a complex abstraction and having faith that it will 'do the right thing' and doing it fast enough as hand rolled code when speed it paramount. In short, because of what this is, and who the target audience is-simple and concise is probably better then clever and complicated. Again, just my .02, Mike