Why not define the broadcast machinery for your Particles type and force the user to use broadcasting in this kind of scenario?
The problem is third-party code. I can’t make the user reimplement a third-party library to make their functions and objects work with my exotic number type 
(That, if possible, would have solved all my problems 
)
But I wonder why you expect this code p > 0 ? 1 : 0 to work for Particles. I can argue that it doesn’t work because it doesn’t make sense when some particles are positive and others are negative. Perhaps, it is more semantically sound then to have the user use a different Julia construct, e.g. map.
No I do not expect it to work and it doesn’t. But the result of the outer function is well-defined, it’s just a matter of getting there. map is a good option when particles appear on the input, I already have machinery for this docs.
My example function implements (almost) 0.5(sign(x)+1). If sign(p)) is called with particles, this returns the desired result (50/50 1/-1) It just so happen that sign is a function where the particles appear as arguments and defining this is easy. Arbitrary third-party functions, acting on objects with uncertain fields, that internally use branching, these are the problems. They are only well-defined if seen as a larger unit, as the branching inside are impossibl to handle unless julia implements support for fuzzy logic.
I think I am beginning to understand the problem. If branching is one (or the main) issue, how about a macro that transforms:
@fuzzy(p, f(p) ? 1 : 0)
to
if p isa Particles
map(p -> f(p) ? 1 : 0, p)
else
f(p) ? 1 : 0
end
?
Well, once again it’s third-party code with third-party structures that cause problems… 
Well, if you can’t even tell the users these constructs are supported and these are not, I am not sure how to do what you are trying to do. I was trying to figure out the basic constructs that are causing issues. Branching is one. Transforming code blocks can only done using macros or by Cassette overdubbing which acts on the function-call level of modularity, i.e. not sure how if statements can be transformed. This means that if dispatch falls short, macros are your only go-to solution. Parsing the whole function body and modifying it is another option, but again you need a recipe for this transformation which may be harder to figure out in the generic case than if you just restrict your users to some specialized constructs, e.g. the @fuzzy macro for branching.
1 Like
I have actually solved the problem somewhat satisfactorily, detailed in this answer and documented the limitations and potential solutions here. The only remaining issue is the world-age problem