[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vector-binary-search

This page is part of the web mail archives of SRFI 43 from before July 7th, 2015. The new archives for SRFI 43 contain all messages, not just those from before July 7th, 2015.

On 31 Mar 2004, campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:

> It's not quite as clear-cut as you make it seem.  Olin Shivers stuck
> with the convention because there were no inherent benefits _for_those_
> sorting_algorithms_.  However, there _are_ inherent benefits for
> _searching_ (and for a few sorting algorithms).

Olin planned to have versions of sort functions with suffix "3".
So, maybe the compromise could be the same for this SRFI-43:
to have both, vector-binary-search and vector-binary-search3
> > My other problem with three-way comparators is the fact that there 
> > is no three-way boolean to represent their results; symbols and
> > -1, 0, 1 are equally bad in this respect, more so because of 
> > lack of precedent (no standard Scheme function uses symbols
> > as flags or enumerated options). 
> > 
> > P.S. Symbols are actually worse than -1, 0, 1 because with
> > the latter, one can use, say, * as a substitute for three-way 
> > boolean operations; with symbols all operations have to be 
> > written explicitly.
> I'm sticking with negative, zero, and positive.  That convention is
> used all over the place, it's efficient, and it's convenient.

Agreed. (This was exactly Olin's reply to my (naive) proposal to use 3
symbols for representing comparison results.)


Attachment: pgpmhz5pSC257.pgp
Description: PGP signature