| 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: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Thu, 13 Aug 2009 09:40:35 -0400
- 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=Z+o6PbfaAVsoOu3QEIPNpYHGnHN+f/BH6zZvDhMIrYU=; b=Tv9rAzOFsd49xw3WXqrJ+d7/gTr8QoaKOTUS9pmorjVOetr+EQ5l5/JE4WTIsEi8XJ k7trHaQMPFQj0vqB1t1xnSCJoZEyaCMMGAoBA3uZ7R6oSJhFfSXDIUqs/qozf/phGz6h DyGJSAKXqQyJyv+dHnI4WVPctPMvz790Fa8e0=
- 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=OP/XFzGjR6jVy0FrQmO8gwgF+NDSLsBMOHsXFR4psCRCvKDo1/Q4gzT4wXfZbX0gZO wQeJsd+9CYxmKmvd/rPVgMTNI8LPgz+Go4aARslPWdvWB3jM+O3UyuuVEKDn5PwJ0mV0 /7L2wZdAX+Uc1XYU1HC7o6Tt8bNGgAzr1wFCQ=
ok, i have done the changes in IO.h, but for machine_epsilon I have a
big problem.
the problem is that at least with gcc-4.4, std::numeric_traits is
broken for std::complex. Specifically:
std::numeric_limits<std::complex<float> >::epsilon()
returns the zero complex number (0,0)
There's a twofold problem, first it should be 1e-7 instead of 0,
second in order to be usable directly this should be a real number.
The only solution i can see is to go for the other solution, keep
machine_epsilon and make it a wrapper around numeric_limits whenever
possible.
ideas?
Benoit
2009/8/12 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> 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
>
>
>