quick, write a "compound" function that takes a function, an init value, and predicate, and returns a the list [ f(init), f(f(init)), f(f(f(init))), ... ]
, in which the last element is the element that last returned true for the predicate aka, keep collecting until pred (f ... f(init) ) returns false
So, if f is a predicate, then f is a function returning bool (since that's the definition of a predicate). If we can feed the output of f back into f again, then its input is also bool. So we know there are only two valid inputs and two valid outputs, and assuming that f is actually a function, then the same input placed into the function should return the same output every time.
If f(init) is true, and init is true, then the list will be of infinite size. If f(init) is true, and init is false, then the list will either be of size 1, or of infinite size. If f(init) is false, then the list will be empty.
However I'm not sure how many programming languages allow for a list to have an infinite amount of elements.
Joshua Cruz
but why would you compound with a predicate? compound is useful for applying a thing until something for example we can compound CDR on a list until the value is the empty list, in which case we get the last element
Bentley Gutierrez
*we get the successions of cdr with the last element being the last element of init
Carson Lewis
11025? right?
Luke Johnson
yeah
Xavier Barnes
this is like a 8 char fold expr
Levi Brown
can unfold work here?
Hunter Morgan
>However I'm not sure how many programming languages allow for a list to have an infinite amount of elements. any non-shit one in high level languages it might just happen "magically" without you having to think about it but even in C you can have arbitrarily many elements either by implementing a linked list or by repeatedly calling realloc() to grow an array
David Evans
written in shitty not-actually-C pseudocode: list[0] = init; i = 0; while(true) { temp = f(list[i]) if pred(temp) { list[++i] = temp; } else { return list; } }
Aiden Mitchell
this fails on infinite lists and isn't even a function 0/10
Brayden Richardson
>keep collecting until pred (f ... f(init) ) returns false yes if the predicate is always true then it will infinite loop but that is the expected behavior anyways. fault goes to whoever called the function with those arguments if i could solve the halting problem and magically determine whether the predicate will, at any point in the future, return false, then i would not fail on infinite lists. but before i posted that on Jow Forums i'd go accept my million-dollar millenium prize
Noah Kelly
OP is shit correct approach is to return a lazily evaluated generator which can be infinite
Jordan Stewart
This would be a naive C++ implementation:
template auto foldlist(const T& init, const Func& f, const Pred& p) { Return x = f(init); std::vector v{}; while(p(x)) { v.push_back(x); x = f(x); } return v; }
Room for improvements: - implement some kind of forward iterator type (it would still require a homogeneous Return type) - with some template metaprogramming magic don't even require a homogeneous Return type
Elijah Morales
...
Christopher Wilson
I think it looks cleaner in Rust...
fn compound(init: T, f: fn(T) -> T, pred: fn(T) -> bool) -> Vec { let mut list = Vec::::new(); let mut acc = f(init);
while !pred(acc) { list.push(acc); acc = f(acc); }
list }
Julian Sanchez
Lazy C++ implementation. Doesn't depend on any std containers, can be used in constexpr context and handles inhomogeneous init, f(init), f(f(init)) types. The foldlist starts with init, so it doesn't meet OP's spec, but I think it is nicer this way. Wouldn't be too hard to modify it to meet OP's spec though.
oopsie, I have a little error takeUntil p [] = [] takeUntil p (x:xs) | p x = [x] | otherwise = x : takeUntil p xs
compound f init pred = takeUntil pred $ tail $ iterate f init
Luke Hernandez
nevermind, I am retarded and can't read
Brayden Williams
i'd rather the pred be an until instead of a while so I can do stuff like (compound 1+ 0 (curry = 10)) read as, compound 1+ starting with 0 until it's equal to 10 instead of (compound 1+ 0 (negate (curry = 10)))
also, the list should be like so [ init, f(init), f(f(init)), f(f(f(init))), ... ]
Jordan Rodriguez
I don't know Haskell but that takeUntil doesn't look right.
Eli Wright
why not use takeWhile and a function which negates booleans?
Jeremiah Robinson
God, I am so dumb compound f i p = takeWhile p $ tail $ iterate f i
James Gray
I didn't read the task correctly
Grayson Nelson
haskell's infinite lists are nice
Blake Diaz
Can Haskell list elements be inhomogeneous type? In C++ functions can be overloaded and init, f(init), f(f(init))... each can be different type. My C++ version handles this case (as long as this doesn't generate infinite many types though)
Carson Sanders
haskell lists are homogeneous although you make a wrapper type for the types you'd like to have in there
Jaxson Ross
To the image: function getAlbumNames() { const { fromCharCode } = String; const consonants = []; const vowels = ["A"]; for (let i = 66; i
Blake Rodriguez
>KEKE
Oliver Williams
and the actual post function* anonsHomework(f, init, predicate) { yield init; for (let prev = init;;) { const tmp = prev = f(prev); if (predicate(tmp)) yield tmp; else return; } }
Jace Stewart
As long as you're allowed to repeat vowels
Lucas Miller
What the fuck is that shit
I wonder how disgusting the assembly output of that is
An analogous C++ implementation using range-v3. For some reason there isn't an analogous view (lazy list) to iterate in Haskell, so I had to implement it. It's not too hard, but the range-v3 documentation isn't too helpful with it. The actual implementation of compound is quite terse, similar to Haskell's.
#include
template class iterate : public ranges::view_facade { private: friend ranges::range_access; T value{}; const Func* func = nullptr;
template constexpr auto compound(const Func& f, const Init& i, const Pred& p) { using namespace ranges::view; return take_while(tail(iterate(i,f)),p); }
#include int main() { auto test_range = compound( [](auto x){ return x+1; }, 1, [](auto x){ return x < 10; });
for(const auto& e: test_range) { std::cout
Jace Watson
Write a function that takes two accelerating spheres with variable radius expansion rate and computes all possible contact locations (where two spheres share exactly 1 point). Pro tip: there are in to 4 such locations.
Colton Reyes
48 instructions with O3
Juan Gutierrez
not him, but: 21*5*21*5=11,025 Really you don't need a program for this... like this is worse than fizzbuzz by far. You should just use a const or readonly to optimize this shit, unless it needs to dynamically update for various character sets or something. Solving this shit is like first year math for CS so you can avoid horribly slow and inefficient solutions. Really even with a lot of languages you would probably want to just pre-generate it and use a lookup table for the results, then return that. Don't waste cycles, this is why shit is so bloated.
Lincoln Hall
Specify? You just pass any variable of a type that implements copy (the pre requisite that user made).
Samuel Young
>Really you don't need a program for this this. That's just basic combinatorics. If you need a program to answer this you need to go back to high school
Easton Wright
Stop trying to get us to solve problems, or offer a reward. We'll compete to win a prize, that makes it a fun group activity.
Jacob Brown
A line-per-line translation to C++ is possible: template std::vector compound(T init, T (*f)(T), bool (*pred)(T)) { auto list = std::vector{}; auto acc = f(init);
while (!pred(acc)) { list.push_back(acc); acc = f(acc); }
return list; }
But this one can't accept lambdas with captures. I don't know about the Rust one.