Closed MichaelClerx closed 4 years ago
I think it's imtentional. @nickerso?
yep, imtentional :) @hsorby was arguing that some languages include the leading +
by default, but we can't find any examples in practice.
ok!
Wait, what? In any language I know you can write x = +1
Including MathML, for example
And we're allowing 1e+2
too
The only place we're allowing the + is in the exponents, yeah. Not sure on the fundamental reason for that though...
We allow in the exponential because some languages/tools will write it out. There are no examples we can find where a tool or language will write a +
in front of positive numbers. Technically it can certainly be done but it generally is not done in practice. Are there known examples where this is needed? (As always, we don't stop people putting whatever they want into a MathML number...
Does that mean that this is valid?
<math>
<apply><eq/>
<ci>x</ci>
<cn>+1</cn>
</apply>
</math>
... but this is not ... ?
<variable name="x" initial_value="+1"/>
??
yep - CellML doesn't describe the rules for valid MathML, we just say which elements from MathML 2.0 are valid to use in a CellML model.
We allow in the exponential because some languages/tools will write it out. There are no examples we can find where a tool or language will write a
+
in front of positive numbers. Technically it can certainly be done but it generally is not done in practice. Are there known examples where this is needed? (As always, we don't stop people putting whatever they want into a MathML number...
That's a very tool-based reason!
In my mind sticking a plus or a minus in front of a number are just two opposite equal things, so it seems a bit weird to disallow one, while every tool I know of will parse "+1" just as easily as it will parse "-1"
Also allowing it in the exponent but then not in normal numbers really grates me
Thats what I would have thought @MichaelClerx, but thought your earlier OK
and closing the issue resolved things :) Thought we had got off lightly on this one!
I'm not strictly against allowing the +
so happy to add it if people think it would be useful.
I'm wondering if it would make validation easier. At the moment I'm just passing the string into Python's float()
, which means I wouldn't catch "+1" as an error. I'll need to change this anyway as float
also accepts e.g. "nan"
and "inf"
as input, but I imagine there's more languages where e.g. int(x)
only allows integers, possibly prefixed with a + or a -, and the same for `float?
Aaaactually, we're making a mistake here then, aren't we:
- An exponent SHALL be represented by an exponent separator character, followed by the integer string representation of the value of the exponent. Non-negative exponents MAY begin with the Basic Latin plus sign character U+002B as the sign indicator.
That can't be right, because an exponent separator character followed by an integer string representation can never be "e+3".
This contradicts directly with the next sentence "Non-negative exponents MAY begin with the Basic Latin plus sign character U+002B as the sign indicator.". Because if that's true the thing following the exponent separator character is not an integer string representation.
So against allowing a "+":
For allowing +:
I would tentatively add a "it's what people would expect" as a fifth point in favour. Because apparently we were expecting it ourselves when we wrote the real number string definition?
That can't be right, because an exponent separator character followed by an integer string representation can never be "e+3".
... why not? 1e+3 is fine?
It's not "an exponent separator character followed by an integer string". It's an exponent separator character followed by a plus sign followed by an integer string.
I think it's a great representation, don't get me wrong, but if we say that "-1" is an int, but "+1" is not, then "1e-3" is a 1, plus an e, plus an integer string ("-3"), while "1e+3" is a 1 plus an e plus a "+" plus an integer string ("3")
So why not just say "+1" and "-1" are both integer strings, then all we need to say is "e or E followed by an integer string" and we're done
Seems that this should go in.
We're currently allowing
-1.23
and also1e+23
, but not+2
or+1.23e+456