summaryrefslogtreecommitdiff
path: root/nlpsolver
AgeCommit message (Collapse)AuthorFilesLines
2024-04-29Double values comparison changed to compare method.Todor Balabanov1-4/+4
Using the Double.compare() method is often preferred over the == comparison operator for comparing double values due to several reasons: Handling NaN (Not-a-Number) values: The Double.compare() method correctly handles NaN values, while the == operator does not. If either of the operands is NaN, the == operator will always return false, regardless of the other operand. In contrast, Double.compare() will correctly evaluate NaN values according to the IEEE 754 floating-point standard. Handling positive and negative zero: The == operator treats positive zero and negative zero as equal, whereas they are distinct values in IEEE 754 floating-point representation. Double.compare() correctly distinguishes between positive and negative zero. Robustness against rounding errors: Floating-point arithmetic can introduce rounding errors, causing two double values that should be equal to differ slightly. Directly comparing them with the == operator might yield unexpected results due to these small differences. Double.compare() allows you to define a tolerance level if necessary, providing more control over how equality is determined. Consistent behavior: The behavior of Double.compare() is consistent and predictable across different platforms and JVM implementations, as it follows the IEEE 754 standard. On the other hand, the behavior of the == operator might vary depending on the platform and compiler optimizations. Suitability for sorting: Double.compare() returns an integer value that can be directly used for sorting double values in ascending or descending order. This makes it convenient for sorting arrays or collections of double values. Overall, while the == operator might work in some cases, using Double.compare() provides more robust and predictable behavior, especially when dealing with floating-point numbers in Java. Change-Id: I5756936a0d2b4fe11b9113ddd33b6ae691f5103f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166796 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2022-12-19Fix title for nlpsolver/README.mdHossein1-1/+1
The nlpsolver module is "Solver for Nonlinear Programming", which was mistakenly called "New Linear Programming", and this is now fixed. The change will appear within a week in: https://docs.libreoffice.org/nlpsolver.html Change-Id: I05b14d1e4056d8d0797728905886edef867f29e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144408 Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2022-07-05Related tdf#137145 tdf#137569 Capitalization + punctuation fixesAdolfo Jayme Barrientos1-1/+1
Change-Id: Icd8a631da83c86333c7e5bcee0069165899d3041 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136822 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-08-06cid#1489772 UR: Uninitialized read of field in constructorCaolán McNamara3-13/+6
pass in SearchPoint to initialize pbest_t before it is then passed to setMemPoints setMemPoints sets the pbest_t variable of AbsGTBehavior so calling setPbest on AbsGTBehavior subclasses after calling that doesn't do anything so drop it, and then DEPSAgent.setPbest isn't needed anymore Change-Id: Id4fdc770cefc0f801218dc9bf51a6dc5b1e25d5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120115 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-02The null pointer bug should be fixed now.Todor Balabanov5-27/+24
Change-Id: I8278bfed8170907a958396839d0997fc127f4b2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119744 Tested-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-19AbsGTBehavior should implement ILibEngineJulien Nabet2-3/+3
so we're sure all derivatives will have to Change-Id: I4e62d02f01382dbc95b28ffcb3d278aa31427f85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119145 Tested-by: Jenkins Reviewed-by: Todor Balabanov <todor.balabanov@gmail.com> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-07-18nlpsolver: DEPSAgent doesn't implement ILibEngineJulien Nabet1-1/+1
Fix this error: /home/julien/lo/libreoffice/nlpsolver/ThirdParty/EvolutionarySolver/src/net/adaptivebox/deps/DEPSAgent.java:45: error: DEPSAgent is not abstract and does not override abstract method setLibrary(Library) in ILibEngine public class DEPSAgent implements ILibEngine { ^ 1 error (on pc Debian testing x86-64 with master sources updated today openjdk 11.0.11 2021-04-20 OpenJDK Runtime Environment (build 11.0.11+9-post-Debian-1) OpenJDK 64-Bit Server VM (build 11.0.11+9-post-Debian-1, mixed mode, sharing) ) Change-Id: I1ce2d1a9ddee1020889f1a7a8fcd3387980b241f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119119 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-07-18Revert "Some lower objects coupling."Noel Grandin2-14/+23
This reverts commit 7b93bae224c7c2c49b105ef97304bb46f8b68da5. Reason for revert: Does not compile /home/tdf/lode/jenkins/workspace/lo_ubsan/nlpsolver/ThirdParty/EvolutionarySolver/src/net/adaptivebox/deps/DEPSAgent.java:45: error: DEPSAgent is not abstract and does not override abstract method setLibrary(Library) in ILibEngine public class DEPSAgent implements ILibEngine { ^ 1 error Change-Id: I72f2a22ab1f4119178f8002c21ba0845c4cd1bdf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119040 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-17Some lower objects coupling.Todor Balabanov2-23/+14
Change-Id: I0a7c658d830f82d627d20b9ed7000f3c5b8f1f89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119105 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-13Object initialization is done via a constructor with parameters.Todor Balabanov2-22/+19
Change-Id: I66e87f7c898efb1f2c6b1d31fbd5654244e3ea82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118785 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-12cid#1487032 NP: Null pointer dereferenceCaolán McNamara1-0/+11
and cid#1487033 UwF: Unwritten field since... commit 822f128e734f37ee4de9bf5b62640cbec140701e Date: Wed Jul 7 16:01:19 2021 +0300 Polymorphism is a better approach when there are chains of inheritance. where deGTBehavior and psGTBehavior are no longer stored when set from DEPSSolverImpl.java:146 and DEPSSolverImpl.java:147 Change-Id: If3d228bf6e5f2b1ddd119d75b55bd778bcce8b05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118759 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-07-08Polymorphism is a better approach when there are chains of inheritance.Todor Balabanov4-12/+8
Change-Id: I2580dafcf8792bf4b11db78988db8c2976e4545c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118569 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-06-21Global optimization metaheuristics sometimes are sensitive to the quality of ↵Todor Balabanov2-0/+6
the random numbers. Change-Id: Ibc1e95736c5f9355e67f2129a7804064e329da89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117510 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-20It is a good practice single source of random numbers to be used.Todor Balabanov4-6/+32
Change-Id: If76e247461288a9ed938b4f6cb592c814b8bbe2b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117406 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-06-17A separate function for getting a random search point is a little bit clearer.Todor Balabanov2-1/+5
Change-Id: I2d7471440cdee096b09ce704cbea3d5311f984c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117289 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-15Fewer array reference calls make the code more readable and more efficient.Todor Balabanov1-16/+24
Change-Id: I7416633a735078a4e0e857f050ea7bfaadba310c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117158 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Jenkins
2021-05-03clean up some Java warningsNoel Grandin1-0/+1
Change-Id: Id54e8fd6803c3a6c0d924338d1781679ed0b1bfd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115025 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein1-3/+6
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein1-0/+0
Renaming all README files for all top level modules to README.md, applying no content change at this stage to be able to track history of the files. These files should be edited to use correct Markdown syntax later. Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-09-25value and targetValue cannot be null at this pointNoel Grandin1-8/+6
Change-Id: I175da8a170fcddca083ed47b41c7241433e54db0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103383 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-28Related tdf#135211: return early if no dataJulien Nabet3-0/+13
With DEPS or SCO Evolutionary algorithms, it'll return "No solution found." Change-Id: I15e8e24eb519a20e3f3645b79e990949f648fbd2 Change-Id: I7321419ccc1cd00d75f03fa86d3c0cb4bf9ad473 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99584 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-07-28Typo: Swam->SwarmJulien Nabet1-1/+1
Change-Id: I99dbe7fa6d49e0663c3551d2e3dabd3f42d8d3c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99578 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2020-05-06Move all public Java classes to libreoffice.jarSamuel Mehrbrodt1-2/+1
This moves the classes from juh.jar and ridl.jar to libreoffice.jar The goal is to have one single jar (and Java module, will be added later) which developers can include to work with LO. juh.jar and ridl.jar are kept as basically empty jars with libreoffice.jar on its classpath to keep backwards compatibility. This is a continuation of ae855bf48163ff64d94cfc34aff8e37abdb5518d and a preparation to have Java 9 module support. Change-Id: Ifbbfb97f60373d14256e62ae3122913bd17d5bbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91930 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-04tdf#117331 Merge jurt and unoil into ridlSamuel Mehrbrodt1-2/+0
jurt.jar and unoil.jar are kept as effectively empty jars, each with a Class-Path: ridl.jar in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or without also loading ridl.jar) will still have access to their content. Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi) are not part of the URE, but are now made available by URE's ridl.jar. This should probably not cause problems in practice. At least for now, we seal exactly those packages in ridl.jar that were originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now, but that would be mildly incompatible, as it would prevent 3rd-party code from introducing additional UNOIDL entities in the relevant namespaces (even if that is something we do not want 3rd-party code to do anyway). However, some JunitTest_jurt_* define classes in those sealed packages. In the past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt. Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets leave that for a follow-up clean up.) As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/. Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a Co-authored-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-06Fixing '....'Andrea Gelmini1-1/+1
Change-Id: Icf2a34500acc18b28f113c85366bf24edc6d20b9 Reviewed-on: https://gerrit.libreoffice.org/78695 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-07-27Fix typosAndrea Gelmini1-1/+1
Change-Id: I380856ca45c835e732fdf080a522caab4534db5b Reviewed-on: https://gerrit.libreoffice.org/76346 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-06-03Checking of min and max factor value was added.Todor Balabanov1-2/+2
It is possible user to swap these two values. Change-Id: Ib375d705e42f7257aa9b16d72ab834020e401cde Reviewed-on: https://gerrit.libreoffice.org/72483 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2019-06-03Range for DE scaling factor was implemented.Todor Balabanov3-6/+13
Change-Id: I5b8d3cd69a6138d7eebf37c299626019b32d639a Reviewed-on: https://gerrit.libreoffice.org/72373 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2019-05-17Some additional manual formatting.Todor Balabanov13-55/+74
Change-Id: Ie5590535d013aa2f747dd034fa2fcd2ae5c3956b Reviewed-on: https://gerrit.libreoffice.org/72226 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-05-13nlpsolver: This is considered internal codeSamuel Mehrbrodt1-0/+3
Change-Id: Icd8566c2fce1a0ff3fb9471afd71858ec2f91bc5 Reviewed-on: https://gerrit.libreoffice.org/71982 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-05-12Formatting - Eclipse IDE Java Conventions with spaces for indentation.Todor Balabanov21-275/+254
Change-Id: I0c3e50ef25bda0bc4ae59665a07848fe75507121 Reviewed-on: https://gerrit.libreoffice.org/72185 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2019-05-12Generate behavior code simplification and very small speed-up.Todor Balabanov1-13/+48
Change-Id: Ib13080e4c21738affa129d12a07f5380f665e7a4 Reviewed-on: https://gerrit.libreoffice.org/71673 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2019-05-10Import of each class is better practice than import of entire library.Todor Balabanov11-45/+50
Change-Id: I13c4916b951d36ea5e83e52c9c6e36df552bdfeb Reviewed-on: https://gerrit.libreoffice.org/71961 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-05-01Fisher-Yates shuffling algorithm achieves much better randomization.Todor Balabanov1-27/+19
Change-Id: I6d204a7ba0fa19f4c318d1c70f5a0344e0640d6d Reviewed-on: https://gerrit.libreoffice.org/71620 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-05-01Random class is better than Math random function.Todor Balabanov1-3/+8
Change-Id: Ia35e3bb3b4f0323c7fbfc54ae5064afdf2c3f381 Reviewed-on: https://gerrit.libreoffice.org/71539 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-05-01Math pow is too slow in this case.Todor Balabanov1-1/+1
Change-Id: I16149cabf75ec928d96975e4b98622df6951cefc Reviewed-on: https://gerrit.libreoffice.org/71519 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-06-26tdf#43388: add missing info for Evolutionary Algorithm SolverJulien Nabet1-0/+6
Add SolverConstraintOperator.INTEGER_value case and in the same time the also missing SolverConstraintOperator.BINARY_value case Change-Id: I18b826e74a2381dedaea3090919118b8d5dad072 Reviewed-on: https://gerrit.libreoffice.org/56359 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-01-27Fix typosAndrea Gelmini1-2/+2
Change-Id: I8d5a8251a01af7cdf9832d98d8a6573b907f8532 Reviewed-on: https://gerrit.libreoffice.org/48683 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jens Carl <j.carl43@gmx.de>
2017-02-03TyposJulien Nabet1-1/+1
Change-Id: Ic54695e86b4b462419fa7d5ded7b1ddb19ee8ed5 Reviewed-on: https://gerrit.libreoffice.org/33904 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2016-12-12tdf#104268 NLPSolver: Improve display of solutionLaurent Balland-Poirier1-1/+1
Format "%.2f" is not optimal for large or small values. Format "%g" should be prefered. Change-Id: I92899d80564b9000b1f3e049221c456f8e1176a9 Reviewed-on: https://gerrit.libreoffice.org/31445 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-11-06tdf#103622 do not use arrow as separator of menu commandsStanislav Horacek1-1/+1
Change-Id: I15f1cb699107dc7e24d6ebef2e8f4d8f38dcd596 Reviewed-on: https://gerrit.libreoffice.org/30573 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2016-01-21coverity#1326449 Dereference null return valueCaolán McNamara1-12/+8
and coverity#1326448 Dereference null return value Change-Id: I8e26c9c57264b654a5a7c3dc56c658f23291e357
2016-01-10Fix typosAndrea Gelmini1-2/+2
Change-Id: I9a5940027423ff0791fa7da0b79b617412ce6b86 Reviewed-on: https://gerrit.libreoffice.org/21209 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
2015-11-04coverity#1327027 SIC: Inner class could be made staticCaolán McNamara1-1/+1
Change-Id: I9c36aa362e58de724c63b9d23334eabfc973ee42
2015-10-21More plausible fixStephan Bergmann1-2/+4
...for 7c465e7f9e8b5c34a4926fb0de84de70aee8f37d "coverity#1326260 Explicit null dereferenced" Change-Id: I3b7fb8195c29b7e447fbe31f823cd00d7a820e95
2015-10-15coverity#1326260 Explicit null dereferencedCaolán McNamara1-1/+1
Change-Id: I75b9cb661a7a45304bf32395ad980f83621f4612
2015-10-15cid#1327023 to cid#1327077 SIC: Inner class could be made staticNoel Grandin2-2/+2
Change-Id: I41f89c4feefe4e012d72c663ebb9bbcb4aa7f163
2015-10-14cid#1326608,cid#1326609 CN: Bad implementation of cloneable idiomNoel Grandin1-1/+1
Change-Id: Iac74be96b47720ab105f862e7d1a69f909214294
2015-10-01Fix typosAndrea Gelmini1-1/+1
Change-Id: I4452d4a4a4a61f39cd9c2b5a441c6c2017f15ce8 Reviewed-on: https://gerrit.libreoffice.org/19073 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2015-10-01Fix typosAndrea Gelmini3-3/+3
Change-Id: I04d1bc3a9f38ff7871d3192563cd1f649fdc6cea Reviewed-on: https://gerrit.libreoffice.org/18960 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-22 09:17:52 +0000