Re: [Success, 1% lisp-tests fail] XEmacs 21.5-b0 "alfalfa", i586-pc-win32

APA> These test fails because my system prints 3 digits for the exponent: APA> (format "%e" 100) APA> "1.000000e+002" APA> MSDN actually documents that exponents are always printed with three APA> digits. APA> What's the preferable way to fix these tests? APA> 1. APA> (cond APA> ((equal system-type 'windows-nt) APA> (Assert (string= (format "%e" 100) "1.000000e+002"))) APA> (t APA> (Assert (string= (format "%e" 100) "1.000000e+02")))) APA> 2. APA> (Assert (string-match "1\\.000000e\\+0?02" (format "%e" 100) 0)) Martin> I vote for 2. Except that the 3rd arg to string-match Martin> seems unnecessary. Martin> (Assert (string-match "1\\.000000e\\+0?02" (format "%e" 100))) Martin, for maintainability (regexps are pretty easily screwed up, I have used the fix of perl, grep, XEmacs for too long) I would prefer 1. Would it be OK with you if generated a patch grouping all %[eEgG] together in on (cond ...) and adding your comment from below? Best regards, Adrian Martin> Of course, a comment should be added. Martin> Microsoft's implementation is not standard compliant. From the standard: Martin> e,E A double argument representing a floating-point Martin> number is converted in the style [-]d.ddde_dd, where Martin> there is one digit before the decimal-point Martin> character (which is nonzero if the argument is Martin> nonzero) and the number of digits after it is equal Martin> to the precision; if the precision is missing, it is Martin> taken as 6; if the precision is zero and the # flag Martin> is not specified, no decimal-point character Martin> appears. The value is rounded to the appropriate Martin> number of digits. The E conversion specifier will Martin> produce a number with E instead of e introducing the Martin> =====> exponent. The exponent always contains at least two Martin> =====> digits, and only as many more digits as necessary to Martin> represent the exponent. If the value is zero, the Martin> exponent is zero. Martin> A double argument representing an infinity or a NaN Martin> is converted in the style of an f or F conversion Martin> specifier. Martin> So the truly correct thing to do is for (format) to remove the extra Martin> zero digit, but only on Microsoft platforms. Probably not worth it. -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/