From: Brad K. <bra...@ki...> - 2003-10-22 19:18:18
|
Hello, I've been updating vnl to include ITK's changes to support the Borland C++ compiler. One change I had to make was to vnl_numeric_limits to fix the infinity and quiet_NaN values provided when building with that compiler. Meanwhile, I noticed a few problems: 1.) Several values in vnl_numeric_limits specializations seem to be wrong. For example, unsigned short has a min_exponent of -31 and a max_exponent of 31. The return types from min/max methods are also inconsistent with the numeric type. 2.) There no specializations for char types. 3.) Some of the constants are static methods and some are static constants. I do not see any reason for the inconsistency. 4.) Min/max values for long types are hardcoded to assume 32-bits. It should be possible to construct almost all the values with try-run programs during the configuration process, but that may be overkill for now. Unfortunately, I cannot commit the time to fix these problems, but I thought I'd bring them up in case someone else is interested. Another problem is that test_math and test_numeric_limits access the NaN values. There is nothing wrong with this, but Borland throws floating-point exceptions by default. I've fixed my local copy to use the _control87 function to disable exceptions for those tests on that compiler, but I haven't committed it yet. Is this something we want to abstract and add to testlib? -Brad |
From: Peter V. <Pet...@es...> - 2003-10-22 20:44:01
|
> Another problem is that test_math and test_numeric_limits access the NaN > values. There is nothing wrong with this, but Borland throws > floating-point exceptions by default. A similar problem on Alpha (OSF). I've commented out the affected tests, but that's not really the best way to proceed. So it's not just Borland C++, and it would indeed be nice to have an elegant solution for this. -- Peter. |
From: Brad K. <bra...@ki...> - 2003-10-23 19:35:33
|
On Wed, 22 Oct 2003, Peter Vanroose wrote: > > Another problem is that test_math and test_numeric_limits access the NaN > > values. There is nothing wrong with this, but Borland throws > > floating-point exceptions by default. > > A similar problem on Alpha (OSF). I've commented out the affected tests, > but that's not really the best way to proceed. So it's not just Borland > C++, and it would indeed be nice to have an elegant solution for this. We could just put the floating point exception disable code in the top of testlib_main just like the crtdbg stuff for getting rid of the MSVC popup dialogs. Once we get it working everywhere with a bunch of #ifdef lines then we could consider making it a function somewhere useful outside testing. Thoughts? -Brad |
From: Ian S. <ian...@st...> - 2003-10-24 06:02:11
|
AFAIK vnl_numeric_limits was introduced because support for vcl_numeric_limits was poor amongst most compilers. Now vcl_numeric_limits is well supported amongst most compilers, and vcl provides a emulation for those that don't support it. Why do we need vnl_numeric_limits at all? Ian. > -----Original Message----- > From: Brad King [mailto:bra...@ki...] > Sent: Wednesday, October 22, 2003 6:52 PM > To: VXL Maintainers > Subject: [Vxl-maintainers] vnl_numeric_limits, NaN, and Borland C++ > > > Hello, > > I've been updating vnl to include ITK's changes to support > the Borland C++ > compiler. One change I had to make was to vnl_numeric_limits > to fix the > infinity and quiet_NaN values provided when building with > that compiler. > > Meanwhile, I noticed a few problems: > > 1.) Several values in vnl_numeric_limits specializations seem > to be wrong. > For example, unsigned short has a min_exponent of -31 and a > max_exponent of 31. The return types from min/max methods are > also inconsistent with the numeric type. > > 2.) There no specializations for char types. > > 3.) Some of the constants are static methods and some are > static constants. I do not see any reason for the inconsistency. > > 4.) Min/max values for long types are hardcoded to assume 32-bits. > It should be possible to construct almost all the values with > try-run programs during the configuration process, but that may > be overkill for now. > > Unfortunately, I cannot commit the time to fix these problems, but I > thought I'd bring them up in case someone else is interested. > > Another problem is that test_math and test_numeric_limits > access the NaN > values. There is nothing wrong with this, but Borland throws > floating-point exceptions by default. I've fixed my local > copy to use the > _control87 function to disable exceptions for those tests on that > compiler, but I haven't committed it yet. Is this something > we want to > abstract and add to testlib? > > -Brad > > > > ------------------------------------------------------- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance > to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Amitha P. <pe...@cs...> - 2003-10-24 15:54:17
|
On Thu 23 Oct 2003, Ian Scott wrote: > AFAIK vnl_numeric_limits was introduced because support for > vcl_numeric_limits was poor amongst most compilers. Now vcl_numeric_limits > is well supported amongst most compilers, and vcl provides a emulation for > those that don't support it. Why do we need vnl_numeric_limits at > all? I agree with this sentiment. And vcl is a much better place to fix any bugs related to this, because we can take full advantage of the particular compiler's idiosyncrasies. Amitha. |
From: Andrew F. <aw...@ro...> - 2003-10-25 14:06:00
|
thirded. I can attest that historically vnl_numeric_limits existed before vcl. > -----Original Message----- > From: vxl...@li... > [mailto:vxl...@li...] On > Behalf Of Amitha Perera > Sent: 24 October 2003 14:23 > To: Ian Scott > Cc: Vxl-maintainers (E-mail) > Subject: Re: [Vxl-maintainers] vnl_numeric_limits, NaN, and > Borland C++ > > > On Thu 23 Oct 2003, Ian Scott wrote: > > AFAIK vnl_numeric_limits was introduced because support for > > vcl_numeric_limits was poor amongst most compilers. Now > vcl_numeric_limits > > is well supported amongst most compilers, and vcl provides > a emulation for > > those that don't support it. Why do we need vnl_numeric_limits at > > all? > > I agree with this sentiment. And vcl is a much better place to fix any > bugs related to this, because we can take full advantage of the > particular compiler's idiosyncrasies. > > Amitha. > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Ian S. <ian...@st...> - 2003-10-27 15:55:19
|
I have now deprecated and removed all uses of vnl_numeric_limits from VXL. It should be deleted sometime after release VXL-1.1 Ian. > -----Original Message----- > From: Andrew Fitzgibbon [mailto:aw...@ro...] > Sent: Friday, October 24, 2003 5:25 PM > To: 'Amitha Perera'; Ian Scott > Cc: 'Vxl-maintainers (E-mail)' > Subject: RE: [Vxl-maintainers] vnl_numeric_limits, NaN, and > Borland C++ > > > > thirded. I can attest that historically vnl_numeric_limits > existed before vcl. > > > -----Original Message----- > > From: vxl...@li... > > [mailto:vxl...@li...] On > > Behalf Of Amitha Perera > > Sent: 24 October 2003 14:23 > > To: Ian Scott > > Cc: Vxl-maintainers (E-mail) > > Subject: Re: [Vxl-maintainers] vnl_numeric_limits, NaN, and > > Borland C++ > > > > > > On Thu 23 Oct 2003, Ian Scott wrote: > > > AFAIK vnl_numeric_limits was introduced because support for > > > vcl_numeric_limits was poor amongst most compilers. Now > > vcl_numeric_limits > > > is well supported amongst most compilers, and vcl provides > > a emulation for > > > those that don't support it. Why do we need vnl_numeric_limits at > > > all? > > > > I agree with this sentiment. And vcl is a much better place > to fix any > > bugs related to this, because we can take full advantage of the > > particular compiler's idiosyncrasies. > > > > Amitha. > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: The SF.net Donation Program. > > Do you like what SourceForge.net is doing for the Open > > Source Community? Make a contribution, and help us add new > > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |