Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Tue, 20 Nov 2012 23:28:59 +0000 (UTC)
From: "Jeff Hain (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <1699808536.9882.1353454139777.JavaMail.jiratomcat@arcas>
In-Reply-To: <990881746.124608.1353085694194.JavaMail.jiratomcat@arcas>
Subject: [jira] [Comment Edited] (MATH-901) FastMath.sin is slow
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/MATH-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501578#comment-13501578 ] 

Jeff Hain edited comment on MATH-901 at 11/20/12 11:28 PM:
-----------------------------------------------------------

>What would be an acceptable loss of accuracy, opinions?

If the user doesn't need correct rounding and monotonicity
subtleties, I think an acceptable loss should be about
1e-15, i.e. about the precision of doubles, so that there
is not much visible loss for a few lucky computations.
In jodk, tan/exp/pow accuracy can be as bad as about 1e-12,
but that's for relatively large/small values, and that's fine
since the user is (or should be!) aware that he's using
something designed to be fast more than accurate.

>If we decide to do something like this, we should also
>add a specific page in the user guide, describing the
>differences with figures for performance and accuracy.
>Right now, FastMath is advertised as safe drop-in replacement
>to Math, but with two diverting implementations with different
>goals, users would need more guidance I guess.

For a drop-in replacement to be really safe, it needs to
behave exactly (except for speed) like the original, but
current FastMath claims to be more accurate so it can't be
one.

The JDK already has two Math classes (Math and StrictMath).
If you do a faster and safe drop-in replacement for one of these,
ideally you should try to get it into JDK since it's now open,
to avoid people ending up with too many implementations around
(I don't think it's worth it to have yet another class, just to
end up with similar accuracy and speed, especially for such low-level
features).
Some people at Sun/Oracle already thought about faster and
pure java implementations, see mails at
http://www.mail-archive.com/core-libs-dev@openjdk.java.net/msg03359.html

-Jeff

                
      was (Author: jeff):
    >What would be an acceptable loss of accuracy, opinions?

If the user doesn't need correct rounding and monotonicity
subtleties, I think an acceptable loss should be about
1e-15, i.e. about the precision of doubles, so that there
is not much visible loss for a few lucky computations.
In jodk, tan/exp/pow accuracy can be as bad as about 1e-12,
but that's for relatively large values, and that's fine
since the user is (or should be!) aware that he's using
something designed to be fast more than accurate.

>If we decide to do something like this, we should also
>add a specific page in the user guide, describing the
>differences with figures for performance and accuracy.
>Right now, FastMath is advertised as safe drop-in replacement
>to Math, but with two diverting implementations with different
>goals, users would need more guidance I guess.

For a drop-in replacement to be really safe, it needs to
behave exactly (except for speed) like the original, but
current FastMath claims to be more accurate so it can't be
one.

The JDK already has two Math classes (Math and StrictMath).
If you do a faster and safe drop-in replacement for one of these,
ideally you should try to get it into JDK since it's now open,
to avoid people ending up with too many implementations around
(I don't think it's worth it to have yet another class, just to
end up with similar accuracy and speed, especially for such low-level
features).
Some people at Sun/Oracle already thought about faster and
pure java implementations, see mails at
http://www.mail-archive.com/core-libs-dev@openjdk.java.net/msg03359.html

-Jeff

                  
> FastMath.sin is slow
> --------------------
>
>                 Key: MATH-901
>                 URL: https://issues.apache.org/jira/browse/MATH-901
>             Project: Commons Math
>          Issue Type: Sub-task
>    Affects Versions: 3.0
>         Environment: Mac OS 10.8.2, Java 7
>            Reporter: Konstantin Berlin
>         Attachments: SineTest.java
>
>
> The FastMath.sin (maybe other functions too) are not nearly as fast as some other libraries that can be found on the internet.
> The *much* faster code can be found here http://www.oliford.co.uk/phys/code/AlgorithmRepository/src/jafama/.
> Max Absolute Error Apache vs JDK: 1.1102230246251565E-16
> Max Absolute Error Alternative vs JDK: 5.551115123125783E-16
> JDK Time: 0.698
> Apache Time: 0.491
> Alternative Time: 0.18
> I will add my test code as soon as I figure out how.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira