Re: [eigen] a couple of RFCs

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

thanks for the fixes in IOFormat.

about numeric_limits, I think we should use:

std::numeric_limits<NumTraits<Scalar>::Real>::epsilon()

this way the user only have to specialize NumTraits for his/her own
scalar type...

gael.

On Thu, Aug 13, 2009 at 4:30 PM, Benoit Jacob<jacob.benoit.1@xxxxxxxxx> wrote:
> 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
>>>
>>>
>>>
>>
>
>
>



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