`inconsistent valuation @ shared 'Acc'` when trying to lift non-`Acc` function to `Acc` about accelerate HOT 6 OPEN

As far as I can see (but it's late, I'll check again tomorrow) this behaviour can't be supported by Accelerate. You can 'compose' Acc programs using run and use, but you can't use such a "lifted" function within Accelerate-level control flow (such as acond or awhile), I think. The cleanest way to avoid doing so, is to really divide your program such that each part is a single Accelerate program, using only 1 call to 'run'.
We could certainly do a better job reporting this; "Cyclic definition of a value of type 'Acc'" hints in the right direction but the first error is really meant as an internal sharing recovery error.

from accelerate.

@dpvanbalen I don't see a good way to separate objective functions from optimizers in this situation. Different optimizers call objective functions in different ways, and some may call an objective function multiple times or an indeterminate number of times.

Maybe I don't understand something about Accelerate, but couldn't a function like liftAcc wrap a non-Acc function so that it takes an Acc value, evaluates it if necessary, loads it into host memory, runs the given function, and loads the result back into device memory? I understand if you can't implement this liftAcc in terms of run and use, but is it possible for Accelerate to support such functionality?

from accelerate.

It sounds like your liftAcc is foreignAcc: call some foreign code and return the result back into accelerate?

from accelerate.

@tmcdonell That looks close to what I'm looking for. My liftAcc would look something like

liftAcc :: (Arrays as, Arrays bs) => (as -> bs) -> Acc as -> Acc bs

Unlike foreignAcc, it would not depend on choice of backend or have a fallback written in Acc.

from accelerate.

The fallback choice allows you to chain multiple implementations, presumably ending with one written in pure accelerate (or, error). I don't think we can really entirely remove the dependency on the particular backend, however, because e.g. a GPU needs to copy the results back to the host, but the CPU does not.

from accelerate.

@tmcdonell It sounds like you could implement liftAcc with a chain of foreignAcc, one for each backend, followed by an error. The main downside I see is you would need to update liftAcc for every new backend. It would be nice if this functionality lived in the accelerate package.

P.S. One of my motivations for wanting a function like liftAcc is convenience for users of my library that don't know Accelerate, so they can use it without learning Accelerate.

from accelerate.