Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 28 15:58
    bnorthan commented #557
  • Jan 25 16:27
    gselzer commented #557
  • Jan 25 08:37
    imagejan commented #592
  • Jan 25 03:11
    HorizonP edited #592
  • Jan 25 03:10
    HorizonP opened #592
  • Jan 22 17:30
    ctrueden commented #591
  • Jan 22 17:26
    haesleinhuepf edited #591
  • Jan 22 17:19
    haesleinhuepf opened #591
  • Jan 21 20:21
    dariomel edited #590
  • Jan 21 20:20
    dariomel opened #590
  • Jan 21 12:56
    bnorthan commented #557
  • Jan 21 09:33
  • Jan 20 14:05
    bnorthan commented #557
  • Jan 18 22:53
    gselzer commented #557
  • Jan 18 22:53
    gselzer commented #557
  • Jan 18 20:12
    bnorthan commented #557
  • Jan 18 19:50
    gselzer synchronize #557
  • Jan 18 19:50

    gselzer on sharpen-smooth

    Add DefaultSmooth and DefaultSh… Preserve differentiation in sum… Rely on helper Ops to decrease … and 1 more (compare)

  • Jan 18 19:14
    gselzer commented #557
  • Jan 18 18:54
    gselzer synchronize #557
Stefan Helfrich
@stelfrich
Gabriel Selzer
@gselzer
@ctrueden Question: should classes such as Arity0-OT have a compute(O out) method?
Gabriel Selzer
@gselzer
I guess maybe not, seeing as how if you had an O out in mind you would just pass that to the Op builder, not the O?
Gabriel Selzer
@gselzer
@ctrueden inplaces are now supported in the OpBuilders. I added computer/inplacen methods to the OT op builders, seeing as how I didn't see any reason not to add that functionality
Curtis Rueden
@ctrueden
@gselzer Thanks. And yeah, the builders don't have apply/compute/mutate methods that accept args. Those should have been given already. If you want that, request the function/computer/inplace and use it directly.
Gabriel Selzer
@gselzer
Yeah, that was what I was assuming we would do
Gabriel Selzer
@gselzer
@ctrueden I still feel like the inplace support for OpBuilders is still a little wonky:
        final double[] actual1 = {1, 2, 3};
        final double[] actual2 = {1, 2, 3};
        final Inplaces.Arity2_1<double[], double[]> castToInt = //
            name("test.mulArrays").input(actual2).output(actual1).inplace1();
        castToInt.mutate(actual1, actual2);
Curtis Rueden
@ctrueden
@gselzer Shouldn't the input call be input(actual1, actual2)?
Gabriel Selzer
@gselzer
Ideally, yes, however if you did that here you would get an Arity2_IV_OU, which we don't want with an Inplaces.Arity2_1
So we would (will) have to restructure
Curtis Rueden
@ctrueden

which we don't want

Why not...?

I think the Arity2_IV_OV needs to support calling inplace1() to match an Inplaces.Arity2_1, and inplace2() to match an Inplaces.Arity2_2. No?
Gabriel Selzer
@gselzer
Hmm, I suppose we could, actually, I just didn't do it that way earlier since then the type parameters were weird. But I do suppose that conceptually this would probably be a sound change.
Although this could cause some type parameter shenanigans. We just have to trust that the users are smart enough to have the io argument in inputbe the same type as the argument to output
Gabriel Selzer
@gselzer
Interestingly enough, if we do this then we really don't care about the output at all. So then Arity2_IV_OU/Arity2_IT_OU can have inplace1/2 methods
Gabriel Selzer
@gselzer
Although then I suppose this brings up the question: do we want inplace1/2 methods in the OpBuilders where we have declared output types/values?
Gabriel Selzer
@gselzer
I would argue no, seeing as how if someone calls output(<some type/value>), that type/value will not be used if the user then calls .inplace()/.mutate(), so we don't want to be misleading by allowing that.
Curtis Rueden
@ctrueden

We just have to trust that the users are smart enough to have the io argument in inputbe the same type as the argument to output

You can check. And if it out is not the same reference as in1 then calling inplace1 can throw IllegalStateException.

Arity2_IV_OU/Arity2_IT_OU can have inplace1/2 methods

Sure, I think that would be fine.

do we want inplace1/2 methods in the OpBuilders where we have declared output types/values?

If you do the reference checking I mentioned, then it makes sense too, I think. But I don't feel strongly.

Jan Eglinger
@imagejan

The complex plane of Gaussian prime numbers looks beautiful: see this forum topic.
Can we generate this using ops? I imagine something like this:

ops.run("equation", img, "isPrime(p[0]*p[0]+p[1]*p[1])”)

… but we would likely need a lambda expression to define isPrime, right? Do we have to go Java, or is this possible in Groovy,Python,etc. ?

Curtis Rueden
@ctrueden
@imagejan IIRC, @bnorthan added support for passing Functions to the equation op?
This one I guess:
    (IterableInterval out) =
    net.imagej.ops.image.equation.DefaultXYEquation(
        IterableInterval out,
        DoubleBinaryOperator in)
Curtis Rueden
@ctrueden
#@ OpService ops
#@ int width
#@ int height
img = ops.run("create.img", [width, height])
java.util.function.DoubleBinaryOperator gaussPrime = {
    x, y -> new BigInteger((long) (x*x+y*y)).isProbablePrime(1) ? 1.0 as double : 0.0 as double
}
ops.run("image.equation", img, gaussPrime)
img
Jan Eglinger
@imagejan
Thanks, @ctrueden, that's great!
Gabriel Selzer
@gselzer
@ctrueden OpBuilder is now auto-generated!
Will work on Functions / Inplaces now, then will finish up with the tests
Gabriel Selzer
@gselzer
@ctrueden Code gen is functionally complete, will clean up with the little time left. What arity do we want to generate to?
Curtis Rueden
@ctrueden
What were we at before? 13 or so?
Maybe 16 for now?
Gabriel Selzer
@gselzer
Woah, I think we maxed out at 11
I can do 16 if you want
Curtis Rueden
@ctrueden
I like powers of 2. :-)
But 11 or 12 is also fine for now.
It's worth fine-tuning the templates a bit before we generate everything, since every time we tune them it will result in a largish git commit.
Gabriel Selzer
@gselzer
Looking at this hurts my brain :grin:
public interface Arity16<T, U, V, W, X, Y, Z, A, B, C, D, E, F, G, H, I>{
Curtis Rueden
@ctrueden
I favor using numbered parameters over letters.
Otherwise we'll sometime run into the Y26 bug.
Gabriel Selzer
@gselzer
Sure, I just used letters for Consumers because this was the convention we used before. I can change to numbers if you would prefer.
Gabriel Selzer
@gselzer
Did we come to a conclusion about I1 vs I for the unary ops?
Curtis Rueden
@ctrueden
I favor whatever makes the Java code most usable by programmers. The vast majority of people will never see the template, so it is OK if it's a bit more complicated. Whereas more people will look at the generated code and especially the API, which includes the generic parameter names.
Therefore, I lean toward I instead of I1.
Gabriel Selzer
@gselzer
Okay, sounds good
Gabriel Selzer
@gselzer
@ctrueden is there a good way in groovy to combine two streams?
Hmm, maybe I should say, something like zipping two streams
Curtis Rueden
@ctrueden
The same way as in Java?
I am no Groovy expert. Google will help you better.
Gabriel Selzer
@gselzer
Ah, never mind, found it :grin:
Curtis Rueden
@ctrueden
:+1:
Gabriel Selzer
@gselzer
Was not looking in the right place yesterday