simon-git: spigot (master): Simon Tatham

Sat Sep 2 16:53:58 BST 2017

TL;DR:
  bb574df Rework diagnostic system so it's always compiled in.
  0b545b9 Improve refinement policy in baseout exponent-finding loop.
  df57f3c Fix the force-refine return values in the EinSeries class.

Repository:     https://git.tartarus.org/simon/spigot.git
On the web:     https://git.tartarus.org/?p=simon/spigot.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2017-09-02 16:53:58

commit bb574df8d53a175ea23da8a38c76b409a317d307
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=bb574df8d53a175ea23da8a38c76b409a317d307;hp=d311e5ebd589d0ebbfa1d2d09e78a7edfb8d7b4d
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Sep 2 15:47:02 2017 +0100

    Rework diagnostic system so it's always compiled in.

    I'm sick and tired, when I have to debug a spigot problem, of having
    to manually edit the #if 0 in spigot.h's Debuggable class definition,
    then edit in an enable_debug() in some appropriate class constructor,
    and then unconditionally get a spew of diagnostics in the resulting
    spigot binary until I recompile again without those changes. It's
    cumbersome, and inflexible, and only lets me control diagnostics at
    the class rather than instance level (i.e. doesn't let me ask for
    diagnostics from just one of multiple instances of the _same_ class in
    a given run).

    So here's a rewrite, in which the diagnostic code is always compiled
    in. The main trick is a piece of macro ickery in which all those
    dprint() statements are now macros hiding an if statement that
    automatically checks the 'debugging' flag, and only even evaluates the
    argument list of the function if it's set.

    Also, each object is assigned a distinct 'debuggable object id', which
    are assigned in order of construction and output in the form D#nnn for
    some decimal integer n, and are printed in place of the %p object
    identifiers in the previous diagnostic system. The idea of these is
    that they're more stable than pointers - they should be the same
    across multiple identical runs of spigot in spite of ASLR, and even
    survive a recompile in most cases.

    The new UI for all this is a command-line option --debug (which I've
    intentionally not written up in the user-facing docs). Typically you
    start by running your computation with --debug=greetings, which will
    cause every created object with any diagnostic messages to just print
    its initial 'hello' message. (These are distinguished at the source
    level by being instances of the macro 'dgreet' instead of 'dprint'.)
    Having identified the id of the object you actually want to know more
    about, you then run again with an option like '--debug=12' (or
    whatever number), or synonymously '--debug=D#12', which will cause all
    the diagnostics from that particular object to be printed.

 arithmetic.cpp |  2 +-
 baseout.cpp    |  2 +-
 cfracout.cpp   |  2 +-
 enforce.cpp    |  2 +-
 exp.cpp        |  4 ++--
 gamma.cpp      |  2 +-
 main.cpp       | 30 +++++++++++++++++++++++++++++
 misc.cpp       | 10 +++++++++-
 monotone.cpp   |  2 +-
 spigot.cpp     | 39 +++++++++++++++++++++++++------------
 spigot.h       | 61 +++++++++++++++++++++++++++++++++++++---------------------
 sqrt.cpp       |  4 ++--
 trigint.cpp    |  2 +-
 unary.cpp      |  2 +-
 zeta.cpp       |  2 +-
 15 files changed, 118 insertions(+), 48 deletions(-)

commit 0b545b946d994c1298a3addc143e8225390a54c8
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=0b545b946d994c1298a3addc143e8225390a54c8;hp=bb574df8d53a175ea23da8a38c76b409a317d307
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Sep 2 16:01:57 2017 +0100

    Improve refinement policy in baseout exponent-finding loop.

    BaseOutputGenerator's exponent-finding phase had a bug similar to the
    one I fixed for continued-fraction output in commit e831d185b and its
    followup b535eb0f4. Every time it went round the loop, it would insist
    on receiving more actual data from the input spigot, even if it had
    just modified its own scaling factor in a way that might have allowed
    it to find out what it needed from the information it already had.

    Fixed using a similar strategy of having the force_refine parameter in
    the iterate_to_bounds call be a variable tracked in the exponent-
    finding loop. We set it to false whenever we change our scaling factor
    (reflecting the idea that we should at least _try_ the new scale
    factor against the information we already have), and back to true
    after we go round the loop once and haven't either exited it or
    changed our scale again.

    Added a test case that previously failed, namely a very small value
    from zeta().

 baseout.cpp | 12 ++++++++++--
 test.sh     |  1 +
 2 files changed, 11 insertions(+), 2 deletions(-)

commit df57f3c46b3dd682d6d6ad601f5c399822235cca
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=df57f3c46b3dd682d6d6ad601f5c399822235cca;hp=0b545b946d994c1298a3addc143e8225390a54c8
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Sep 2 16:36:28 2017 +0100

    Fix the force-refine return values in the EinSeries class.

    The previous commit caused an assertion failure when computing Ei(10)
    with ordinary base-10 output, which turned out to be because EinSeries
    was returning some non-refining matrices and failing to mark them as
    such, so that the owning Core got inconsistent bounding intervals for
    the represented number.

    While I'm here, I've added in diagnostics in EinSeries. (Or rather,
    left in the ones I added in order to debug the new code.)

    No new test case required for this bug fix, because an existing test
    picked it up.

 expint.cpp | 33 +++++++++++++++++++++++++++++++--
 1 file changed, 31 insertions(+), 2 deletions(-)