Re: [eigen] Undesired formatting behaviour

[ Thread Index | Date Index | More Archives ]

Gael Guennebaud wrote:
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.
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.
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 ;)
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.
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.

Kind regards,
Johan Pauwels

Mail converted by MHonArc 2.6.19+