From: Wheeler, Frederick W (Research) <wheeler@cr...> - 2003-10-23 15:56:37
I think we should make a new file named $VXLSRC/TODO.txt that lists changes
that should be made to VXL, like these that Brad suggests. Placing the file
at the top follows FSF project behavior.
This file could serve in many ways. People using VXL but not intimately
familiar with VXL who wish to contribute, might find something they can and
want to tackle in the list. Various maintainers who have suggestions about
how to go about particular changes can place them in the file.
Would it be better to use the SF Bug Tracker? I think that might be too
much overhead for people to use regularly. A simple file like I'm
suggesting is easier to use.
Let me know what you think. If there are no objections, I'll create the
file with some sort of organization scheme and get it started with this
item, and a perhaps few others. We can always delete it later if we do not
find it useful.
> -----Original Message-----
> From: Brad King [mailto:brad.king@...]
> Sent: Wednesday, October 22, 2003 1:52 PM
> To: VXL Maintainers
> Subject: [Vxl-maintainers] vnl_numeric_limits, NaN, and Borland C++
> 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?
> 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
> Vxl-maintainers mailing list