stillwater-sc / universal / 34897454005

86%

master: 84%

Build Type

push

github

Committed by web-flow

Commit Message

fix(areal): read areals from text: parse(), assign() and operator>> (#1505)

std::cin >> someAreal never worked (#1454). The friend declaration of operator>> took a
mutable reference and the definition a const one, so extraction into an areal selected the
declared overload, which was never defined: a link error. The definition would not have
compiled anyway, since it read a _fraction member areal does not have. assign(std::string)
was a stub that printed "assign TBD", and there was no parse().

parse(const std::string&, areal&) now reads the three forms an areal is written in:
- d, a decimal: the value truncated toward zero, with the ubit set when that loses anything.
  That is the rule conversion from double already follows, but applied to the exact
  decimal, so digits past double precision still count: 1.5000000000000000000001 reads as
  (1.5, 1.50195), not [1.5].
- [d], the exact form operator<< writes: the exact areal nearest to d. operator<< prints a
  handful of digits, so d itself is usually not exact. Ties go to the even encoding.
- (d, dnext), the uncertain form operator<< writes: the open interval between two adjacent
  exact values, the nearest ones to d and dnext. Either order is accepted, so a mathematical
  interval of negative values works too. Endpoints that are not adjacent are rejected.
Inf and nan are accepted bare or bracketed, in the usual spellings; a nan reads as quiet.

The decimal goes through decimal_to_binary, packed into a blocktriple<fbits, MUL> as cfloat's
parse() does, and convert(blocktriple, areal) truncates and sets the ubit, including for the
converter's own guard and sticky bits. That keeps parse() exact for every width, including
the areals wider than a double. Two guards around the converter:
- It loses bits silently when a decimal needs more working bits than its width (#1504). So
  parse() sizes the width from the converter's own estimate, 2048, 8192 or 32768 bits, and
  rejects text needing more rather than re... (continued)

Coverage Stats

127 of 132 new or added lines in 2 files covered. (96.21%)

8 existing lines in 1 file now uncovered.

43990 of 51245 relevant lines covered (85.84%)

8118412.92 hits per line