Hi.
As announced here: http://sourceware.org/ml/ecos-devel/2011-07/msg00003.html we are working on a port of Newlib's single precision floating point math library (float vs double...). I know part of the questions should be addressed to the Newlib's mailing list (which I have done as well), but I am asking help on the Ecos part of the problems. We've reached the testing phase of the single precision functions. First, I have noticed the tests provided in Ecos are different from those of Newlib's. Can anyone tell how are the test cases chosen? As one can notice, the test cases in Ecos are random, but are they randomly chosen over some interval that is "critical" for some specific function (i.e. some interval in which the specific function might return some value that differs from the value it should return, that is, in this interval the function might be erroneous). On the other hand, the test cases in Newlib are from the interval [-1.2;1.19] with step 0.01, and some other test cases that do not exceed the interval [-30;30]. Second, I have noticed, there are no tests provided in the current/tests/vectors directory (where all tests for the corresponding functions are) for these functions: acosh, atanh, gamma functions, hypot, Bessel functions, remainder, scalb, asinh, cbrt, copysign, error function, expm1, finite, ilogb, isnan, log1p, nextafter, rint, scalbn and significand (I am talking about the standard double-receiving-and-returning functions, not their float counterparts we are working on). From these functions. I could not find tests on the corresponding test folder of the Newlib (1.19.0) for these functions: remainder, scalb, cbrt, copysign, expm1, finite, ilogb, nextafter, rint, scalbn and significand. How could this be explained? I know that some of them are not standard ANSI C functions, and some of them are closely related with other similar functions (for example, expm1(x) is exp(x) - 1, as the name suggests). Also, I have noticed that in some functions, when the argument is out of range, the function returns value other than specified in documentation of the Newlib. For example, when asin receives argument not in the range [-1;1], the documentation says it should return NaN, while in fact it returns zero. And lastly, about the gamma function - I've used the tests provided from Newlib, and when I try to compile the test files about this function, I get the error ecos/packages/language/c/libm/current/src/double/ieee754-api/w_gamma.c:99: undefined reference to `signgam'. Can anyone help on this? Kind regards, Visar |
On Mon, 25 Jul 2011, Visar Zejnullahu wrote:
> Hi. > > As announced here: > http://sourceware.org/ml/ecos-devel/2011-07/msg00003.html we are working > on a port of Newlib's single precision floating point math library > (float vs double...). > > I know part of the questions should be addressed to the Newlib's mailing > list (which I have done as well), but I am asking help on the Ecos part > of the problems. Hi Visar, [cut set of Q that I do not have the expertise] > And lastly, about the gamma function - I've used the tests provided > from Newlib, and when I try to compile the test files about this > function, I get the error > ecos/packages/language/c/libm/current/src/double/ieee754-api/w_gamma.c:99: > undefined reference to `signgam'. Can anyone help on this? Look, please, at ecos math.h:160 #ifdef CYGSEM_LIBM_THREAD_SAFE_GAMMA_FUNCTIONS // FIXME: these need to be documented and signgam mentioned as non-ISO // This returns the address of the signgam variable used by the gamma*() and // lgamma*() functions externC int * cyg_libm_get_signgam_p( void ); #define signgam (*cyg_libm_get_signgam_p()) I think you will get it. Also, the next point to look on libm.cdl:125:cdl_option CYGSEM_LIBM_THREAD_SAFE_GAMMA_FUNCTIONS IMHO, the option's description attribute is the very informative. Sergei |
Free forum by Nabble | Edit this page |