On Dec 17, 2003, at 1:17 PM, Michael Sperber wrote:

>>>>>> "Taylor" == Taylor Campbell <xxxxxx@evdev.ath.cx> writes:
>
> Taylor> The thing about this issue is that the _right_ thing to do is
> have a
> Taylor> real vector slice API.
>
> I think vectors are just fine for many things.  Vector slices
> introduce complications best introduced in a separate, additional
> SRFI.

Yes, that's why I said it was out of the scope of this already six (in
fact, it's now eight) months overdue SRFI.

And we probably ought to wait for SRFI 47 (Array) to be finalized
before thinking about an array slice SRFI.

> Taylor> (One minor bit that I haven't really gotten anyone else's
> opinion on,
> Taylor> but I've been planning on anyways: is anyone opposed to
> switching the
> Taylor> comparator in VECTOR-BINARY-SEARCH to returning
> negative/zero/positive
> Taylor> integers, rather than the symbols LT/EQ/GT?)
>
> Rationale?

It isn't a drastic change that's bad for clarity, but in terms of
efficiency, it can be a lot better: often, the comparator will be
implemented as a subtraction, and so there are only two comparisons
per usage of the comparator, and they're integer comparisons -- fast
--; if the comparator need be implemented in terms of LT/EQ/GT anyways
then there's not much difference.  However, if LT/EQ/GT are used, then
there will probably be about four comparisons per iteration in the
search: the overhead of the comparison during the iteration will be
doubled.

Then again, it could be moot anyways and I could be spouting trout, as
I haven't benchmarked this.  Yeah, yeah, premature optimization...but
at least I say it's a _minor_ bit, so I'm not _focussing_ on premature
optimization.

> --
> Cheers =8-} Mike
> Friede, Völkerverständigung und überhaupt blabla