This version takes parser-ng-arrow to the next level by adding the filter, the project and the filterProject methods.
This extends ParserNG's reach into BigData as not just an evaluator, but also as a query(non-SQL) engine fo BigData. This functionalities are available across the CPU and GPU.
Enjoy!
- This version features the gradual phaseout of SIMDEngineEvaluator and the phase-in of the SIMDCommand series. The former SIMDCommandEvaluator is also being retired for a suite of SIMDCommand classes; one for handling float64(double) data, one for handling float32(Java's float primitive) data, one each for handling MemorySegment storing doubles and MemorySegment storing floats. SIMDCommandF32, SIMDCommandF64, SIMDCommandSegmentF32, SIMDCommandSegmentF64, The API remains unchanged from that of the SIMDEngineEvaluator. SIMDCommandF32 runs faster by default than the others since it is handling float32 data.
- The second big addition to the ParserNG runtime is the
parser-ng-arrowextension which brings the SIMD and the GPU leveraging power of ParserNG to the Apache Arrow library. Out of the box,ArrowBulkEvaluatoruses ParserNG's SIMD integration to beat the existing evaluator, Apache Gandiva on most expressions, save pure arithmetic and expressions where Gandiva can use the native hardware intrinsics (sqrt) where Gandiva is about 1.5x to 2x as fast. Since ParserNG comes with a parallel mode in its SIMD evaluators, if you set it to true, out of the box, you will see even more throughput depending on how many processors and how much RAM your device possesses.
The second class is ArrowGpuBulkEvaluator which lets you select the GPU to use on your system to process Arrow data. It supports OpenCL and CUDA.(Feedback is needed on both paths, but especially on the CUDA path.)
Both ArrowBulkEvaluator and ArrowGpuBulkEvaluator support Float4Vector and Float8Vector.
For more on ArrowBulkEvaluator, see:
parser-ng-arrow's README.md
For more on ArrowGpuBulkEvaluator, see:
parser-ng-arrow's GPU README.md
- Thirdly, Metal framework support has been added to the GPU bulk evaluator and the incubating LLM engines, which formerly supported CUDA and OpenCL alone, bringing the macOS ecosystem into the ParserNG GPU bulk evaluation/LLM world, or vice versa.
This update strengthens the differential equation engine by adding systems solving capability explicitly
in the diffeqn and diffeqnPath paths. The engine has also been given a battery of tests, 120 in number
to check the engine for correctness and to give users an insight into the usage.
Equally important in this release is the emergence of the ARRAY type in ParserNG.
This is the piece that made the systems solving ability possible in ParserNG.
Pre-dating the ARRAY type was the VECTOR type which was simply an array of numbers.
The ARRAY type allows one to store both numbers, strings etc.
It is also bound to the Function class. So a Function in ParserNG may be a VECTOR(a 1D matrix), a MATRIX, an ARRAY, or an ALGEBRAIC_EXPRESSION. You may access it with the getArray() method on the Function object.
More methods are layered on the MathExpression object such as solveGenericWithThrows and
solveWithThrows, which throw java.lang.Throwable`, if the expression errors out during evaluation.
There may be a slight breaking change also with the MathExpression constructor which now throws an InputMismatchException.
It features a differential equation solver that supports rk4, rk45, euler, implicit_euler, bdf2. Incubating in parser-ng-gpu-simd extension is a pure Java Llama model runner which uses the GPU(CUDA and OpenCL) to execute Llama models. We will need a lot of feedback from our users on this, as it is in active development.
Stabilized v3.0.0
- GPU bulk evaluator(CUDA and OpenCL) comes to ParserNG with MemorySegments and zero dependencies; no JNI hell.
- SIMDEngineEvaluator with MemorySegments also and SIMDCommandTurboEvaluator from ParserNG Enterprise now open-sourced and released with version 3.0.0
- Nth-order Automatic Differentiation, A fresh symbolic differentiator and a resilient numerical integrator, fronted by a symbolic integrator to expand the range of numerically integrable functions
- Conditionals; if, &&, || implemented all the way from parser frontend to all backends(std evaluator, 2 turbo scalar evaluators and 1 turbo matrix evaluator, bulk evaluators(vector simd and auto-vectorization type) and GPU bulk evaluator)
Full migration of all inbuilt functions and UDFs to the Vector API(not stats functions), leading to 2.0x to 14x speedup in bulk evaluations
Very stable release. Lots of bug fixes in bulk gelu, swiglu etc
More stable. Cleaned up API.
More stable. Indexing bugs fixed in bulk processors
Guess who the kid on the block is? Vector API bulk evaluator(SIMDVectorTurboEvaluator)and its compatibility partner, VectorTurboEvaluator.
Both run bulk evaluations at roughly same speed(competitive with Janino), and come with workers out of the box!
VectorTurboEvaluator works because its code is mechanically sympathetic to the hardware running it, so auto-vectorization occurs.
Version 1.2.1 fixes bugs in Matrix Algebra in the standard mode.
Version 1.2.0 introduces pure Matrix algebra into ParserNG standard. Its great performance is not at par with what ParserNG Turbo can do( with MatrixTurboEvaluator), in terms of memory allocation optimization and matrix evaluation speed, but it ensures that Matrix Algebra is fully available alongside matrix functionality on ParserNG Standard also.
We have completely refactored the runtime variable mapping layer inside ScalarTurboEvaluator1 and ScalarTurboEvaluator2.
- Runtime Remapping Eliminated: Variable array positions are now baked directly into the
MethodHandletopology at compile-time. The runtime engine now evaluates expressions by reading straight from the user's input arrays. - 30%+ Evaluation Speed Burst: Microbenchmarks show arithmetic evaluation speeds dropping from ~18ns down to ~12.2ns, pulling within arm's reach of raw native Java performance (~6.4ns).
- Flat Memory Profile: GC allocation churn on hot evaluation paths remains at absolute zero. This guarantees stutter-free performance during heavy graph plotting or the soon-coming multi-million step differential equation loops.
Version 1.1.4 squashes a bug where an over active syntax checker disables nested stats functions e.g. sort(3,1,5,listsum(4,12,18,-9),5,2,31,4) returns a syntax error Added tests
Fixed validation bugs in parser, made relevant matrix maethods support algebraic operations, like A*invert(B) etc, fixed bad bugs in flat matrix turbo implementations and optimized them further. Added tests
- Fixes bugs and makes
MatrixTurboEvaluatornatively support turbo execution of the rot function. Note that theScalarTurboEvaluators already support it. - Also
FastCompositeExpressionis now aware of its compiler as it now sports agetCompilerdefault method(which can be overriden to specify the turbo class that compiled it)
Implemented version retrieval for ParserNG
Bug fixes in Rotor and ErrorLog. Matrix of Points upgrade for Rotor
Bug fixes and more Android compatibility issues resolved.
Bug fixes and Android compatibility issues resolved.
Features bug fixes and optimizations in the scanning/semantic analysis stages.
This version features various optimizations and turbo capability for the Function class.
Parser 1.0.3 has been released on maven-central!
Maintaining the industry standard besting speeds of v1.0.x, it adds the functionality of rotational geometry.
In v1.0.3, you can use the rotor function, rot to rotate raw points in 3D space and other functions such as curves, lines, surfaces(both plane and curved) and 3D equations of all sorts.
Version 1.0.2 retains the wild speeds of Version 1.0.1. Adds an extra widening technique of variable passing to the Turbo mode, In addition to the current method of array based passing. The widening technique can be sometimes faster than the array based methods, but their speed profiles and memory profiles are similar. Its weakness though is that it cannot use more than 63 variables per expression, whereas the array based approach allows in theory any number up to the max integer size.
This close update ensures that Turbo mode's memory profile stays close to that of the normal mode, which is, nigh zero.
The library has finally come of age with the introduction of its Turbo mode, which offers a massive speed boost over its normal mode. The nomal mode already beats famous libraries like exp4J, and rivals Janino, the widely acclaimed Gold Standard of Java math parser speed measurements, very closely
-
Functions like
intg,root,t_rootandquadratichave been fixed and are working well. . -
Frame based args passing is used to milk to milk the last drops of performance during iterations.
-
Constant folding and strength reduction make the evaluation process feel much faster.
-
The
printfunction that can be used to view the contents of anEvalResultwhich thesolveGeneric()method returns is also functional. -
If you need a rich, fully featured parser that can do 3 million to 10 million evaluations per second, ParserNG v0.2.5 is the one for you.
ParserNG 0.2.4 drives the limits of expression interpretation velocity even further than all previous versions, beating many lighterweight and fast Java math parsers(interpreted) in many benchmarks.
Check ParserNG-Wars for some shootouts between ParserNG and other parsers, both handrafted benchmarks and JMH based ones
ParserNG evaluates expressions at almost the speed at which the expressions would run if they were compiled statements in Java code. Typical values for moderate expression evaluation speeds are between 85ns(algebraic expressions e.g.((12+5)*3 - (45/9))^2 to 176ns(methods with trig. functions, e.g. (sin(3) + cos(4 - sin(2))) ^ (-2)).
Applications that need 5 million to 10 million points generated per second would benefit from ParserNG v0.2.4
comes with couple microsecond (on decent hardware and) expression solving ability while maintaining its full feature stack. Graphing feels butter-smooth and iterations shouldn't feel so iterative.
At 5 microsecond, moderately complex expressions such as
String s6 = "5*sin(3+2)/(4*3-2)";can be evaluated almost 200 thousand times per second.
The model of a Matrix has also been optimized to use a 1D array internally. This makes it faster due to memory locality of Matrix data.
Also, we support eigenvalues and eigenvectors as inbuilt methods, so enjoy!
- Breaking change!!! Package name change. ParserNG now has a proper root package name, com.github.gbenroscience
- Really cool!!! -> Speed upgrades of up to 10x to 40x in the base algebraic expression parser. This means more speedy and energy efficient iterative calculations and graphing!
- Very nice to have -> ParserNG now comes with a Java platform agnostic graphing capability. All the developer needs to do is to implement 2 interfaces:
com.github.gbenroscience.math.graph.DrawingContextcom.github.gbenroscience.math.graph.AbstractViewand pass the instance to
com.github.gbenroscience.math.graph.GridSo you can use the same codebase to plot graphs on Android, JavaFX, Swing and other Java platforms. We have made the required implementations of DrawingContext(so called adapters) for the most popular Java platforms(Android, Swing and JavaFX) available in GRAPHING.md If you have more platforms in mind, we will be excited to have you contribute the code and make ParserNG even more versatile. Enjoy!
Fun fact: here are some interactions with ParserNG hosted on maven-central within Dec 2025 and Feb 11 2026: We had 970 total downloads from 193 unique sources across 82 companies See here
