-
Notifications
You must be signed in to change notification settings - Fork 294
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
Refactor #26
Refactor #26
Conversation
@joaojeronimo, it looks fantastic. I'll make a PR on your branch to add the bessel* functions that we recently added: #24 |
@hmalphettes we should. |
You guys rock! http://sutoiku.com/post/94028279288/formulajs-graduated-today On Thu, Aug 7, 2014 at 2:05 AM, João Jerónimo [email protected]
|
Once tested we should push a new release to the npm registry cheers On 7 Aug 2014, at 12:53 pm, Ismael Ghalimi [email protected] wrote:
|
Submitted a PR with the bessel functions here: Some of the tests are not passing on my machine due to overly precise number comparisons. We will need to review in depth the removal of ACCRINT: and the error handling: |
Why did we remove ACCRINT? On Thu, Aug 7, 2014 at 2:55 PM, Hugues Malphettes [email protected]
|
@ghalimi "we" did not remove it. It is removed in CrowdProcess's branch. In my understanding we are using 24 times the evil We can ask @joaojeronimo if there was something else going on. |
I don't think I ever used eval in the original codebase. Somehow it must |
Hey guys, very glad you didn't take this as a hostile fork and we can continue working together to make formula.js better :) 👍 for that. @hmalphettes thanks for the bessel PR, we're just going to add input validation to it and merge it right away; The tests not passing due to overly precise number assertions is indeed a problem that we are not sure on how to solve. Maybe make assertions to an interval instead of a fixed number ? Maybe use the cleanFloat function for assertions ? We chose to remove ACCRINT because the current implementation was not correct and not taking into account the frequency parameter, as @ghalimi says here. By the way which is the Quantitative Finance library you talk about in the post ? I looked for it but only found https://github.com/lballabio/quantlib and couldn't find the algorithm there. I found 2 common cases of eval usage:
So for now we have 8 uses of eval that we do not know how to get rid of, or even if that is possible, or even if that is desirable. But as for specific security concerns in CrowdProcess it's not a problem. About the error handling, we feel that using instances of Error is more javascript idiomatic that returning strings that one must later compare with other strings to see if they are errors or just regular function output. That would make for instance the input of |
Update: I'm going to deal with the floating number assertions with Update2: Update3: used should.approximately everywhere so now the tests pass, merged the Bessel functions and started doing input treatment in all functions (parsing strings to numbers where possible, returning |
@joaojeronimo thanks for the explanations. |
In that case please don't merge it in the next hour or so because I'm doing all the type checking and input error handling. Btw we accidentally closed this branch and started committing to our master, so if you're thinking of merging it maybe we should do another pull request with the master or restore the refactor branch and merge what we have on the master branch, tell me if you prefer any of these two options or if they're the same to you. |
@joaojeronimo it would be awesome if you could open another pull request against master. That would surely expedite the release process. |
Ok I will do that. By the way currently the coverage is 94% instead of 100% because on friday I added proper input type checking and conversion to all the formulas and now I need to test all those cases, so I'll create the PR now but it should be merged after the coverage is back to 100%. |
thanks @joaojeronimo .I'll give a look out for the PR |
@jalateras just finished covering the input parsing error cases, coverage is back to 100% and I'd say it's ready to be merged :) |
We do not expect you to accept this PR but would like to offer it anyway. We did this major refactor so it would be easier to continue to contribute. Glad to answer any questions that arise. This is still a drop-in replacement for your module.