Skip to content

Conversation

@gselzer
Copy link
Member

@gselzer gselzer commented Sep 9, 2024

Also made some fixes to Any support to enable better conversion.

TODO: Parse these two out into separate commits

@gselzer gselzer added this to the 1.0.1 milestone Sep 9, 2024
@gselzer gselzer requested a review from hinerm September 9, 2024 23:08
@gselzer gselzer self-assigned this Sep 9, 2024
@gselzer gselzer force-pushed the scijava-ops-image/number-realtype-conversion branch from 7b603c7 to 3fc4631 Compare September 10, 2024 18:33
@gselzer gselzer force-pushed the scijava-ops-image/number-realtype-conversion branch from 3fc4631 to 9453816 Compare January 23, 2025 19:46
@gselzer
Copy link
Member Author

gselzer commented Jan 23, 2025

This PR has been rebased over main, and all tests pass on my machine.

The main TODO is to figure out why all of the Any work on this branch was even needed.

@gselzer gselzer force-pushed the scijava-ops-image/number-realtype-conversion branch 4 times, most recently from 209a5d1 to 6977314 Compare January 23, 2025 22:20
The broader goal here is to understand "bounded" Anys, which are very
necessary for Computer -> Function adaptation.

Suppose we ask for a
Function<IntType, Any> , hoping to match some
Computers.Arity1<I extends RealType<I>, O extends RealType<O>> via
adaptation. Adapation requires (1) the underlying Computers.Arity1<I, O>
Op, but also (2) some way to generate the output (in practice, either a
Function<IntType, Any> or a Producer<Any>). If there are no bounds on
the Any, then we can get incorrect matches, such as a Producer<Double>,
which would produce an object unsuitable for the Computers.Arity1 op
being adapted. Therefore it is necessary to attach bounds on the Any (as
an example, an Any bounded by RealType) to ensure correct matching.
@gselzer
Copy link
Member Author

gselzer commented Jan 23, 2025

Okay, now I understand! Any bounds needed some attention because it was necessary in some kinda complex adaptation scenarios, which appeared as a result of the possibilities enabled with the new converters. I wrote about the reasoning in f716a6d.

@gselzer gselzer marked this pull request as ready for review January 23, 2025 22:23
@gselzer
Copy link
Member Author

gselzer commented Jan 23, 2025

So the last thing that I want to do before merging this is to make sure that the converters actually work in practice. I tried doing that but encountered errors, so I pushed the changeset as a WIP commit. Will have to figure out when I next have time.

@imagesc-bot
Copy link

This pull request has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/fiji-friends-weekly-dev-update-thread/103718/52

@gselzer gselzer force-pushed the scijava-ops-image/number-realtype-conversion branch 3 times, most recently from 952d149 to c52471f Compare February 7, 2025 17:29
@gselzer gselzer changed the title WIP: Add Number<->RealType conversion Add Number<->RealType conversion Feb 7, 2025
@gselzer gselzer force-pushed the scijava-ops-image/number-realtype-conversion branch from c52471f to 5aea9a5 Compare February 7, 2025 17:32
It's tough to find a good comment for this, because the comment belongs
in SciJava Common3 but a persuasive argument requires discussion beyond
the scope of that project. For now, a disclaimer will do.
@gselzer gselzer merged commit b3ad0f6 into main Feb 7, 2025
1 check passed
@gselzer gselzer deleted the scijava-ops-image/number-realtype-conversion branch February 7, 2025 19:20
@imagesc-bot
Copy link

This pull request has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/fiji-friends-weekly-dev-update-thread/103718/60

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Development

Successfully merging this pull request may close these issues.

3 participants