- From: <bugzilla@jessica.w3.org>
- Date: Wed, 24 Jun 2015 09:59:06 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28845 --- Comment #1 from Michael Kay <mike@saxonica.com> --- Firstly, rule (c) is talking about the number of significant digits in an integer. The number of significant digits in an integer is the number of digits excluding leading zeroes. I believe that rules (b) and (c) in conjunction uniquely define the values of the mantissa and exponent. If the adjusted number is (say) 1234.5678, then rule (b) allows you to choose (M,E) as any of (for example) (1234.5678, 0) or (123.45678, 1) or (12.345678, 2) etc. Rule (c) then restricts your choice among these alternatives: if the minimum integer part size is 3, then you have to choose (123.45678, 1) because it is the only one with three significant digits in the integer part. You ask: What is going to happen if the minimum integer part size is 0 and if there are optional digit signs in the integer part of the pattern? Optional digit signs to the left of the decimal point are more-or-less ignored; their only effect is to allow you to space out the grouping separators. (This question was resolved during the development of XSLT 2.0; some people read the XSLT 1.0 spec as saying that given a picture of '00.00', the number 123 should be formatted as "23.00" and we decided that this interpretation was wrong; the effect of this decision is that the picture '##00.00' has exactly the same effect as '00.00'.) You ask: In the current test cases "numberformat135" and "numberformat136"... fn:format-number(0.2, '#.e9') fn:format-number(0.2, '9e9') ...the expected result is "2e-1". Is the result correct for both test cases? The second one looks OK but I'm not convinced by the first. I think the rules give us a mantissa of 0.2 and an exponent of 1. The maximum fractional digits is 0 so 0.2 is rounded to zero. My reading of the rules says that after rule 7, the mantissa is ".", and after rule 12, it is "", so the result should be e1 (which isn't very nice, but you get what you ask for) -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 24 June 2015 09:59:12 UTC