| |
 | Posted by monkyyy
in reply to H. S. Teoh |  Permalink Reply |
|
monkyyy 
Posted in reply to H. S. Teoh
| On Monday, 15 January 2024 at 19:48:30 UTC, H. S. Teoh wrote:
>
> Adam's pretty good about merging stuff that makes sense.
> Just create a project on github and invite contributors.
I can't imagine *myself* writing the 100 useful algorithms, the glue code, the 20 or so data structures alone
> My personal goal is to make my algorithms *completely* data structure agnostic.
I find that unlikely unless you stick to purely functional algorithms
in-place sorting and finding indexs/slices in my mind are imperative
>> Filter will break length, map will break a ref front, if you declare length is higher on the hierarchy than ref front, or vice versa you're necessarily limiting your flexibility and users will find hacks like adding `.array` to move up back up the hierarchy
>
> I'm confused. You just said "feature-based and not hierarchy-based" and then you start talking about moving back up the hierarchy. Which do you mean?
Im arguing why hierarchy-based suck and how users(me) respond
if I type out 5 chained functions and it says "you don't have a bidirectional range", I will throw .array in each spot before thinking about why I'm lacking anything.
>
>> 2. one of those feature sets has indexing, so searching isn't so badly designed and named
>
> Don't understand what exactly you mean here. What does has indexing have to do with "searching isn't so badly designed"?
>
> Also, a name is just an identifier; as long as it's not ridiculous I don't really care how things are named.
>
The theory of "finding" when your imagining ranges are "views of data", is you "countUntil" the right element or you return a range in a "state" that's useful in some way
I view data as having a place where it actually exists, and would like filter/chunks/slide to fundamentally leave ".index" alone
copy and pasted from my libs:
```d
enum isIter(R)=is(typeof(
(R r){
if(r.empty)return r.front;
r.pop;
return r.front;
}));
enum hasIndex(R)=is(typeof((R r)=>r.index));
auto filter(alias F,R)(R r){
static assert(isIter!R);
struct filter_{
R r;
auto front()=>r.front;
void pop(){
r.pop;
while( (!r.empty) && (!F(r.front)) ){
r.pop;
}
}
bool empty()=>r.empty;
static if(hasIndex!R){
auto index()=>r.index;
}
}
auto temp=filter_(r);
if(temp.empty){return temp;}
if(!F(temp.front)){temp.pop;}
return temp;
}
auto swapkeyvalue(R)(R r){
struct swap{
R r;
auto front()=>r.index;
auto index()=>r.front;
auto pop()=>r.pop;
auto empty()=>r.empty;
}
return swap(r);
}
```
`filter.swapkeyvalue`, should let you take any filter and get a lazy list of indexs under such a scheme.
>> 5. "composite algorithms" where you reuse smaller pieces are
>> encouraged and not blocked for "you made an extra allocation","to
>> trivail" `auto sumWhere(alias F,R)(R
>> r)=>r.filter!F.reduce((a,b)=>a+b)`
>
> Why should there be an exponential number of functions when you could just provide the log(n) number of primitives which the user could compose himself to build an exponential variety of algorithms?
Map filter and reduce, have to be template hell, but template hell should be minimized.
I'm not so convinced about all algorithms, and Id like to see a collection of small algorithms written with base algorithms end users could try first, if it fails copy and paste and edit.
|
