| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Reviewed by: das
Approved by: das (mentor)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on i386-class hardware for sinl and cosl. The hand-rolled argument
reduction have been replaced by e_rem_pio2l() implementations. To
preserve history the following commands have been executed:
svn cp src/e_rem_pio2.c ld80/e_rem_pio2l.h
mv ${HOME}/bde/ld80/e_rem_pio2l.c ld80/e_rem_pio2l.h
svn cp src/e_rem_pio2.c ld128/e_rem_pio2l.h
mv ${HOME}/bde/ld128/e_rem_pio2l.c ld128/e_rem_pio2l.h
The ld80 version has been tested by bde, das, and kargl over the
last few years (bde, das) and few months (kargl). An older ld128
version was tested by das. The committed version has only been
compiled tested via 'make universe'.
Approved by: das (mentor)
Obtained from: bde
|
|
|
|
|
|
|
|
|
|
|
| |
with r219571 and re-enable building of cbrtl.
Implement the long double version for the cube root function, cbrtl.
The algorithm uses Newton's iterations with a crude estimate of the
cube root to converge to a result.
Reviewed by: bde
Approved by: das
|
|
|
|
|
|
|
|
| |
The algorithm uses Newton's iterations with a crude estimate of the
cube root to converge to a result.
Reviewed by: bde
Approved by: das
|
| |
|
| |
|
|
|
|
| |
Reviewed by: bde (earlier version)
|
|
|
|
|
|
| |
PR: bin/154928
Submitted by: Eitan Adler <lists at eitanadler.com>
MFC after: 3 days
|
|
|
|
|
|
|
| |
This bug results in a type mismatch that happens to be harmless
because of the way SET_FLOAT_WORD() works.
Submitted by: bde
|
|
|
|
|
|
|
| |
This bug results in a type mismatch that happens to be harmless
because of the way INSERT_WORDS() works.
Submitted by: bde
|
|
|
|
|
|
|
| |
e.g. cos(small) = 1, sin(small) = small. This commit tightens
the thresholds at which the simple approximations are used.
Reviewed by: bde
|
|
|
|
|
|
|
| |
This commit should have no effect on correctness; it merely changes the
threshold at which a simpler approximation can be used.
Reviewed by: bde
|
|
|
|
| |
doesn't promote the entire expression to double.
|
|
|
|
| |
Code changes verified with md5.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementing accurate logarithms in different bases. This is based
on an approach bde coded up years ago.
This function should always be inlined; it will be used in only a few
places, and rudimentary tests show a 40% performance improvement in
implementations of log2() and log10() on amd64.
The kernel takes a reduced argument x and returns the same polynomial
approximation as e_log.c, but omitting the low-order term. The low-order
term is much larger than the rest of the approximation, so the caller of
the kernel function can scale it to the appropriate base in extra precision
and obtain a much more accurate answer than by using log(x)/log(b).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Explanation by Steve:
jn[f](n,x) for certain ranges of x uses downward recursion to compute
the value of the function. The recursion sequence that is generated is
proportional to the actual desired value, so a normalization step is
taken. This normalization is j0[f](x) divided by the zeroth sequence
member. As Bruce notes, near the zeros of j0[f](x) the computed value
can have giga-ULP inaccuracy. I found for the 1st zero of j0f(x) only
the leading decimal digit is correct. The solution to the issue is
fairly straight forward. The zeros of j0(x) and j1(x) never coincide,
so as j0(x) approaches a zero, the normalization constant switches to
j1[f](x) divided by the 2nd sequence member. The expectation is that
j1[f](x) is a more accurately computed value.
PR: bin/144306
Submitted by: Steven G. Kargl <kargl@troutmask.apl.washington.edu>
Reviewed by: bde
MFC after: 7 days
|
|
|
|
|
|
|
|
|
|
|
| |
macro expand to __isnanf() instead of isnanf() for float arguments.
This change is needed because isnanf() isn't declared in strict POSIX
or C99 mode.
Compatibility note: Apps using isnan(float) that are compiled after
this change won't link against an older libm.
Reported by: Florian Forster <octo@verplant.org>
|
|
|
|
|
|
|
|
| |
The amd64-specific bits of msun use an undocumented constraint, which is
less likely to be supported by other compilers (such as Clang). Change
the code to use a more common machine constraint.
Obtained from: /projects/clangbsd/
|
|
|
|
|
| |
Because we use ISO C99 nowadays, we can just get rid of enforcing
GNU89-style inlining.
|
| |
|
| |
|
|
|
|
| |
defined at all. See also: defect report #223.
|
|
|
|
|
|
| |
of gcc, where the meaning of 'inline' was changed to match C99.
Noticed by: rdivacky
|
|
|
|
|
|
|
|
| |
should both be floats, not doubles.
PR: 127795
Submitted by: Christoph Mallon
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
| |
FPA floating-point format is identical to the VFP format,
but is always stored in big-endian.
Introduce _IEEE_WORD_ORDER to describe the byte-order of
the FP representation.
Obtained from: Juniper Networks, Inc
|
|
|
|
| |
Reported by: Intel C Compiler
|
|
|
|
|
|
|
| |
#pragma STDC CX_LIMITED_RANGE ON
the "ON" needs to be in caps. gcc doesn't understand this pragma
anyway and assumes it is always on in any case, but icc supports
it and cares about the case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
conj() instead of using expressions like z * I. The latter is bad for
several reasons:
1. It is implemented using arithmetic, which is unnecessary, and can
generate floating point exceptions, contrary to the requirements on
these functions.
2. gcc implements complex multiplication using a formula that breaks
down for infinities, e.g., it gives INFINITY * I == nan + inf I.
|
| |
|
|
|
|
|
|
|
| |
- Improve the order of some tests.
- Fix style.
Submitted by: bde
|
|
|
|
|
|
|
| |
- When y/x is huge, it's faster and more accurate to return pi/2
instead of pi - pi/2.
- There's no need for 3 lines of bit fiddling to compute -z.
- Fix a comment.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
at compile time regardless of the dynamic precision, and there's
no way to disable this misfeature at compile time. Hence, it's
impossible to generate the appropriate tables of constants for the
long double inverse trig functions in a straightforward way on i386;
this change hacks around the problem by encoding the underlying bits
in the table.
Note that these functions won't pass the regression test on i386,
even with the FPU set to extended precision, because the regression
test is similarly damaged by gcc. However, the tests all pass when
compiled with a modified version of gcc.
Reported by: bde
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Adjust several constants for float precision. Some thresholds
that were appropriate for double precision were never changed
when these routines were converted to float precision. This
has an impact on performance but not accuracy. (Submitted by bde.)
- Reduce the degrees of the polynomials used. A smaller degree
suffices for float precision.
- In asinf(), use double arithmetic in part of the calculation to
avoid a corner case and some complicated arithmetic involving a
division and some buggy constants. This improves performance and
accuracy.
Max error (ulps):
asinf acosf atanf
before 0.925 0.782 0.852
after 0.743 0.804 0.852
As bde points out, it's cheaper for asin*() and acos*() to use
polynomials instead of rational functions, but that's a task for
another day.
|
|
|
|
|
|
|
| |
and cargl().
Reviewed by: bde
sparc64 testing resources from: remko
|
| |
|
|
|
|
|
|
| |
spurious optimizations. gcc doesn't support FENV_ACCESS, so when it
folds constants, it assumes that the rounding mode is always the
default and floating point exceptions never matter.
|
|
|
|
| |
Document fmodl and fix some errors in the fmod manpage.
|
|
|
|
|
|
|
|
|
| |
- fma(x, y, z) returns z, not NaN, if z is infinite, x and y are finite,
x*y overflows, and x*y and z have opposite signs.
- fma(x, y, z) doesn't generate an overflow, underflow, or inexact exception
if z is NaN or infinite, as per IEEE 754R.
- If the rounding mode is set to FE_DOWNWARD, fma(1.0, 0.0, -0.0) is -0.0,
not +0.0.
|
| |
|
| |
|
|
|
|
| |
remquol() performs to compute the quotient is negligible.
|
| |
|
| |
|
| |
|
|
|
|
| |
as double.
|
|
|
|
| |
Submitted by: Steve Kargl <sgk@troutmask.apl.washington.edu>
|
|
|
|
| |
fixes for ld128 by me.
|
|
|
|
|
|
|
|
|
|
|
| |
This makes little difference in float precision, but in double
precision gives a speedup of about 30% on amd64 (A64 CPU) and i386
(A64). This depends on fabs[f]() being inline and efficient. The
bit fiddling (or any use of SET_HIGH_WORD(), which libm does too
much because it was best on old 32-bit machines) always causes
packing overheads and sometimes causes stalls in the packing, since
it operates on only part of a variable in the double precision case.
It apparently did cause stalls in a critical path here.
|