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

Potential issues with isequivalent function #839

Open
TorkelE opened this issue May 16, 2024 · 7 comments
Open

Potential issues with isequivalent function #839

TorkelE opened this issue May 16, 2024 · 7 comments
Labels

Comments

@TorkelE
Copy link
Member

TorkelE commented May 16, 2024

I don't really know exactly what is the exact intention of this function, but some notes:

  • Events are not checked (but e.g. observables are).
  • Should complete be checked?
  • For subsystem, issetequal is used. Does this actually use isequivalent though? If not, shouldn't isequivalent somehow be called on the subsystems?
"""
    isequivalent(rn1::ReactionSystem, rn2::ReactionSystem; ignorenames = true)

Tests whether the underlying species, parameters and reactions are the same in
the two [`ReactionSystem`](@ref)s. Ignores the names of the systems in testing
equality.

Notes:
- *Does not* currently simplify rates, so a rate of `A^2+2*A+1` would be
    considered different than `(A+1)^2`.
- Does not include `defaults` in determining equality.
"""
function isequivalent(rn1::ReactionSystem, rn2::ReactionSystem; ignorenames = true)
    if !ignorenames
        (nameof(rn1) == nameof(rn2)) || return false
    end

    (get_combinatoric_ratelaws(rn1) == get_combinatoric_ratelaws(rn2)) || return false
    isequal(get_iv(rn1), get_iv(rn2)) || return false
    issetequal(get_sivs(rn1), get_sivs(rn2)) || return false
    issetequal(get_unknowns(rn1), get_unknowns(rn2)) || return false
    issetequal(get_ps(rn1), get_ps(rn2)) || return false
    issetequal(MT.get_observed(rn1), MT.get_observed(rn2)) || return false
    issetequal(get_eqs(rn1), get_eqs(rn2)) || return false

    # subsystems
    (length(get_systems(rn1)) == length(get_systems(rn2))) || return false
    issetequal(get_systems(rn1), get_systems(rn2)) || return false

    true
end
@TorkelE TorkelE added the bug label May 16, 2024
@TorkelE TorkelE changed the title Potential issues with `` function Potential issues with issetequal function May 16, 2024
@TorkelE TorkelE changed the title Potential issues with issetequal function Potential issues with isequivalent function May 16, 2024
@isaacsas
Copy link
Member

isaacsas commented May 16, 2024

isequivalent should be the same as == modulo that it ignores the names of the systems. So anything we think is necessary to decide two systems are the same should be included. (In fact, ==, and hence isequal, just calls isequivalent.)

Probably we need to make a list at some point of everything that needs updating when adding new fields to ReactionSystem. Thinks like flattening, extending, and isequivalent. (There are probably others though.) It is otherwise hard to not miss something...

@TorkelE
Copy link
Member Author

TorkelE commented May 16, 2024

Yeah, I think I entirely forgot about this when I added e.g. the metadata field. It should be noted that MTK also have related problems: SciML/ModelingToolkit.jl#2638 which we might need to consider.

@isaacsas
Copy link
Member

A checklist of what functions should be updated in the comments before the ReactionSystem structure def would probably help with this.

@TorkelE
Copy link
Member Author

TorkelE commented May 16, 2024

Maybe something we can add to the dev docs (once we write those)? Just as a natural place to keep that. Alternatively we can just create an internal .txt doc with stuff like that (that we don't necessarily display in the docs, but link to).

@ChrisRackauckas
Copy link
Member

Why isn't this isequal?

@isaacsas
Copy link
Member

We dispatch == to call isequivalent with the kwarg to require the same system name. Is there a reason to dispatch isequal instead of ==? I thought isequal falls back to == anyways?

@ChrisRackauckas
Copy link
Member

Either should be fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants