Re: [eigen] a couple of RFCs

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

ok, it occured to me that the  dummy values returned are probably a
default that needs to be overridden by adding a specialization of
numeric_traits for std::complex. it seems that at least gcc doesn't
provide such a specialization.

so the other solution is to add our own partial specialization for
std::complex<T>. do you prefer this approach?

Benoit

2009/8/13 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 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
>>
>>
>>
>