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

Re: VECTOR-MAP/INDEX

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 Dec 17, 2003, at 1:17 PM, Michael Sperber wrote:

"Taylor" == Taylor Campbell <campbell@xxxxxxxxxxxx> 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