Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Direct mlj interface #126

Merged
merged 62 commits into from
Nov 7, 2024
Merged

Direct mlj interface #126

merged 62 commits into from
Nov 7, 2024

Conversation

pasq-cat
Copy link
Member

solve this #121

@pasq-cat
Copy link
Member Author

@pat-alt everything works but i fail to improve the patch coverage further.

@pat-alt
Copy link
Member

pat-alt commented Oct 21, 2024

@pat-alt everything works but i fail to improve the patch coverage further.

Great, nice work! The docs are failing due to this error:

Error: Cannot resolve @ref for md"deep_properties" in src/reference.md.

  • No docstring found in doc for binding LaplaceRedux.deep_properties.
  • No docstring found in doc for binding Main.deep_properties.
    CheckDocument: running document checks.
    Populate: populating indices.

Is this really related to MLJ rules? Seems like there's just a missing docstring for deep_properties.

@pasq-cat
Copy link
Member Author

@pat-alt everything works but i fail to improve the patch coverage further.

Great, nice work! The docs are failing due to this error:

Error: Cannot resolve @ref for md"deep_properties" in src/reference.md.

  • No docstring found in doc for binding LaplaceRedux.deep_properties.
  • No docstring found in doc for binding Main.deep_properties.
    CheckDocument: running document checks.
    Populate: populating indices.

Is this really related to MLJ rules? Seems like there's just a missing docstring for deep_properties.

uhm i have removed my definition of deep_properties and _equal_to_depth_one since they are not needed (probably a remnant of some older test i made), and i still get the same error, probably because the docstring is missing in the MLJ definitions

@pasq-cat
Copy link
Member Author

@pat-alt
Copy link
Member

pat-alt commented Oct 22, 2024

@pat-alt how would you find the definition of https://github.com/JuliaAI/MLJModelInterface.jl/blob/03ccc2dbdc8a87b869fad27bf550f62f8a26c005/src/equality.jl#L7 i can't find it anymore.

That's a built-in function:

julia> Base.isdefined
isdefined (built-in function)

I'll have a look at the issue with deep_properties

- values that are not of `MLJType` are "equal" if they are `==`.

In the special case of a "deep" property, "equal" has a different
meaning; see [`MMI.StatTraits.deep_properties`](@ref)) for details.
Copy link
Member

@pat-alt pat-alt Oct 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pasq-cat the problem was that Documenter couldn't find this reference without the namespace.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pat-alt can you explain me how to use that "@ref" ? what does it mean? i guess it is used for crossreferencing but i have never used it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and indeed for cross-referencing, yes

sigma_scaling, rescale_stddev
sigma_scaling,
rescale_stddev

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pasq-cat I have removed the include("mlj_flux.jl") here since we no longer need it? Let's then also remove that file altogether

Copy link
Member Author

@pasq-cat pasq-cat Oct 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pat-alt i have seen you have implemented an interface with mljflux in jointenergymodels.jl . does it work well without overloading any private method?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it doesn't, same issues as here I'm afraid, so the MLJFlux dependency there is currently upper bounded to v0.5. I think we'll have to use the same approach as here eventually (directly interfacing MLJ through MMI).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i was thinking about this issue and i was wondering if we can't just take the function shape and build and use it with the mlj interface, without passing through mljflux.
shape depends only on the data, build is just adding an initial and final layer. can't we just write an if statement in the fit function where if model.model=nothing -> use shape and build to set a simple mlp?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm possibly! Let's discuss it next Tuesday?

@pat-alt
Copy link
Member

pat-alt commented Oct 23, 2024

@pasq-cat I have removed the @ref in the MMI.is_same_except docstring, because the deep_properties is part of MLJBase and cannot be accessed by Documenter.jl unless we use DocumenterInterLinks.jl. This looks a little more involved than what I currently have time for, so I'll just open a new issue for this. Feel free to explore this, would eventually be nice to use DocumenterInterLinks.jl to connect different documentations of Taija (but also feel free not to 😅 )

@pat-alt pat-alt self-requested a review October 23, 2024 09:50
Copy link
Member

@pat-alt pat-alt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work @pasq-cat 👏🏽 thanks for being so persistent with this, it's really much appreciated!

Only two minor comments for you to see, but I'll already approve this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is no longer needed, let's removed it (ipynb always clogs up the repo).

Alternatively, could also turn into a qmd and make it part of the docs if relevant.

Copy link
Member Author

@pasq-cat pasq-cat Oct 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are a couple of issues before we merge this pr.

  1. do you want to merge this one before the one for verbose->verbosity switch? change verbose::Bool with verbosity::Int #127 . if so we will have to modify the interface again before asking ablaom to review it.
  2. I would keep the ipynb for now if you are ok with it. once the interface is complete and ablaom has reviewed it i will transform it in a .qmd for the documentation.
  3. the patch coverage is still under the threshold. When i try to raise it further, i fail. It seems that the tests never hit the missing lines, which is weird and worrying.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding 1, good point, we should probably wait.

Regarding 2, yes, that's fine.

Regarding 3, are you able to inspect the missing coverage on codecov or do you not have access rights?

image

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pat-alt ops, i tried to answer via email but it seems I didn't answer under the right comment. I will post the text here again:
i can see the codecov lines, the problem is that when i tried to set a test that would cover those lines it didn't work. Theoretically when the model.model change to a different chain the last condition should be called but it wasn't.

i will try again next week because monday i have an important test.

src/baselaplace/predicting.jl Outdated Show resolved Hide resolved
@pasq-cat
Copy link
Member Author

@pat-alt sorry but looks like I can't do better than this. Looking at the COdecov report it seems that the "return false" lines in _equal_flux_chain are not hit even when the two flux models are different but the tests seem to work as intended. if you want to take a look... otherwise, we merge and then ablaom will tell us if there is something wrong.

ps: i added a simple builder for when the user leave nothing in the field model.

@pasq-cat pasq-cat requested a review from pat-alt October 30, 2024 17:26
Copy link
Member

@pat-alt pat-alt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM @pasq-cat thanks again!

@pasq-cat pasq-cat merged commit 5f66429 into main Nov 7, 2024
10 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

direct mlj interface
2 participants