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>
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>
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>
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>
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>
This reverts commit 7b93bae224.
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>
and
cid#1487033 UwF: Unwritten field
since...
commit 822f128e73
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>
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>
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>
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 ae855bf481
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>
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>
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>
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>
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>
