-
Notifications
You must be signed in to change notification settings - Fork 7
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
Add bigdecimal capability #32
base: master
Are you sure you want to change the base?
Conversation
@judovana. Please check |
src/main/java/parser/Function.java
Outdated
String val = expr.solve(); | ||
String referenceName = expr.getReturnObjectName(); | ||
System.out.println("rhs: "+rhs+", mathExpClass: "+mathExpClass+", expr.class: "+expr.getClass()+", val: "+val+", type: "+expr.getReturnType()); |
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.
System.out.println("rhs: "+rhs+", mathExpClass: "+mathExpClass+", expr.class: "+expr.getClass()+", val: "+val+", type: "+expr.getReturnType()); |
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.
Yah, tracing/verbose mode is a bit missing.
Ugh. This is very hard to read. It seems to be mixing various reformatting and refactoring together with logical changes. I guess youa re not willing to split those to individual commits? If you would be my intern all above will be show stoppers for merging
But you are not my intern, and this is yours project :) So only good advices can be given. One political request if I can. I have PR adding docs for expanding and logical parsers and bumpiong ParserNG to 0.1.9. As this PR may be possibly breaking change, do you mind to release 1.9 before continuing with feature ? |
lol, sorry.. I created ParserNG in 2009. So well, a lot of design decisions taken then would not fly now. I was more concerned about creating the parser and making it multi-featured then. |
Send in the PR |
The method is marked |
True. Will add unit tests where relevant, going forward. Thanks |
I guess no. More likely I may be missing something. Can you point up a line please> |
No need to apologise. Still parseng is one of the younger. Also it is indeed feature-full. Still the tests are now there, and should be used right away O:) ps: mixing refactroign reformating and logical changes is one of the most terrible evils in sowftare development Still, thanx a lot for working on this! |
I would still heavil vote for heavy rework of initialcommits - to split refactorings, cosemtic changes, a and reallogic change. Tahnx! |
Jsut for small info - it wil be easy to adapt main CLI to use this new BIgDecimal parser. Also all "underlying" parsers (like expandable and logical) are already parametrised so they can work with BigDecimalMath out of the box. |
Hello! I'm running set of JMH benchmarks - basic It is currently moreover showing that double Double is practically no difference. Which should lead this PR to nearly complete removal double, and making I hope to have some publishable results to the end of next week. In meantime... Maybe 0.1.9 can be released. |
Ok, for now, just to String and from string: https://github.com/judovana/CustomJmhBenchmarks/tree/numbers It is interesting. It seems that it should move directly to BigDecimal :) float < BigDecimal << double and float == Float and double == Double So in the autoboxing, java is doing really great work. I am looking forward to arithmetic measurements and to ParserNG itself. Not sure when I will have more time :( |
now some basic math: https://github.com/judovana/CustomJmhBenchmarks/blob/numbers/README.md#basic-math looks more like expected . More autoboxing in equation, the worse. However it is still very minor, and generally double=Double=float=Float The BigDecimal however, is here super slow (which is logical, as it do not count in cpu but algorithmically) |
MathExpression x BigMathExpression: In the complexity of parser, the slowdown of the move from I'm planning to add also include DoubleMathExpression - jsut for this meassurments - but from all we see, the impact of Thus saying, the work should be done to make MathExpression properly extend-able, And thus have no duplicated code nowhere and support in functions out of the box. |
Originally I wanted to write some DoubleMathExpression as you did in BigMathExpression, but then I chaged my mind and simply converted whole ParserNG from double to Double -judovana@352745f Results are here: https://github.com/judovana/CustomJmhBenchmarks/blob/numbers/README.md#parserng-rewritten-from-double-to-double interesting is, that whole ParserNG got nearly immeasurable, but still visible speed up. That again is saying, that adding BigMathExpression should be done by heavy changes elsewhere, and BigMathParser should then be just candy on top of it all. Note, that without support of functions, BigMathParser is useless, and should not go in. Functions are heartbeat of ParserNG. Thus saying, I'm against this PR (but I do not have any vote). As input to functions is Unless you will require additional measurement, I think I'm finished with them. |
Oh, one important nit. With the I already did it wrong, as I was really not forseeing BigMathExpression - and eg here: https://github.com/gbenroscience/ParserNG/blob/master/src/main/java/parser/methods/ext/Avg.java#L22 it is redeclared. |
Thanks for all the work @judovana |
no worries sir :) I believe the only missing piece is some class NumberProvider, which will be converting strings and numbers, and returning some Number on demand as needed. Then MathParser, FloatMathParser and BigMathParser, built on top of some GenericNumberProvidingParser should be easy enough. As functions are taking array of Strings, they will need to handle on theirs own and support, or not support double/big/float inputs. Or the contract of functions will need to be changed, so they would receive already parsed numbers, and then the support will be just in overloading of some solve(<double/float/big> array) . However still many of implementations will need to be type-dependent similarly as the basic math operations above big x float/double |
This PR exposes bigdecimal arithmetic features to ParserNG users. This is the first stage of this feature.
For normal floating point arithmetic, we use the
MathExpression
class.For bigdecimal arithmetic, the active class is the
BigMathExpression
class.What is supported
What is not supported yet
Still to come
So this will work:
But this wont:
The last expression,
h(3)
will fail at runtime because it containssin(x)
(an inbuilt function) in its definition, whoseBigDecimal
implementation is non-existent."Will fail at runtime" implies that the function:
h(x)=3*x^2+x+2*x-sin(x)
will be successfully compiled and stored in parser memory, but when we try to use it by runningh(3)
, it will give an error