Repository navigation
Consider additional adapt Ops between FunctionalTypes #47
Description
Currently scijava-ops has support for the following adaptations:
Computers toFunctionsFunctions toComputersInplaces toFunctions
@ctrueden and I have discussed (several times) why the other three conversions have not been implemented. I think it a good idea to put the discussion here for posterity (and because I found myself again asking why we do not have these):
ComputertoInplace: Suppose we have adouble[]and want to mutate this array withmath.sqrt. Such a converter might look like
@Plugin(type = Op.class, name = "adapt")
public class CompToInplaceAdaptor implements Function<Computers.Arity1<IO, IO>, Inplaces.Arity1<IO>> {
@OpDependency(name = "copy")
private Function<IO, IO> copyOp;
public Inplaces.Arity1<IO> apply (final Computers.Arity1<IO, IO> computer) {
return (io) -> {
IO copy = copyOp.apply(io);
computer.compute(copy, io);
};
}
};InplacetoFunction: I cannot really think of a use case for this, but the general idea is that the user expects an output to be generated for them, and that their input will not be modified:
@Plugin(type = Op.class, name = "adapt")
public class InplaceToFunctionAdaptor implements Function<Inplaces.Arity1<IO>, Function<IO, IO>> {
@OpDependency(name = "copy")
private Function<IO, IO> copyOp;
public Function<IO, IO> apply (final Inplaces.Arity1<IO> inplace) {
return (in ) -> {
IO copy = copyOp.apply(io);
inplace.mutate(copy);
return copy;
};
}
};InplacetoComputer: I cannot really think of a use case for this, but the general idea is that the user expects the output of the Op to be placed in their preallocated output, and that their input will not be modified:
@Plugin(type = Op.class, name = "adapt")
public class InplaceToComputerAdaptor implements Function<Inplaces.Arity1<IO>, Computers.Arity1<IO, IO>> {
@OpDependency(name = "copy")
private Computers.Arity1<IO, IO> copyOp;
public Computers.Arity1<IO, IO> apply (final Inplaces.Arity1<IO> inplace) {
return (in, out) -> {
copyOp.compute(in, out);
inplace.mutate(out);
};
}
};Metadata
Metadata
Assignees
Labels
No labels
Activity
ctrueden commentedon Jul 7, 2020
I don't have any clear reasons why we shouldn't implement all of these. We aren't chaining adapt steps anymore, so there is no ambiguity. And each one could make a scripter's life easier in the right circumstance. @dietzc Do you recall any concrete reason why implementing these automatic conversions between op types would be a bad idea?
gselzer commentedon May 13, 2021
Time commitment: 1 week
gselzer commentedon Nov 16, 2023
@hinerm and I are thinking YAGNI. All of these additional functional types are dealing with Inplaces. In our limited experience, we generally don't use inplaces unless we really want efficiency, and we haven't seen that be the goal as of yet. The natural tendency is to call these things as functions, and I'm hesitant to put in X->Inplace converters that give the impression of efficiency when really they are less efficient than the
Computers orFunctions they're wrapping because of the additional copy operation.It's not that we're against adding these in, and I think we can do it if/when there is a need.
Merge pull request #47 from scijava/scijavva/scijava-ops-engine/view-…