Re: [eigen] a couple of RFCs

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


On Wed, Aug 12, 2009 at 11:34 PM, Benoit Jacob<jacob.benoit.1@xxxxxxxxx> wrote:
> Hi,
>
> 1) we currently have a template machine_epsilon<Scalar>() that is
> redundant with std::numeric_limits at least for standard numeric
> types.
> Should we:
> a) keep our own machine_epsilon<Scalar>(), and make its
> specializations for standard types be wrappers around
> std::numeric_limits?
> or
> b) remove machine_epsilon<Scalar>() and instead use
> std::numeric_limits directly? This would require the user to add
> custom specializations of
> std::numeric_limits if he wants to support custom numeric types. That
> seems OK, right? Also note that in StableNorm.h we're already using
> std::numeric_limits.

I'd remove our custom machine_epsilon<Scalar>(), and instead use
std::numeric_limits.

> 2) in IO.h, by default we output matrices with a "default format" that
> uses 4 digits precision. This has repeatedly annoyed people, as they
> would expect
> cout.precision(n);
> cout << matrix;
> to work. I suggest that the default value for "precision" be -1, and
> that this special value means "use the current precision of the
> stream".
> Worse: we apply the precision to the stream and don't modify it back
> to the original value, so outputting a matrix to a stream has the very
> unexpected effect of altering its precision. OK to change that so we
> save and restore the stream precision?

ok to have a default precision to -1 and ok to save and restore when
precision!=-1

> Benoit
>
>
>



-- 
Gaël Guennebaud
Iparla - INRIA Bordeaux
(+33)5 40 00 37 95



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/