Quick, write a "compound" function that takes a function, an init value, and predicate, and returns a the list

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

Attached: 1541805354405.jpg (1000x1024, 325K)

Should've paid better attention in class, user.

quick, now, reverse a n-ary tree

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.

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

*we get the successions of cdr with the last element being the last element of init

11025? right?

yeah

this is like a 8 char fold expr

can unfold work here?

>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

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;
}
}

this fails on infinite lists and isn't even a function
0/10

>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

OP is shit
correct approach is to return a lazily evaluated generator which can be infinite

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;
}

template
auto foldlist(const T& init, const Func& f, const Pred& p) {
return foldlist(init, f, p);
}


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

...

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
}

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.

template
struct foldlist {
T init;
const Func& f;
const Pred& p;

constexpr foldlist(const T& init, const Func& f, const Pred& p): init(init), f(f), p(p) {}
constexpr bool is_end() const {
return !p(init);
}
constexpr const T& operator*() const {
return init;
}
constexpr auto next() const {
return foldlist(f(init), f, p);
}
};

template
foldlist(T init, Func f, Pred p) -> foldlist;

template
constexpr void for_each_lazy(const LazyList& ll, Func&& f) {
if (ll.is_end()) { return; }
f(*ll);
for_each_lazy(ll.next(), f);
}

#include

int main() {
auto fl = foldlist(1,[](auto x) { return x+1; }, [](auto x) { return x < 10; });
for_each_lazy(fl, [](auto e) { std::cout

(define (compound f i p)
(let ((fi (f i)))
(if (not (p fi)) '()
(cons fi (compound f fi p)))))

You have to specify T on the call site, right? You don't have to do that for the C++ version.

I don't know lisps, but I can see that your solution is wrong. The predicate of the last element in the resulting list should return true.

how do u work it out?

*dabs on c++*
takeUntil p [] = []
takeUntil p (x:xs) | p x = x
| otherwise = x : takeUntil p xs

compound f init pred = takeUntil pred $ tail $ iterate f init

it's not wrong
here are some examples
(compound 1+ 0 (negate (curry = 10)))
=> '(1 2 3 4 5 6 7 8 9)
(compound cdr '(1 2 3 4 5) pair?)
=> '((2 3 4 5) (3 4 5) (4 5) (5))

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

nevermind, I am retarded and can't read

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))), ... ]

I don't know Haskell but that takeUntil doesn't look right.

why not use takeWhile and a function which negates booleans?

God, I am so dumb
compound f i p = takeWhile p $ tail $ iterate f i

I didn't read the task correctly

haskell's infinite lists are nice

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)

haskell lists are homogeneous
although you make a wrapper type for the types you'd like to have in there

To the image:
function getAlbumNames() {
const { fromCharCode } = String;
const consonants = [];
const vowels = ["A"];
for (let i = 66; i

>KEKE

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;
}
}

As long as you're allowed to repeat vowels

What the fuck is that shit

I wonder how disgusting the assembly output of that is

I take back everything i said about C#

Attached: 1463721241422.png (332x512, 186K)

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;

constexpr const T& read() const noexcept { return value; }
constexpr bool equal(ranges::default_sentinel) const noexcept { return false; }
constexpr void next() { value = (*func)(value); }

public:
constexpr iterate() noexcept = default;
constexpr iterate(const T& t, const Func& f): value(t), func(&f) {}
};

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

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.

48 instructions with O3

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.

Specify? You just pass any variable of a type that implements copy (the pre requisite that user made).

>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

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.

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.