simon-git: spigot (master): Simon Tatham

Commits to Tartarus CVS repository. tartarus-commits at lists.tartarus.org
Fri Nov 6 18:45:35 GMT 2015


TL;DR:
  a31152f Add a non-negative width assertion in BinaryIntervalSource.
  e831d18 cfrac output: cope with multiple terms per spigot iteration.

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-11-06 18:45:35

commit a31152fc042026aecfe5060e8c37d3fa5b5aefce
web diff http://tartarus.org/~simon-git/gitweb/?p=spigot.git;a=commitdiff;h=a31152fc042026aecfe5060e8c37d3fa5b5aefce;hp=5b4a69a145db8ba6427d8079c853d651b977d904
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Nov 6 18:34:31 2015 +0000

    Add a non-negative width assertion in BinaryIntervalSource.
    
    If a buggy subclass returns two intervals that are actually disjoint -
    which of course _shouldn't_ happen, and as far as I know doesn't
    happen in any checked-in code, but can easily happen during initial
    development of a new function - then currently BinaryIntervalSource
    just keeps looping round forever getting confused. But that's an easy
    condition to spot, so there's no reason not to add an assertion so
    that you get a prompt termination with some indication of what went
    wrong.

 spigot.cpp |    1 +
 1 file changed, 1 insertion(+)

commit e831d185bdb21fe4f439053f69d0c35141cdb426
web diff http://tartarus.org/~simon-git/gitweb/?p=spigot.git;a=commitdiff;h=e831d185bdb21fe4f439053f69d0c35141cdb426;hp=a31152fc042026aecfe5060e8c37d3fa5b5aefce
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Nov 6 18:36:48 2015 +0000

    cfrac output: cope with multiple terms per spigot iteration.
    
    Previously, every time we went back round the main loop in
    CfracOutputBaseClass, we would call iterate_to_bounds with the refine
    flag set to true, i.e. for every continued fraction term we generated
    we would insist on receiving further actual data from our Core. But if
    the Core is returning data in particularly large blobs, then one
    single refining iteration might be sufficient to return more than one
    continued fraction term, in which case it's a pointless bottleneck to
    insist on _more_ data from the Core when we haven't used up what we've
    already got.
    
    Now, all three iterate_to_bounds loops in the continued fraction code
    make sure to start by passing refine=false on the first iteration, and
    only set it to true if that first iteration doesn't immediately
    provide enough data to make progress.

 cfracout.cpp |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)



More information about the tartarus-commits mailing list