> Extremely interesting, so far. The strengths of Joy and K seem tothanks
> amplify each other.
>'find' returns a single index into the list you're searching, namely,
> The only aspect of cK that perplexes me is the definition of find:
> wouldn't it be better to return 'I' when find fails? What can one do
> with an integer index one greater than the size of the vector
> searched?
the index of the first occurrence of what you're searching for. I is
a list (the empty list of integers), so it wouldn't necessarily be a good
choice for "not found". returning the size of the list for that is
often useful. either you can test
if[(#list)>i:list?target; ... i ...] / do ... with i if target in list
or you can use #list to index out a "not-found" value joined to the end
of the list:
(list,notfound)@list?target / list?target returns index of notfound
in ck,
list notfound , list target ? @
people have proposed alternatives over the years: return -1, let
list[anyoutofrangeindex] = null, &c. the important point is that
whatever value you pick for "not found" should work smoothly with
indexing, however that is implemented.
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
--- In concatenative@yahoogroups.com, "stevan apter" <sa@n...> wrote:
[snip]
>
> 'find' returns a single index into the list you're searching,
namely,
> the index of the first occurrence of what you're searching for. I
is
> a list (the empty list of integers), so it wouldn't necessarily be
a good
> choice for "not found". returning the size of the list for that is
> often useful. either you can test
>
> if[(#list)>i:list?target; ... i ...] / do ... with i if
target in list
>
> or you can use #list to index out a "not-found" value joined to the
end
> of the list:
>
> (list,notfound)@list?target / list?target returns index of
notfound
>
> in ck,
>
> list notfound , list target ? @
>
> people have proposed alternatives over the years: return -1, let
> list[anyoutofrangeindex] = null, &c. the important point is that
> whatever value you pick for "not found" should work smoothly with
> indexing, however that is implemented.
>
That makes sense. Given that requirement, the status quo looks like
as good a choice as any of the alternatives.
BTW, have any of the vector techniques used in K been applied to
text/file manipulation? I realize that K's forte is math, but I
would think that treating strings as lists--or as trees--could
provide some advantages over C-style strings in terms of flexibility,
complex algorithms, especially for really massive agglomerations of
text. (I'm just now starting to read the K reference on I/O, so, I
don't know much about it.).
--Hodge