[
https://issues.apache.org/jira/browse/LUCENE-7194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15232021#comment-15232021
]
Dawid Weiss commented on LUCENE-7194:
-------------------------------------
That's what I'm saying -- I don't know! And seriously, I think it indeed misses
the point: if StrictMath does have this method and the reference (fdlibm)
doesn't have it then it should at least stick to identical implementation. I
would file a bug.
strictfp is another issue; in reality you won't be able to keep floating point
computations exact (unless you declare everything as strictfp) because of
processor-dependent truncations and roundings? I recall we did hit it once (a
long time ago) when we tested on sparcs, amds and intels in parallel -- we had
reference results of matrix computations (in high precision) and there was some
inaccuracies in tiny digits.
> Ban Math.toRadians/toDegrees and remove all usages of it
> --------------------------------------------------------
>
> Key: LUCENE-7194
> URL: https://issues.apache.org/jira/browse/LUCENE-7194
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> The result of these methods is unreliable and changes across jvm versions: we
> cannot use these methods.
> The following program prints 0.7722082215479366 on previous versions of java
> but 0.7722082215479367 on java 9 because Math.toRadians is no longer doing
> the same thing:
> {code}
> public class test {
> public static void main(String args[]) throws Exception {
> System.out.println(Math.toRadians(44.244272));
> }
> }
> {code}
> This is because of https://bugs.openjdk.java.net/browse/JDK-4477961.
> I am not really sure its a bug, because the method says that the conversion
> is "generally inexact".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
