SEARCH
NEW RPMS
DIRECTORIES
ABOUT
FAQ
VARIOUS
BLOG

 
 
Changelog for ojalgo-javadoc-55.0.0-1.9.noarch.rpm :

* Sun Oct 06 2024 shvetz.antonAATTgmail.com- Update to v55.0.0
* Changed ~ org.ojalgo.function + The BigDecimal valued constants in BigMath for E, PI and GOLDEN_RATIO are redefined with more decimal digits. + The BigDecimal valued functions in BigMath for EXP, LOG, SIN and COS are re-implemented to produce much more accurate results. ~ org.ojalgo.optimisation + The new LP solver implementation is now the default alternative. + The two classes LinearSolver.GeneralBuilder and LinearSolver.StandardBuilder are replaced by a common LinearSolver.Builder. Consequently the methods newGeneralBuilder() and newStandardBuilder() are deprecated and replaced by newBuilder(). ~ org.ojalgo.scalar + Re-implemented Quadruple\'s divide method using primitives only. (Previously delegated to BigDecimal.)
* Deprecated ~ org.ojalgo.data + Everything related to downloading (historical) financial data is deprecated. It\'s already broken (due to changes in the external \"service\") and we\'re not going to try fix it.
* Removed ~ org.ojalgo.structure + Removed a bunch of stuff that was deprecated in Factory1D, Factory2D and FactoryAnyD and/or some of their sub-interfaces.
* Thu Jun 13 2024 shvetz.antonAATTgmail.com- Update to v54.0.0
* Added ~ org.ojalgo.matrix + Added the ability to specify the initial capacity of a SparseStore. + More efficient sparse to sparse copying of SparseStore. + New option to use a builder when initially setting the elements of a SparseStore. + When setting (or adding to) elements there used to be internally synchronized code. This is no longer the case. Instead you must call synchronised() to get a synchronized mutating wrapper. This should make common single threaded usage faster. + The sparse BasicMatrix builder no longer has all the methods that really only made sense with dense implementation. The sparse builder implementation changed to use that new SparseStore.Builder. ~ org.ojalgo.structure + There are new methods fillCompatile(...), modifyCompatile(...) and onCompatile(...) to complement the already existing \"fill\", \"modify\" and \"on\" methods. (Inspired by MATLAB\'s concept of compatible array sizes for binary operation.) + The factory interfaces got methods to construct instances of compatible sizes/shapes. (Inspired by MATLAB\'s concept of compatible array sizes for binary operation.)
* Changed ~ org.ojalgo.matrix + The classes Primitive64Store and Primitive32Store have been renamed R064Store and R032Store. These classes are central to ojAlgo. The effect of this name change is widespread. ojAlgo has been transitioning to a new naming scheme over several versions now, but these classes were left untouched so far (in part because of how central they are). Now, to complete the work, it\'s done! No deprecations, just did it. Apart from the name change the classes are identical. + Vector space method like \"add\" and \"subtract\" have been redefined to no longer throw exceptions if dimensions are not equal, but instead broadcast/repeat rows or columns. (Inspired by MATLAB\'s concept of compatible array sizes for binary operation.) ~ org.ojalgo.optimisation + Refactored, cleaned up deprecations, primarily regarding how model variables are created. They can no longer be instantiated independent of a model. You have to first create the model, and then use that as the variable (and expression) factory. ~ org.ojalgo.structure + Refactored the builder/factory interfaces to better support creating immutable 1D, 2D or AnyD structures. This has implications for most ojAlgo data structures. There are deprecations in all factory classes, but everything that worked before still works (I believe). + The Structure
*D, Access
*D, Mutate
*D and Factory
*D interfaces have all been refactored to make working with int indices (rather than long) the primary alternative. Huge data structures, that require long indices, are still suported – no change in this regard. In reality only a few implementations actually allowed to create such large instances. This change is to allow all the other classes to be implemented using int and not bother (so much) with long. Users of the various classes in ojAlgo should see no difference. If you have created your own classes implementing some of ojAlgo\'s interfaces you will probably need to implement some additional methods in those classes.
* Fri May 24 2024 shvetz.antonAATTgmail.com- Update to v53.3.0
* Added ~ org.ojalgo.function + Some additional PowerOf2 utilities. ~ org.ojalgo.netio + SegmentedFile that divides a large file in segments to enable reading those in parallel using memory mapped files (memory mapped file segments). ~ org.ojalgo.type + New primitive number parsers in NumberDefinition. They take CharSequence rather than String as input and do not create any intermediate objects. In particular the parseDouble performs much better than its counterpart in Double. The downside is that it only handles a limited plain format.
* Changed ~ org.ojalgo.concurrent + The reduce(...) methods of ProcessingService are renamed (deprecated) reduceMergeable(...). In addition there are now also reduceCombineable(...). ~ org.ojalgo.data + The processMapped(...) method of BatchNode is renamed (deprecated) processMergeable(...). In addition there is now also processCombineable(...). + The reduceMapped(...) method of BatchNode is renamed (deprecated) reduceByMerging(...). In addition there is now also reduceByCombining(...). ~ org.ojalgo.type + The merge(Object) method of TwoStepMapper has been removed. Instead there are two new sub-interfaces TwoStepMapper.Mergeable and TwoStepMapper.Combineable.- Update to v53.2.0
* Added ~ org.ojalgo.data + There is a new package org.ojalgo.data.transform that (so far) contain implementations of the ZTransform and the DiscreteFourierTransform. Most notably ojAlgo now contains an implementation of the FFT algorithm. + ImageData has been extended with features to work with Fourier transforms of images, as well as a Gaussian blur function. ~ org.ojalgo.function + The PolynomialFunction interface now extends org.ojalgo.algebra.Ring which means it is now possible to add and multiply polynomials. There’s also been some refactoring of the internals of the polynomial implementations. + Two new PrimitiveFunction.Unary implementations PeriodicFunction and FourierSeries. It is now possible to take any (periodic) function and, via FFT, get a Fourier series approximation of it (1 method call). ~ org.ojalgo.scalar + Some minor additions to ComplexNumber. It is now possible to do complex number multiplication without creating new instances (calculate the real and imaginary parts separately). Added utilities to get the unit roots.
* Sat Jan 20 2024 shvetz.antonAATTgmail.com- Update to v53.1.1
* Added ~ org.ojalgo.data + New ImageData class that wraps a java.awt.image.BufferedImage and implements MatrixStore. Further it adds a few utility methods to simplify working with image data - convert to grey scale, re-sample (change size), separate the colour channels… ~ org.ojalgo.matrix + It is now possible to create a matrix decomposition instance and calculate the decomposition with 1 method call. Previously you had to first call make on the factory instance and then decompose on the decomposition instance. Now it is possible to call decomposed directly on the factory instance. + The SingularValue interface now defines a method to reconstruct a matrix using a specified number of singular values.
* Tue Sep 26 2023 shvetz.antonAATTgmail.com- Initial packaging with v52.0.1
 
ICM