Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

## [Vxl-maintainers] vnl_numeric_traits

 [Vxl-maintainers] vnl_numeric_traits From: Amitha Perera - 2003-01-21 04:01:18 ```Hi Why is vnl_numeric_traits::real_t a double instead of a float? The comment says "result when multiplied by double", but that's not quite how it is used. It generates a warning is vnl_vector::cos_angle when instantiated with complex because there is an attempt to create a complex from a double, which implies a loss of precision. Changing the real_t to float would also fix things like vnl_matrix.txx:834: // FIXME need correct rounding here // There is e.g. no *standard* operator*=(complex, double), hence the T() cast. this->data[i][j] *= T(scale); Here, scale has type real_t, which means double, and therefore the problem. I think we should have typedef vnl_numeric_traits::real_t float; typedef vnl_numeric_traits::real_t double; typedef vnl_numeric_traits< complex >::real_t complex; typedef vnl_numeric_traits< complex >::real_t complex; The comment could be from //: Name of type which results from multiplying this type with a double to //: Name of type which results from multiplying this type with a float However, I have no experience in using vnl except with doubles, so I don't know what would break from this change. Can someone who knows better comment? Thanks, Amitha. ```

### Thread view

 [Vxl-maintainers] vnl_numeric_traits From: Amitha Perera - 2003-01-21 04:01:18 ```Hi Why is vnl_numeric_traits::real_t a double instead of a float? The comment says "result when multiplied by double", but that's not quite how it is used. It generates a warning is vnl_vector::cos_angle when instantiated with complex because there is an attempt to create a complex from a double, which implies a loss of precision. Changing the real_t to float would also fix things like vnl_matrix.txx:834: // FIXME need correct rounding here // There is e.g. no *standard* operator*=(complex, double), hence the T() cast. this->data[i][j] *= T(scale); Here, scale has type real_t, which means double, and therefore the problem. I think we should have typedef vnl_numeric_traits::real_t float; typedef vnl_numeric_traits::real_t double; typedef vnl_numeric_traits< complex >::real_t complex; typedef vnl_numeric_traits< complex >::real_t complex; The comment could be from //: Name of type which results from multiplying this type with a double to //: Name of type which results from multiplying this type with a float However, I have no experience in using vnl except with doubles, so I don't know what would break from this change. Can someone who knows better comment? Thanks, Amitha. ```
 RE: [Vxl-maintainers] vnl_numeric_traits From: Andrew Fitzgibbon - 2003-01-21 10:17:17 ```> Why is vnl_numeric_traits::real_t a double instead of a float? > The comment says "result when multiplied by double", but that's not > quite how it is used. So, the comment is correct, but the usage is wrong. If we need another sort of real_t, then we should add it. But the existing one has a well-defined meaning, and is used in contexts like T t; traits::real_t product = 1.0 * t; Now, maybe it should be renamed to double_product_t, but it does have a meaning and use at the moment. > It generates a warning is vnl_vector::cos_angle > when instantiated with complex because there is an attempt to > create a complex from a double, which implies a loss of > precision. So that function should be fixed. Where did the double come from? acos? In which case either the float->float acos should be used, or we must narrow to complex > > Changing the real_t to float would also fix things like > vnl_matrix.txx:834: > > // FIXME need correct rounding here > // There is e.g. no *standard* > operator*=(complex, double), hence the T() cast. > this->data[i][j] *= T(scale); > > Here, scale has type real_t, which means double, and therefore the > problem. > > I think we should have > typedef vnl_numeric_traits::real_t float; > typedef vnl_numeric_traits::real_t double; > typedef vnl_numeric_traits< complex >::real_t > complex; > typedef vnl_numeric_traits< complex >::real_t > complex; > > The comment could be from > > //: Name of type which results from multiplying this type > with a double > > to > > //: Name of type which results from multiplying this type > with a float > > > However, I have no experience in using vnl except with doubles, so I > don't know what would break from this change. Can someone who knows > better comment? > > Thanks, > Amitha. > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Vxl-maintainers mailing list > Vxl-maintainers@... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > ```
 RE: [Vxl-maintainers] vnl_numeric_traits From: Peter Vanroose - 2003-01-21 11:22:51 ```> the existing one has a well-defined meaning, and is used in contexts like > > T t; > traits::real_t product = 1.0 * t; Well, let's then change the meaning to traits::real_t product = 1.0f * t; It is less harmful to cast from float to double than from double to float. -- Peter. ```
 RE: [Vxl-maintainers] vnl_numeric_traits From: Andrew Fitzgibbon - 2003-01-21 11:44:34 ```No, what I said was "the existing one has a well-defined meaning". Therefore we should not change it. It is harmful either way. Make a new one if we need a new one. > -----Original Message----- > From: Peter Vanroose [mailto:Peter.Vanroose@...] > Sent: 21 January 2003 11:22 > To: Andrew Fitzgibbon > Cc: 'Amitha Perera'; vxl-maintainers@... > Subject: RE: [Vxl-maintainers] vnl_numeric_traits > > > > the existing one has a well-defined meaning, and is used in > contexts like > > > > T t; > > traits::real_t product = 1.0 * t; > > Well, let's then change the meaning to > > traits::real_t product = 1.0f * t; > > It is less harmful to cast from float to double than from > double to float. > > > > -- Peter. > ```