id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
257	numeric_to_ascii_base_ can return numbers including digits not in that base	Gary Dixon	Eric Swenson	"A test program I wrote calls a new cv_fixed_point_integer_$decimal subroutine to convert an input string to a float dec(59) number; and then converts this number back to a numeric string in the same base.  This two-way conversion measure precision loss that can occur in some odd numeric bases.  However, the loss of precision is not the issue of this ticket.

For certain float dec(59) input numbers and output base values, numeric_to_ascii_base_ may emit a numeric string containing digits which are not valid for the specified output base.  Examples follow for desired output bases 14 and 15.


{{{
tcfps$test_decimal    in: ""0.01""
  details: T         out:  5.1020408163265306122448979591836734693877551020408163265306e-3
     base: 14        out:  0.00e

tcfps$test_decimal    in: ""0.01""
  details: T         out:  4.4444444444444444444444444444444444444444444444444444444444e-3
     base: 15        out:  0.00f
}}}

Notice that base 14 output ends with an ""e"" digit where the highest valid digit in base 14 is ""d"".
Base 15 output ends with an ""f"" digit where the highest valid digit in base 15 is ""e"".

In each example above, the first out: value gives the float dec(59) input to numeric_to_ascii_base_ as expressed in decimal by the numeric_to_ascii_ subroutine.

I'm guessing this may be an ""off-by-1"" bug.  For an input value just shy of a 1 in the last digit position, numeric_to_ascii_base_ adds another digit position to the right of the radix point, with a value in that position of the highest digit valid for that numeric base... but it selects a digit 1-higher than the highest valid digit by mistake.  "	defect	closed	minor	MR12.8	General	MR12.8	fixed