-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Print one based in the parser #3009
Conversation
missing dot in `A._size`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks David, this looks like a good solution. We indeed need a transform function for print
. Your solution looks solid and well tested.
One remark: I would like to extract the duplicated logic from print
and printTransform
and reuse it, to prevent them getting out of sync some day. Do you see a way to do that?
The shared logic is not much other than the regular expression The logic to split the results by I'm thinking of a few possibilities:
|
You're right, only the regex can be reused. I prefer having the regex defined only once. Can you please implement your option (2), make a file |
Hi, thanks. Sounds good I will work on it and report back.
|
Hi, I included |
Thanks David! |
The fix is published now in |
Unfortunately for the app I work on this was a breaking change and because it was included in a patch release and not a major release it went unreviewed in the package update process. We have to do a bunch of remediations as a result, and will be improving our in-house unit testing of Math.js to try and catch other regressions like this that could affect our app in future, but moving forward is there any policy regarding semantic versioning guarantees in the library? Semver seems to be the intention, but I couldn't find discussion regarding the breaking nature of this change, is that because it was considered to be a bug? Does Math.js allow bugfixes in patch releases to cause breaking changes to long-standing behaviour, or was it just missed in this instance? Btw the docs still refer to zero-based indexing here: https://mathjs.org/docs/reference/functions/print.html Thanks! |
I'm sorry to hear that. The library indeed using Semver, and bug fix releases and feature releases should not be breaking. Every bug fix changes the behavior of the library (normally for the better), but in this case we should indeed have realized that people may rely on the (non-intended) zero-based behavior and mark it as a breaking change.
The plain functions do use zero-based indexing, and the expression parser uses a one-based version of the function, see docs: https://mathjs.org/docs/expressions/syntax.html#differences-from-javascript On a side note: in my projects I use exact version numbers so I have full control, and I upgrade them manually once in a while, so I can directly verify that nothing is broken. Even though minor and bug-fix releases should be non breaking, it sometimes happens that there are unforeseen cases. |
Hi, this is according to #2989
There is no rush, please review when possible.