Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 00:12
    github-actions[bot] opened #44
  • 00:12

    github-actions[bot] on new_version

    CompatHelper: bump compat for "… (compare)

  • 00:12
    github-actions[bot] opened #43
  • 00:12

    github-actions[bot] on new_version

    CompatHelper: bump compat for "… (compare)

  • Feb 27 19:21
    mforets opened #28
  • Feb 27 17:06

    mforets on tmjets_mince

    add utils file (compare)

  • Feb 27 16:00

    mforets on tmjets_mince

    add TaylorModel output (compare)

  • Feb 27 12:35
    mforets labeled #194
  • Feb 27 12:35
    mforets opened #194
  • Feb 27 12:10
    mforets labeled #2014
  • Feb 27 12:10
    mforets edited #2014
  • Feb 27 12:10
    mforets edited #2014
  • Feb 27 12:08
    mforets opened #2014
  • Feb 27 08:09
    schillic commented #1982
  • Feb 27 08:05
    mforets commented #1982
  • Feb 27 07:53
    schillic commented #1982
  • Feb 27 07:51
    mforets commented #1982
  • Feb 27 07:46
    schillic commented #1982
  • Feb 27 07:43
    schillic commented #1982
  • Feb 27 07:24
    mforets commented #1982
Marcelo Forets
@mforets
:thumbsup:
about JuliaReach/MathematicalSystems.jl#164: i agree that it would be nice to return a better error message for the examples that you sent
but given the slow progress of this PR i would rather postpone it to a follow up issue
Christian Schilling
@schillic
yes, i don't want to discuss any further
Marcelo Forets
@mforets
ok :thumbsup:
i will open the new issue
related to MathematicalSystems, can we handle from the library a case with input constraints but no state constraints? these appear quite often
but ConstrainedAffineControlContinuousSystem restricts to both input and state
i think that there are 2 options (at least):
1) create a new type, eg. StateConstrainedAffineControlContinuousSystem
Christian Schilling
@schillic
there was a discussion about this today
Marcelo Forets
@mforets
i missed it?
Christian Schilling
@schillic
implicitly
Marcelo Forets
@mforets
do you have a link?
ah yes, well but we dont have types yet
Christian Schilling
@schillic
right
but i would not add them
just use nothing
otherwise you have 8 combinations per system type
and the naming becomes ridiculous
Marcelo Forets
@mforets
:laughing:
it's an option to use nothing, but then the type parameter is Nothing
Christian Schilling
@schillic
exactly
so you can dispatch on that
having to write ConstrainedAffineConstrainedControlConstrainedNoisyContinuousSystem does not sound like something you want
Marcelo Forets
@mforets
well, ok. i prefer this than adding a new type, finally. what i thought was more like using a think layer for dispatch
haha true, but the idea is that @system macro should handle this for you..

well, ok. i prefer this than adding a new type, finally. what i thought was more like using a think layer for dispatch

i mean, to use MathematicalSets.AbstractSet and defiene a universal set in that library

Christian Schilling
@schillic
yes but you only want to use different types if you can use them for dispatch i think
storing an unnecessary nothing is not really bad
Marcelo Forets
@mforets
ok. in the long run i think that using an AbstractSet is better but i agree that nothing is better than more types :smile:
Christian Schilling
@schillic
set?
ah i see what you mean
Marcelo Forets
@mforets
:thumbsup:
then ill make a PR for the "nothing" cases soon..
as it was the case for the "scalar" issues, we can handle this at the level of the @system macro or by creating new systems constructors
Marcelo Forets
@mforets
i would tend to prefer the former if possible
because it may be simpler :smile:
Marcelo Forets
@mforets
i opened the issue; i think the most compelling reason to use a universal set is that
And also, generic algorithms do not have to consider the missing information as a special case becuase LazySets.Universe behaves as a set ;)
Benoît Legat
@blegat
Why did we go from v0.9 to v0.10 in MathematicalSystems if there was no breaking change ?
Marcelo Forets
@mforets
well https://github.com/JuliaReach/MathematicalSystems.jl/releases/tag/v0.10.0 should have been tagged v0.9.1 .. i was not too cautious about that :/
ill have this in mind for future releases
Benoît Legat
@blegat
Not a big issue
But now that we are forced to put upper bounds on Compat, doing a minor version bump creates a CompatHelper PR for each packaged depending on it ^^
Marcelo Forets
@mforets
true :)