Re: [eigen] Undesired formatting behaviour

[Johan Pauwels <johan.pauwels@xxxxxxxxxxxxx>]

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.
>   
Great.

Kind regards,
Johan Pauwels