#229 Proposal: add new functions to allowable MathML

closed
nobody
5
2015-10-28
2012-09-06
No

People seem to be using the modulus function a fair amount (it's been in Copasi for ages, translated to ugly-looking mathML), so it would be good to add those two functions to the list of allowable MathML in L3v2 core.

EDIT: Updated to make this the general tracking item for 'what MathML elements should we add to the allowable subset of MathML'

EDIT #2: After some discussion, we now have three options:

1) Add all the MathML we discussed at HARMONY to L3v2 core (basically, all the functions that are either useful or easy to implement), and put other sets into MathML-only packages.

2) Add only quotient, rem, max, min, and implies to L3v2 core (basically, all the functions that are both useful and easy to implement); put other sets into MathML-only packages.

3) Add no new MathML to core; instead, add all the MathML we discussed at HARMONY including quotient, rem, etc. into domain-specific MatHML-only packages.

Discussion

1 2 > >> (Page 1 of 2)
  • Lucian Smith

    Lucian Smith - 2012-09-06

    I agree with the proposed change and that it should be done.

     
  • Chris Myers

    Chris Myers - 2012-09-06

    I am accepting this issue as valid.

     
  • Lucian Smith

    Lucian Smith - 2012-09-06

    I agree with the proposed change and that it should be done.

     
  • Lucian Smith

    Lucian Smith - 2012-09-06

    Bruce clarifies that it's 'rem' that is modulus, and that 'quotient' is integer division (which is a different thing entirely, and may not be desirable in SBML).

     
  • Nicolas Le Novère

    I agree with the proposed change and that it should be done.

     
  • Nicolas Le Novère

    Be careful, mod is both a function and an operator. Here we are talking about the function. This must be super-clear in the spec. But otherwise, yes. (it is part of mathml, it should be included ... Can-I have a implicit yest vote for any suggestion involving the extension of what we call the MathML subset?)

     
  • Nicolas Le Novère

    • status: open --> pending
     
  • Lucian Smith

    Lucian Smith - 2013-09-16
    • labels: Level 3 Version 2 --> Level 3 Version 1 Core
    • Group: --> Accept-conformance-implications
     
  • Lucian Smith

    Lucian Smith - 2013-09-16
    • summary: Proposal: add 'quotient' and 'rem' to allowable MatmML --> Proposal: add new functions to allowable MathML
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1 +1,3 @@
     People seem to be using the modulus function a fair amount \(it's been in Copasi for ages, translated to ugly-looking mathML\), so it would be good to add those two functions to the list of allowable MathML in L3v2 core.
    +
    +EDIT:  Updated to make this the general tracking item for 'what MathML elements should we add to the allowable subset of MathML'
    
    • status: pending --> open
     
  • Lucian Smith

    Lucian Smith - 2013-09-16

    I'm setting this back to 'open' and making this the more general 'what should we add to MathML?' question.

    So far, people agree on <rem> and <quotient>, and that if we're ever going to add something, we should add it now.

    A much much longer discussion on the issue on sbml-discuss is at http://sbml.org/Forums/index.php?t=msg&th=2154&rid=0#msg_7991

     
    Last edit: Lucian Smith 2013-12-09
  • Lucian Smith

    Lucian Smith - 2013-09-16
    • Group: Accept-conformance-implications --> Reported-Proposed
     
  • Frank Bergmann

    Frank Bergmann - 2014-01-21

    I agree with the proposed change (of including all non-array/set/vector functions) and that it should be done.

     
  • Brett Olivier

    Brett Olivier - 2014-04-11

    I agree with the proposed change (as summarized by Frank) and that it should be done.

     
  • Nicolas Le Novère

    I agree with the proposed change and that it should be done.

     
  • Michael Hucka

    Michael Hucka - 2014-06-04

    I think we are trending towards the introduction of MathML extension packages, correct?

    So what remains for us here is to decide whether any extensions to MathML in Core will be made. The ones that seem least likely to be controversial are the basic arithmetic operators:
    - quotient
    - rem
    - max and min

     
    • Chris Myers

      Chris Myers - 2014-06-05

      Please add implies to that list as it is simple, and should have gone in with all the other Boolean operators.

      A => B is simply !A + B

      but it is very useful to have it explicitly. We use it all the time.

      Chris

       
      Last edit: Lucian Smith 2014-06-05
      Attachments
      • Michael Hucka

        Michael Hucka - 2014-06-05

        It's fine by me to add it. It looked like such a fringe thing that I thought no one would care to have it, but hey.

         
  • Lucian Smith

    Lucian Smith - 2014-06-10

    OK, this has gone back and forth a few times with different ideas, and I believe there are three basic options we could go with. Editors, please vote on which one you believe we should do:

    1) Add all the MathML we discussed at HARMONY to L3v2 core (basically, all the functions that are either useful or easy to implement), and put other sets into MathML-only packages.
    2) Add only quotient, rem, max, min, and implies to L3v2 core (basically, all the functions that are both useful and easy to implement); put other sets into MathML-only packages.
    3) Add no new MathML to core; instead, add all the MathML we discussed at HARMONY including quotient, rem, etc. into domain-specific MatHML-only packages.

    The basic arguments for each, as I understand them:

    1: this is the simplest to understand, and the most difficult to implement (but not horrible to implement).

    2: This adds simple new capacities to core that will not put undue burden on developers, and still provides a way to provide other capabilities to tools that need them, through the packages.

    3: This comes with zero cost to developers of core-only, provides a way to provide other capabilities to tools that need them, and even allows L3v1 models to use quotient, rem, max, min, and implies.

    Personally, I would vote for 2. I think most people won't add support for random MathML packages unless we add them to core, and people have wanted several of those particular functions for years. I don't think the benefit of letting them exist in L3v1 is all that extensive, and if it was really important to someone, we could add a new L3v1 package with those five functions in it, anyway.

     
    • Chris Myers

      Chris Myers - 2014-06-10

      While I don't have a vote anymore, I would agree that Option 2 is the best compromise.

      Chris

       
      Last edit: Lucian Smith 2014-06-10
      Attachments
  • Lucian Smith

    Lucian Smith - 2014-06-10
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,3 +1,11 @@
     People seem to be using the modulus function a fair amount \(it's been in Copasi for ages, translated to ugly-looking mathML\), so it would be good to add those two functions to the list of allowable MathML in L3v2 core.
    
     EDIT:  Updated to make this the general tracking item for 'what MathML elements should we add to the allowable subset of MathML'
    +
    +EDIT #2:  After some discussion, we now have three options:
    +
    +1) Add all the MathML we discussed at HARMONY to L3v2 core (basically, all the functions that are either useful or easy to implement), and put other sets into MathML-only packages.
    +
    +2) Add only quotient, rem, max, min, and implies to L3v2 core (basically, all the functions that are *both* useful and easy to implement); put other sets into MathML-only packages.
    +
    +3) Add no new MathML to core; instead, add all the MathML we discussed at HARMONY including quotient, rem, etc. into domain-specific MatHML-only packages.
    
     
  • Brett Olivier

    Brett Olivier - 2014-06-10

    My vote is for option 2.

     
  • Michael Hucka

    Michael Hucka - 2014-06-11

    It is worth pointing out that Sarah pointed out a benefit of option 3: the new math packages would be usable in L3v1 too.

     
    • Chris Myers

      Chris Myers - 2014-06-11

      Lucian did point this out, but he also pointed out that if needed, could create a small L3V1 package for these functions and still make them part of core for L3V2.

      Chris

       
      Last edit: Lucian Smith 2014-06-11
      Attachments
  • Sarah Keating

    Sarah Keating - 2014-06-11

    Please do not add MathML things to L3V2 core AND have them as a L3V1 package - this presents a horrible situation when it comes to having the correct SBML namespaces present for a construct to be valid.

     
    • Chris Myers

      Chris Myers - 2014-06-11

      In that case, I will would advocate option 2, since those who want these can without too much trouble move to L3V2.

      Chris

       
      Last edit: Lucian Smith 2014-06-11
      Attachments
1 2 > >> (Page 1 of 2)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks