Bug#572746: libm: sinf/cosf performance is awful on amd64
On 17.03.2010 11:29, Vincent Lefevre wrote: On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote: On amd64, only sincos has an optimized version, It may be optimized, but completely buggy. For instance, on 1e22, sincos returns 0.46261304076460174617 for the sine instead of -0.85220084976718879499 (correctly rounded value). Even the sign is incorrect! Sorry, but I don't see the error. Both are the correct values, as any values from -1 to 1. The double 1e22 is outside the *relevant* precision for double, e.g. a whole range of 2*pi is described with the same number (1e22). Maybe using long double (and sincosl) you will have the expected results (I did not calculate the minimun precision of long double). ciao cate -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ba0cde0.1020...@debian.org
Bug#572746: libm: sinf/cosf performance is awful on amd64
On 17.03.2010 14:36, Vincent Lefevre wrote: On 2010-03-17 13:41:04 +0100, Giacomo A. Catenazzi wrote: On 17.03.2010 11:29, Vincent Lefevre wrote: On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote: On amd64, only sincos has an optimized version, It may be optimized, but completely buggy. For instance, on 1e22, sincos returns 0.46261304076460174617 for the sine instead of -0.85220084976718879499 (correctly rounded value). Even the sign is incorrect! Sorry, but I don't see the error. Both are the correct values, as any values from -1 to 1. The double 1e22 is outside the *relevant* precision for double, e.g. a whole range of 2*pi is described with the same number (1e22). No, this is wrong. This could be correct with interval arithmetic, but floating-point arithmetic works differently: inputs are regarded as *exact*. Are you sure? From C standard (not really the standard, but the draft n1256: 5.2.4.2.2, point 5): : The accuracy of the floating-point operations (+, -, *, /) and of : the library functions in math.h and complex.h that return : floating-point results is implementationdefined, : as is the accuracy of the conversion between floating-point : internal representations and string representations performed by : the library functions in stdio.h, stdlib.h, and wchar.h. : The implementation may state that the accuracy is unknown. And also looking in POSIX, I find no further requirement, so are you sure that 1e22 should be taken as exact. So maybe the bug is to define __STDC_IEC_559__ on such case. OTOH, section F9.1 don't require (my interpretation) trigonometric to be IEC 60559 functions. It has such requirement for more elementary functions, e.g. for sqrt (see section F3). OTOH I think you are an expert on such standards, so it is possible/probable that I'm completly wrong. ciao cate -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ba0ffed.6070...@debian.org
Bug#453041: Country Liechtenstein not in country list when selecting German as language in installer
CC: to madduck. IIRC he is rewriting the locales for Switzerland, so probably he could do quickly also for Liechtenstein too. BTW madduck: there is some news about the project? ciao cate Christian Perrier wrote: reassign 453041 locales retitle 453041 Please provide a locale for German/Liechtenstein severity 453041 wishlist thanks Quoting Josef Vogt ([EMAIL PROTECTED]): Package: installation-reports Version: When installing debian, when choosing German as language, the country Liechtenstein isn't in the list for German speaking countries. It would be nice also Liechtenstein having in this list, because German is the only official language in Liechtenstein. Countries that are displayed after the language selection are countries for which a locale with the given language exists in the locales package. Not countries for which the given language is an official language. This is often the same list because, of course, locales have been written for language/country combinations that make sense. The solution to this problem is writing a de_LI locale, which would definitely make sense. Writing locales is not that hard: pick up a similar locale on your system (/usr/share/i18n/locales/de_DE) and modify the country-dependent parts to fit the new country. Then name it appropriately (here de_LI). It of course needs some knwoledge of the said country and the said language. The only tricky part is that locales files use U notations which makes writing them quite tricky. Thankfully, Denis Barbier wrote the attached scripts, in the past, that help converting file back and forth from UTF-8 to U notation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
Anthony Towns wrote: On Mon, Oct 01, 2007 at 04:30:17PM +0100, Ian Jackson wrote: Ian Jackson writes (Re: getaddrinfo() behaviour): Limiting the TC's power to overrule a technical decision to only cases where the TC believes that the wrong behaviour makes the package unsuitable for release would eviscerate the only mechanism we have for dealing with errors by maintainers. I should have said, for dealing with errors by maintainers which persist after persuasion has been tried. Updating the proposed standard has not been tried. If it had, and failed, and did so without addressing the concerns we've had with the current rfc, it'd be appropriate for the tech ctte to rule -- we would have exhausted all other means of obtaining a consensus, and it would be the last resort. No! There is one or two updates for the proposed standard. IIRC one is in the last phase, before to be published. [But anyway they are about IPv6, and not rules 9] To check: http://www.ietf.org/ put in the search 3484 and you see a lot of discussions about updates So it seems (IMHO) that RFC3484 is not mature to be (and become) a Internet standard. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
