Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add function sncs1cs to get accurate 1-cosine #44

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nsajko
Copy link

@nsajko nsajko commented Mar 23, 2020

Currently in three places in the code there is an expression like:
1-cosine(subexpr). The problem with that is that it sacrifices quite a
bit of precision the floating point type in use could provide. Because
of the subtraction, and the fact that floating point is MUCH denser near
zero than near one, 1-cosine(x) values that should be close to zero will
just be truncated to exactly zero.

The added function sncs1cs is not exported.

The changes apply only if the user has not specified a custom mfloat_t.

This improves mat3_rotation_axis, mat4_rotation_axis and
sine_ease_in_out. A side improvement in the former two is that the
computation of sine, cosine and 1-cosine should be cheaper when
computing them all at the same time than when calling a separate
function for each of the three (because the majority of the code is
shared between the three).

I checked that the improvements do materialize and, more importantly,
at the same time searched for big regressions:

https://github.com/nsajko/numericcompfricas (see the README.md)

Basically, the results are that there are no significant differences for
sin and cos (I think the accuracy only varies by one bit), but there are
big improvements for 1-cos (AKA omc AKA 1cs). The repository contains
the results of the check against glibc and against musl.

FriCAS (for the check) can be found here:
https://github.com/fricas/fricas

Currently in three places in the code there is an expression like:
1-cosine(subexpr). The problem with that is that it sacrifices quite a
bit of precision the floating point type in use could provide. Because
of the subtraction, and the fact that floating point is MUCH denser near
zero than near one, 1-cosine(x) values that should be close to zero will
just be truncated to exactly zero.

The added function sncs1cs is not exported.

The changes apply only if the user has not specified a custom mfloat_t.

This improves mat3_rotation_axis, mat4_rotation_axis and
sine_ease_in_out. A side improvement in the former two is that the
computation of sine, cosine and 1-cosine should be cheaper when
computing them all at the same time than when calling a separate
function for each of the three (because the majority of the code is
shared between the three).

I checked that the improvements do materialize and, more importantly,
at the same time searched for big regressions:

https://github.com/nsajko/numericcompfricas (see the README.md)

Basically, the results are that there are no significant differences for
sin and cos (I think the accuracy only varies by one bit), but there are
big improvements for 1-cos (AKA omc AKA 1cs). The repository contains
the results of the check against glibc and against musl.

FriCAS (for the check) can be found here:
https://github.com/fricas/fricas
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant