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 aTaylor> 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/positiveTaylor> 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