Alex Shinn scripsit:

> +1 on not specifying algorithms.  However, in the additional
> procedures section a number of algorithm-specific vector procedures
> are given.

That's because this SRFI has two roles (and I should make it say so more
clearly): it specifies a standard, and it documents Olin's procedures.
The "additional procedures" are part of the latter but not the former.

> +1 to Daniel's suggestion for partial sorting.  I would rather make
> it a selection algorithm (top k elements unsorted), though.  It's
> easy enough to sort the result with ranged vector-sort!, and we could
> provide a utility for this if needed.

Indeed.  I don't know how to do this in n log n time or better, though.
Can you or someone explain it?

> In the draft list-sort! is listed as both linear update and as being
> required to mutate.

I'll fix that.

> I think we should also consider not requiring side effects for
> anything.

I understand the motivation, but I believe we should be able to guarantee
sorting in place, which is another way of saying O(1) space.  guarantee
that some algorithms operate with no additional space requirement,
which demands mutation in the form of sorting in place.

> vector-binary-search "returns the index of the matching element."
> Presumably if no match is found either #f or -1 is returned - we
> should say which.

I'll fix that too.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Overhead, without any fuss, the stars were going out.
        --Arthur C. Clarke, "The Nine Billion Names of God"