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

Breaking changes for v4 #682

Closed
josdejong opened this Issue Jul 8, 2016 · 14 comments

Comments

Projects
None yet
3 participants
@josdejong
Owner

josdejong commented Jul 8, 2016

In this topic I will list all breaking changes for v4.

  • Change the prefixes of rad, deg, grad to short instead of long. Create radian, and give radian, degree, gradian and their plurals long prefixes. See #749.
  • Change the way constants true, false, null, undefined, NaN, Infinity, and uninitialized are parsed by the expression parser: should return a ConstantNode instead of a SymbolNode. See #833.
  • Apply new expression compiler (which doesn't use eval, and has a breaking change in the _compile function signature). See #1019.
  • Change new ConstantNode(valueStr, valueType) to new ConstantNode(value), see #1023.
  • Change the behavior of relational functions to compare strings by the numeric value they contain instead of alphabetically. See #680.
  • null
    • Drop implicit conversion from null to 0, See #830, #353.
    • change the behavior of relevant statistics functions for null values. See #830, #353.
  • Change the behavior of math.format({notation: 'fixed'}) to return all decimals instead of none, plus some other non-breaking improvements in math.format. See #676.
  • Change the behavior of implicit multiplication, see #792.
  • Change behavior of sqrt(2)(1+2) to implicit multiplication instead of a function call? See #1035. To be decided.
  • Replace constant uninitialized with null. See #833.
  • Rewrite typed-function not to use eval internally. It's not yet sure how much work that is, and whether this will have an acceptable performance.

Will not be addressed in v4:

  • Change the behavior of the {number: 'BigNumber'} config: should convert numeric input of all functions into BigNumbers (or Fractions), for example math.add(2, 4) should return a BigNumber. Not sure if this is feasible and now much effort it will require. See #864.

If you know of more breaking changes we should address, please let me know.

@josdejong

This comment has been minimized.

Owner

josdejong commented Mar 31, 2017

Added #749 to the list

@honestserpent

This comment has been minimized.

honestserpent commented Jun 14, 2017

My 2 cents: as far as treating nulls as 0s, my personal opinion is that it is better to have separated functions for taking into consideration or not null values. I would suggest taking inspiration from Matlab's mean and nanmean functions and implement separate functions to ignore null values.

I think computations over a null element should return null, and not simply ignore null values. For instance:

var matrix = matrix([[1,6,2], [1, null, 4]]);
mean(matrix);

should return null. This would tell us there was a null value involved.

This should apply to row and column means too: mean(matrix, 1) should return [3, null], whereas a function nanmean(matrix) should return [3, 2.5].

I think it would be way too easy to forget about the fact that null values are being ignored by default if they are simply ignored in mean: my suggestion is that they are treated as null, and computations over that value result in a null too.

@josdejong

This comment has been minimized.

Owner

josdejong commented Jun 18, 2017

Thanks @honestserpent , I think I agree with you.

Maybe we should also rethink all the representations of "nothing", currently null, undefined, NaN, uninitialized. That's quite a bit. In JavaScript it's also always confusing to have to deal with both null and undefined.

@josdejong

This comment has been minimized.

Owner

josdejong commented Jan 23, 2018

I'm working on getting all breaking changes for v4 implemented. Hope to finish this soon.

@josdejong

This comment has been minimized.

Owner

josdejong commented Feb 4, 2018

🎉 I've just released the first release candidate for v4.0.0, you can install this via npm:

npm install mathjs@4.0.0-rc.1 

I plan to do the final release of 4.0.0 in about two weeks, but it depends on feedback we'll receive on the release candidate.

@josdejong

This comment has been minimized.

Owner

josdejong commented Feb 4, 2018

@gizmodus, would you be interested in giving the release candidate of mathjs, 4.0.0-rc.1 a try? I would love to collect some feedback before doing the official release.

And @pjhampton, I'm not sure whether you're still involved in the integration of mathjs in DuckDuckGo, but if so, would it be possible for you to try out the release candidate of mathjs 4 too?

To install:

npm install mathjs@4.0.0-rc.1 

A detailed list with the (breaking) changes is available in the history:
https://github.com/josdejong/mathjs/blob/v4/HISTORY.md

@gizmodus

This comment has been minimized.

gizmodus commented Feb 14, 2018

@josdejong: Sorry for my late answer, I was on holiday. Yes of course, we can run our own tests with the new mathjs release candidate. Shall I report our questions / issues in this thread?

I have a question concerning the breaking change of string comparison. One of our main use cases of mathjs is to evaluate boolean expressions with math.eval(). Previously, this was possible:

"male" == "male" and 79 > 65

With v4 I get an error:

Cannot convert "male" to a number

Is there a way to achieve the same behaviour as in v3? What about comparing strings alphabetically if they cannot be converted to a number?

@josdejong

This comment has been minimized.

Owner

josdejong commented Feb 14, 2018

Thanks for your feedback @gizmodus . This change in behavior for comparing strings is explained in the HISTORY under "String comparison". Basically mathjs now assumes strings contain a numeric value. If you want to compare arbitrary strings, you can use compareNatural("male", "male"). Does that help?

@gizmodus

This comment has been minimized.

gizmodus commented Feb 14, 2018

@josdejong Yes, that helps. Thank you!

@josdejong

This comment has been minimized.

Owner

josdejong commented Feb 18, 2018

Good news: I managed to rewrite typed-function completely such that it doesn't need eval anymore, whilst still having comparable performance (!). That was quite a challenge. Still have to work out some details and last issues, it's 90% done at this moment.

This means that math.js v4 will not use eval anywhere in the code base anymore :). Hope to release a second release candidate soon.

@josdejong

This comment has been minimized.

Owner

josdejong commented Feb 21, 2018

🎉 I've just released the second release candidate for v4.0.0, you can install this via npm:

npm install mathjs@4.0.0-rc.2

This version contains the rewritten typed-function library and the new expression compiler which do not use eval anymore. This means that mathjs does not use eval under the hood anymore :D .

I hope to do the final release of v4.0.0 within a week, probably coming weekend.

@gizmodus

This comment has been minimized.

gizmodus commented Feb 24, 2018

@josdejong We updated to RC2 and ran our own tests without any problems. The memory issue is also gone as expected. Thanks a lot for this great library!

@josdejong

This comment has been minimized.

Owner

josdejong commented Feb 25, 2018

Thanks for the feedback @gizmodus, good to hear !

@josdejong

This comment has been minimized.

Owner

josdejong commented Feb 25, 2018

v4.0.0 is officially released now, enjoy! :D

npm install mathjs@4.0.0

The changes are listed on the History page: http://mathjs.org/history.html#20180225-version-400

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment