[Bug 28845] fn:format-number, formatting rules for exponential notation


--- 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