Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
#76 - Better break-up fraction. #158
looking good! thanks for working on this, a nice small change that'll add lots of teaching power to mathsteps :D
I left some comments for stuff to think about to make this better
sorry for the delay - was at a conference last weekend! I'll try to be more quick back and forth with you now
I think we're gonna have to think a bit harder about how to get this working properly (unless I missed something) so let me know if you want help thinking about it!
sorry - had to leave some more comments
I think one thing that'd help with readability a lot (and help me review easier hehe) is make a clear list of the conditions that must be true for it to return true at the top of the function declaration - exactly what the things you're going to check for are. Having them all together like that will make it easier to see what you're describing - what do you think?
I'm at GoogleIO this week and can't take much time to review your code - but I replied to some comments and will actually look at the diff on the weekend
thanks for your patience! soon these rules will be easier to write hopefully - someone's working on a cleaner way to describe them right now :) (if you want to see more, check out https://github.com/semantic-math/math-rules)
Good job on this pull request! Apologies for taking so long to submit my own code review. Thanks for taking the time to clean up the code, write helpful comments and add test cases. One quick change and this should be good for merging. I see you commented out the test case
2x / (2x + 3). Why is that? Isn't it suppose to pass? Like Evy said, if it passes uncomment it and if not, add a TODO to handle the case in a future PR. This is a great start to fraction manipulation. Hopefully you can continue to add more support for handling fractions. You could probably start by finding a way to rearrange the terms in a polynomial based on exponent. This would allow you to fix the case you skipped. Anyways, good job! Push the small change and we should be good to go.
the second part numerator.op !== '+' evaluates to true so the no change node is returned. I was thinking about adding a part before this where it adds an op to add a constant node '0' to the numerator in the case of a single polynomial numerator. But idk, it might end up really fragile. What do you think we should do?
Ah good call, I see where you're referring to. Maybe you could add in a check to see if the numerator is a single polynomial term or if it is just a constant and handle it accordingly inside that if statement. By doing this, we can restrict to only the cases that we handle.
So in practice that if statement could be:
hey @evykassirer @aliang8, I've been trying to debug this but I can't seem to identify the problem. I've been poking around but I just can't seem to make sense of what's going on. When I try to incorporate the new checks everything seems to blow up. Sometimes tests from addConstantFractions give out errors, other times a bunch of tests in solveEquation fail. I am baffled. Do you guys want to check it out?
In the meantime, I just commented it out and left a TODO.