unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: David Kastrup <dak@gnu.org>
To: Mark H Weaver <mhw@netris.org>
Cc: 17485@debbugs.gnu.org
Subject: bug#17485: [PATCH 2/3] Rewrite take-right, drop-right, drop-right!
Date: Mon, 22 Sep 2014 20:40:27 +0200	[thread overview]
Message-ID: <877g0vlcro.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <87fvfjk255.fsf@yeeloong.lan> (Mark H. Weaver's message of "Mon,  22 Sep 2014 13:15:18 -0400")

Mark H Weaver <mhw@netris.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> I can take care of doing this myself, and will of course still credit
>>> you in whatever manner you prefer, but I've run into a legal problem: we
>>> don't currently have copyright papers for you on file.  Are you willing
>>> to file copyright papers for GUILE?
>>
>> No problems with that.  Standard request-assign?
>
> request-assign.future would be good, which assigns "PAST AND FUTURE
> CHANGES".  Is that what you meant by "Standard request-assign"?
>
>> At any rate, here is what I would suggest to create: a function
>> min-length receiving a list of lists (possibly as separate arguments via
>> a rest argument).
>>
>> It will return the number of times one can do cdr on every of the given
>> arguments until at least one of them turns into a list end with nothing
>> turning into anything but a pair or a list end.
>
> I agree that these are reasonable semantics for validation by 'map' and
> 'for-each'.  I went ahead and implemented it (attached below).  For
> efficiency in the common case, I check for cycles in only one list at a
> time.  If a cycle is found, the circular list is discarded and cycle
> detection begins on another list.  Let me know if you see a way to
> improve it.

Don't walk the lists in synch.  That's the worst possible way to do
stuff regarding memory locality.

Instead do the lists one by one.  Keep in mind the length of the
shortest list so far and whether any list of that length was improper.
Once you walked the length of the shortest list so far, you can abort
the current list.  Since cyclical lists will tend to be very short (and
not uncommon for the multiple-list case), I'd probably let the tortoise
run even when it is known that there is already one finite list.

Walking the lists in synch is only an advantage when there are several
finite lists and later ones are considerably shorter than preceding
ones.  Not a likely use case.

The work horse would be something like "limited-length" which gets a
list and a previous limit, where #f means "no limit and/or circular",
2*n is used for proper lists and 2*n-1 for improper lists (in order to
dominate the minimum in the case of equal lengths of proper and improper
lists).

The first idea was to use n and n-1/2, but since length comparisons are
done for every element, 2n and 2n-1 should be cheaper.

If the minimum after the last list is odd, flag an error, else divide by
2 and return the result.

-- 
David Kastrup





  reply	other threads:[~2014-09-22 18:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 10:47 bug#17485: (srfi srfi-1) reduce-right does not scale, version 2.0.9 David Kastrup
2014-06-01 23:41 ` Mark H Weaver
2014-06-02  7:59   ` David Kastrup
2014-06-03 18:56 ` bug#17485: [PATCH 1/3] Let length+ return the length of dotted lists rather than #f David Kastrup
2014-06-03 18:56   ` bug#17485: [PATCH 2/3] Rewrite take-right, drop-right, drop-right! David Kastrup
2014-06-04  3:29     ` Mark H Weaver
2014-06-04  3:45     ` Mark H Weaver
2014-09-20 14:56     ` Mark H Weaver
2014-09-20 15:15       ` David Kastrup
2014-09-22 17:15         ` Mark H Weaver
2014-09-22 18:40           ` David Kastrup [this message]
2014-06-03 18:56   ` bug#17485: [PATCH 3/3] Reimplement reduce-right in srfi-1 David Kastrup
2014-06-04  3:30     ` Mark H Weaver
2014-06-04  3:42   ` bug#17485: [PATCH 1/3] Let length+ return the length of dotted lists rather than #f Mark H Weaver
2014-06-04  4:57     ` David Kastrup
2014-06-04 10:09       ` David Kastrup
2014-06-05 13:57         ` David Kastrup
2016-06-21 14:42 ` bug#17485: (srfi srfi-1) reduce-right does not scale, version 2.0.9 Andy Wingo
2016-06-21 15:31   ` David Kastrup
2016-07-12  7:07     ` Andy Wingo
2016-07-12  7:43 ` bug#17485: Ugh, well David Kastrup
2016-07-12 13:54   ` Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877g0vlcro.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=17485@debbugs.gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).