|Re: [eigen] Undesired formatting behaviour|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
Gael Guennebaud wrote:
I understand that and it certainly makes sense for the string variables,
but another difference between precision and width is that as far as I
know, changes made to precision are remembered until changed, while
width is just valid for the first output operation and then defaults
back to 0 (I never understood why). So you can change precision once on
the ostream and use it many times too.
What I consider an inconsistency is that you use the IOFormat class at all
to define the precision, since you still are dependent on the floatfield
flag of the stream to use the precision you define in IOFormat. I mean, you
still need to write cout << fixed << matrix; before the precision gets used
with floats for example. Either you define all the formatting behaviour in
the IOFormat class and inhibit the effects of the ostream flags or you read
all ostream flags and act accordingly (where I'd prefer the latter). The
AlignCols flag has added value compared to a simple width(x), so to put that
into IOFormat makes sense to me in both cases.
the main goal of the current design was to be able to define a format
object once and use it many times. This is why all options are
encapsulated in IOFormat.
My mistake, I didn't notice the member variables were public, so I can
already do that by addressing them directly. Changing to protected
variables and getters/setters would be more pleasing to encapsulation
purists I guess, but would be too much of a hassle.
Either way, a trivial feature
request is that I'd like setters for the variables in IO Format such that you
can initialise with the default IOFormat() format; and just change the one
variable you want with format.setRowPrefix = "pre"; for example.
no problem to add such setters, a patch would be very much appreciated ;)
A last, completely unrelated thing is that I can find how to take the sum of
a matrix, but not the product of the matrix. It could be that I'm looking
over it, but if not, it's another feature request.
in svn trunk we have the prod() function which does exactly that.