Re: [eigen] a couple of RFCs |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] a couple of RFCs
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Wed, 12 Aug 2009 23:50:15 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=n+rUrg8EsszAtLeSQixTfjHJLeNkidhNeJf3oo4xc/Q=; b=Py9OkLliWSQMPAjWFnZRniXWlVJUt+J7w0DQWg+abFZxiwLFuaPpIPyyyV6pVt+6tg h+IhlicqFtPc7s4ZulYjUguCf3jPbwwcSuxfCRyrs0gK9L6ROa9qOofRdJzp+N8Rrex3 tHPoSvbFhpZ4YRHhh/GQP9xJwnnI7W0DFw55s=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=EnumV0uiKCapPgGQHaigNj2eUbOcOQy9XRkbS5RP0wY3k/fiYK5LN+LWC+Of7Chk55 39NiDDAbODlCKNYfB6Tcu/sNgi7tFjcRg/7Nd6Tw3WIRDQtX6JexEamKbgqqAeKJ2dJm sW6ZOqXSo4pCpeH5gTVE5cXHR6M14K18v657g=
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