simon-git: spigot (master): Simon Tatham

Tue Jan 20 20:54:35 GMT 2015

TL;DR:
  3ff9f51 Add explicit force_refine parameter in iterate_to_bounds.
  02a9bdc Get rid of is_base_source() and is_cfrac_source().
  c26c2ca Complete rewrite of BaseGenerator and everything downstream of it.

Repository:     git://git.tartarus.org/simon/spigot.git
On the web:     http://tartarus.org/~simon-git/gitweb/?p=spigot.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2015-01-20 20:54:35

commit 3ff9f511be7bc8b650fabc6f07c647f85f7d272e
web diff http://tartarus.org/~simon-git/gitweb/?p=spigot.git;a=commitdiff;h=3ff9f511be7bc8b650fabc6f07c647f85f7d272e;hp=4223a43ab60aa9d0c13d707258a5ed2bd87a7c7d
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Jan 20 20:25:59 2015 +0000

    Add explicit force_refine parameter in iterate_to_bounds.

    This permits me to be a little less eager about grabbing more data
    from a spigot, in cases where I'm looping on iterate_to_bounds with a
    complicated output condition. It's good to avoid grabbing extra data
    where possible, because that way we can give as much output detail as
    we can before a FileReader throws spigot_eof.

 exp.cpp    |    4 ++--
 output.cpp |    4 ++--
 spigot.cpp |   24 ++++++++----------------
 spigot.h   |    3 ++-
 sqrt.cpp   |    8 ++++----
 5 files changed, 18 insertions(+), 25 deletions(-)

commit 02a9bdc1b578c78ee120b530d950b6537223786a
web diff http://tartarus.org/~simon-git/gitweb/?p=spigot.git;a=commitdiff;h=02a9bdc1b578c78ee120b530d950b6537223786a;hp=3ff9f511be7bc8b650fabc6f07c647f85f7d272e
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Jan 20 20:41:57 2015 +0000

    Get rid of is_base_source() and is_cfrac_source().

    I've just remembered what these were actually *for*, and they're no
    longer relevant. The point of them was that if data is being generated
    by a spigot in the same form as it's being consumed by another piece
    of code, it not only saves effort to pass it directly through without
    translating it to matrices and back, but also it makes sure all data
    gets through as promptly as possible, rather than getting pointlessly
    held up in a spigot core.

    But this was only relevant when parts of the spigot code other than
    the output systems _were_ re-consuming data in base or cfrac forms -
    and the things that did that were things like the old Gosper
    arithmetic module and the old square and cube root classes, which have
    now all been rewritten not to do that anyway because of exactness
    hazards. So these annoying and layer-violating passthroughs are
    obsolete, and can go. Hooray!

 spigot.cpp |   61 +-----------------------------------------------------------
 spigot.h   |   21 ++++-----------------
 2 files changed, 5 insertions(+), 77 deletions(-)

commit c26c2ca41bf8b8c3ded106af3984b86df4274a9c
web diff http://tartarus.org/~simon-git/gitweb/?p=spigot.git;a=commitdiff;h=c26c2ca41bf8b8c3ded106af3984b86df4274a9c;hp=02a9bdc1b578c78ee120b530d950b6537223786a
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Jan 20 20:48:04 2015 +0000

    Complete rewrite of BaseGenerator and everything downstream of it.

    The old base output system was fundamentally designed in the wrong
    order: first it generated digits by the naive method, with an
    exactness hazard at every multiple of a power of the base, then it fed
    them to a post-generation rounding step, and exponent-finding for
    scientific-notation output formats was done in several places ad-hoc.
    This led to various avoidable output-time hangs.

    For example: evaluating sin(asin(0.12345)) to 5 decimal places hangs,
    because it never manages to generate the 5. In round-to-nearest mode,
    though, it it _shouldn't_ have to hang - it ought to be able to
    produce "0.12345" as output, on the grounds that it should be able to
    tell that the answer is within round-to-nearest distance of 0.12345
    whether or not it also knows which side of 0.12345 it's on; but in the
    old setup, because rounding happened _after_ digit stream generation,
    the system would still insist on trying to produce as many digits as
    asked for plus at least one more for the Rounder, so it would still
    hang in just the same way in a case where it shouldn't have had to.
    Another example: in an odd base, known-exact halfway cases in round-
    to-nearest would never be resolved at all, because the BaseGenerator
    would just keep outputting a stream of (b-1)/2 digits forever and the
    Rounder would never find out which way to jump.

    The new architecture moves rounding and exponent-finding into a far
    more sophisticated BaseOutputGenerator class, which has basically
    nothing in common with the old (and now removed) BaseGenerator.
    Formatting the resulting exponent + digit stream into a string is done
    by a subsidiary Formatter class, which receives the _post_-rounding
    output so that it doesn't have to think about rounding at all.
    BaseOutputGenerator retrieves data at (at least) half-digit-width
    resolution, so that it can spot halfway cases between digits even when
    the base is odd; in cases where it needs to wait for more data to find
    out which way something goes (e.g. not being able to tell for a while
    whether a number will be 0.399999x or 0.400000x) it maintains two
    Formatters in parallel containing both possibilities, and discards one
    once it becomes possible to know which is out of range.

    Immediately visible effects of this rewrite include fixing of the
    exactness hazards mentioned above; a new --nibble option modifying
    printf %a formats (because it was suddenly really easy to implement in
    the new architecture and I thought it might come in handy); careful
    definition and documentation of the semantics of round-to-even and
    round-to-odd in odd bases (my previous idea of what they meant was
    incoherent, but fortunately masked by the exactness hazard preventing
    them from ever coming up anyway); and fixes to several bugs I hadn't
    previously noticed, such as exact zeroes in --printf mode not working
    at all, and negative -d in default base mode not being able to exceed
    the length of the number.

    This rewrite should also lay groundwork for the 'tentative output'
    feature described in TODO.txt. In any case where we hesitate before
    writing a digit, we now keep a pair of explicit Formatters containing
    the candidate output strings, so tentative output should now be
    implementable across all the base output modes by temporarily
    outputting the text from one of them (having first decided which is
    more sensible).

 Makefile.am     |    4 +-
 baseout.cpp     | 1615 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 baseout.h       |   77 +++
 main.cpp        |  113 ++--
 manpage.but     |    6 +
 manual.but      |   32 +-
 output.cpp      |  928 --------------------------------
 output.h        |  101 ----
 python/setup.py |    2 +-
 spigot.cpp      |  104 ----
 spigot.h        |   31 +-
 test.sh         |  101 ++++
 12 files changed, 1889 insertions(+), 1225 deletions(-)