# Floating-point accuracy visualization example: the ULP error for each math function coming with Julia
**URL:** https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392
**Category:** Numerics
**Tags:** error, visualization, numerics, approximation, accuracy
**Created:** [February 1, 2026, 9:02pm UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392 "2026-02-01T21:02:59Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [February 1, 2026, 9:02pm UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/1 "2026-02-01T21:02:59Z")
## Introduction
The implementation of a math function, such as `cos(::Float64)` in Julia, should be fast, but also needs to be at least somewhat accurate. Here I propose a method for visualizing empirical accuracy data.
Consider the discrepancy between the exact value of a univariate real function, such as the sine, and the approximate value that is returned by a call such as `sin(0.3)`. By putting an interval that subsets the domain of the function on the x-axis of a plot, and the value of this discrepancy, the _error_, onto the y-axis of the same plot, it might be possible to tell on which part of the function’s domain is the implementation less accurate than on other parts. That is, it might be possible to read off the plot the worst-case regions for the approximation.
I choose the error measured in _units in the last place_/_units of least precision_ (ULPs) as the type of error to visualize here. Other types of error that are often used are _absolute error_, which is not usually appropriate for floating-point numbers, and _relative error_, which has these drawbacks to measuring the error in ULPs:
- it is usually less immediately useful and less intuitive
- plotting software tends to have trouble with the tiny values
One advantage of the error in ULPs is that it has some convenient and easy interpretations in the context of floating-point numbers. For example:
- If the error between the exact value and the approximate (floating-point) value is less than **half** , the approximate value is the number closest to the exact value among the numbers belonging to that floating-point representation. The technical term is _correctly rounded_.
- If the error is merely less than **one** , the approximate value is one of the two floating-point numbers closest to the exact value. The technical term is _faithfully rounded_ (although faithful rounding is not technically a rounding).
If we tried to, say, evaluate the error in ULPs on an evenly-spaced grid on the chosen interval, the plot would just look like noise if each evaluation was plotted as a data point. However, given that the worst cases are what is most interesting, it might be possible to achieve a comprehensible visualization by giving up on visualizing the best cases. In other words, we’re interested in the upward spikes of the error, and by eliding the downward spikes it might be possible to make the plot a lot less noisy.
To accomplish this, the approach I choose here is vaguely similar to downsampling/decimation, from signal analysis: take n values, where n is some large positive integer, and represent them on the plot by an aggregate value: the maximum value among the n points (in this case). In a signal analysis context, it is also common to apply a _lowpass filter_ to reduce noise/high-frequency components of the signal, before the decimation itself. This helps prevent artifacts in the resulting output. In this case, a _sliding window maximum_ seems like an appropriate lowpass filter to smooth out the data before decimation, to prevent artifacts.
## Julia app on Github
The app used for creating these visualizations is published on Github:
- [GitHub - JuliaMath/VisualizeULPError.jl: Visualize the numerical error of a real univariate function](https://github.com/JuliaMath/VisualizeULPError.jl)
Neither the package, nor the app it exposes, are registered as of writing this.
## The plots
Might be useful to both contributors and users of Julia to better understand where there’s room for improvement in the current implementations. In the cases of some functions, though, the worst case error spikes are difficult or impossible to fix efficiently, without reaching for some arbitrary-precision implementation like MPFR (`BigFloat`) or Arb.
### `acos(::Float64)`
### `acosd(::Float64)`
### `acosh(::Float64)`
### `acot(::Float64)`
### `acotd(::Float64)`
### `acoth(::Float64)`
### `acsc(::Float64)`
### `acscd(::Float64)`
### `acsch(::Float64)`
### `asec(::Float64)`
### `asecd(::Float64)`
### `asech(::Float64)`
### `asin(::Float64)`
### `asind(::Float64)`
### `asinh(::Float64)`
### `atan(::Float64)`
### `atand(::Float64)`
### `atanh(::Float64)`
### `cos(::Float64)`
### `cosc(::Float64)`
### `cosd(::Float64)`
### `cosh(::Float64)`
### `cospi(::Float64)`
### `cot(::Float64)`
### `cotd(::Float64)`
### `coth(::Float64)`
### `csc(::Float64)`
### `cscd(::Float64)`
### `csch(::Float64)`
### `deg2rad(::Float64)`
### `exp(::Float64)`
### `exp10(::Float64)`
### `exp2(::Float64)`
### `expm1(::Float64)`
### `log(::Float64)`
### `log10(::Float64)`
### `log1p(::Float64)`
### `log2(::Float64)`
### `rad2deg(::Float64)`
### `sec(::Float64)`
### `secd(::Float64)`
### `sech(::Float64)`
### `sin(::Float64)`
### `sinc(::Float64)`
### `sind(::Float64)`
### `sinh(::Float64)`
### `sinpi(::Float64)`
### `tan(::Float64)`
### `tand(::Float64)`
### `tanh(::Float64)`
### `tanpi(::Float64)`
## Miscellaneous
### PRs featuring this visualization approach
- Julia itself
- Julia package **LogExpFunctions.jl**
### Version, platform info
```julia-repl
julia> versioninfo()
Julia Version 1.14.0-DEV.1670
Commit 6e64d0c3442 (2026-02-02 03:21 UTC)
Build Info:
Official https://julialang.org release
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU: 8 × AMD Ryzen 3 5300U with Radeon Graphics
WORD_SIZE: 64
LLVM: libLLVM-20.1.8 (ORCJIT, znver2)
GC: Built with stock GC
Threads: 5 default, 1 interactive, 5 GC (on 8 virtual cores)
```
---
### Author:  [@jebej](https://discourse.julialang.org/u/jebej)
#### Post date: [February 1, 2026, 11:54pm UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/2 "2026-02-01T23:54:59Z")
Nice! But the plots are hard to see due to the low contrast, low resolution and small text, if it’s not too much trouble, I’m sure an svg (or higher res) version with better sizing and colors would be appreciated!
---
### Author:  [@OlivierHnt](https://discourse.julialang.org/u/OlivierHnt)
#### Post date: [February 2, 2026, 1:36am UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/4 "2026-02-02T01:36:06Z")
Interesting, thank you for sharing.
We recently had a conversation about ULPs over at [IntervalArithmetic](https://github.com/JuliaIntervals/IntervalArithmetic.jl).
We used to have a rounding mode based on `prevfloat`/`nextfloat` (fast, not tight, but GPU compatible), though we ultimately pulled the plug because determining the ULPs turned out to be tricky and architecture-dependent.
I am not an export on this subject, though Julia itself provides implementations of some functions:
1. Where can we find the list of implemented functions?
2. For these functions, this means that the ULP is architecture independent, correct?
3. Do any of these implementations provide proven bounds on the ULP error?
I would not expect _correct rounding_ in general, but even a pessimistic, certified upper bound on the ULP would already be very useful for our purposes.
Maybe one day we can even get an implementation of [CORE-Math](https://core-math.gitlabpages.inria.fr) functions.
---
### Author:  [@PatrickHaecker](https://discourse.julialang.org/u/PatrickHaecker)
#### Post date: [February 3, 2026, 4:56am UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/5 "2026-02-03T04:56:16Z")
This sounds interesting. Am I the only one who can’t see the plots? I only see an “X” below each function name and I thought “X” never, ever marks the spot.
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [February 3, 2026, 7:30am UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/6 "2026-02-03T07:30:02Z")
> [@PatrickHaecker](#):
>
> Am I the only one who can’t see the plots?
Yeah, the post is ~~not done yet~~ 😅
For context, this was originally a blog post on the Julia Forem. However Forem does not accept SVG, so I provided the plots as PNG. However, Forem downscaled all the images, which is something I only realized after publishing the Forem post and linking to it from here. Since then I got sidetracked by a possible Julia bug, so I haven’t gotten around to regenerating the plots.
EDIT: the post is finished now, excuse the confusion.
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [February 3, 2026, 4:39pm UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/7 "2026-02-03T16:39:51Z")
> [@jebej](#):
>
> But the plots are hard to see due to the low contrast, low resolution and small text, if it’s not too much trouble, I’m sure an svg (or higher res) version with better sizing and colors would be appreciated!
The images are now in SVG. Hope it is OK now. Could also have titled the plots and labeled the axes, now that I think about it 🤷♂️
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [February 3, 2026, 4:52pm UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/8 "2026-02-03T16:52:18Z")
> [@OlivierHnt](#):
>
> determining the ULPs turned out to be tricky and architecture-dependent.
Can you link some relevant discussion? I’m not completely sure what you are referring to.
A possible explanation is how the result of `muladd(::Float64, ::Float64, ::Float64)` is architecture-dependent, because modern platforms have a fused multiply-add (FMA) instruction, so `muladd` may be implemented with `fma`, but on older architectures `muladd` may suffer from double rounding.
> [@OlivierHnt](#):
>
> Where can we find the list of implemented functions?
The docs: [Mathematics · The Julia Language](https://docs.julialang.org/en/v1/base/math/)
> [@OlivierHnt](#):
>
> For these functions, this means that the ULP is architecture independent, correct?
Are you asking about the approximation error? If so, yeah, as mentioned just now above. An arch that lacks FMA may suffer from worse accuracy, but modern platforms do have an FMA. The Julia test suite adapts like this:
>
If you’re, on the other hand, just asking about how to calculate the ULP error between `a` and `b`, the formula is basically `(b - a) / eps(a)`. See the entire implementation here:
[https://github.com/nsajko/VisualizeULPError.jl/blob/368d4291b0fa37241e3af1c7b340ee6f9dbf7e37/src/ULPError.jl](https://github.com/nsajko/VisualizeULPError.jl/blob/368d4291b0fa37241e3af1c7b340ee6f9dbf7e37/src/ULPError.jl)
> [@OlivierHnt](#):
>
> Do any of these implementations provide proven bounds on the ULP error?
Pretty sure the answer is no.
---
### Author:  [@GeorgeGkountouras](https://discourse.julialang.org/u/GeorgeGkountouras)
#### Post date: [February 3, 2026, 7:53pm UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/9 "2026-02-03T19:53:30Z")
Cool! Does it work for arbitrary Julia code e.g. `my_cos()` ? What about C functions?
---
### Author:  [@woclass](https://discourse.julialang.org/u/woclass)
#### Post date: [February 4, 2026, 4:58am UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/10 "2026-02-04T04:58:21Z")
I did some similar things for Bessels.jl, but just use relative error.
[Relative error plot for Besseli(nu, x) · JuliaMath/Bessels.jl · Discussion #126](https://github.com/JuliaMath/Bessels.jl/discussions/126)
---
### Author:  [@OlivierHnt](https://discourse.julialang.org/u/OlivierHnt)
#### Post date: [February 4, 2026, 6:42am UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/11 "2026-02-04T06:42:16Z")
Thx! Huh so all of these listed functions are implemented in pure Julia.
I was thinking of how, e.g., the gnu lib is architecture dependent.
So the only safe cases are the functions which are part of the IEEE 754. Anything beyond this, I suppose, would have to be a separate Julia package.
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [February 4, 2026, 6:52am UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/12 "2026-02-04T06:52:55Z")
> [@GeorgeGkountouras](#):
>
> Cool!
Thank you!
> [@GeorgeGkountouras](#):
>
> Does it work for arbitrary Julia code e.g. `my_cos()` ?
Sure, just define the function inline when calling the app. I had to make slight adjustments (`invokelatest`) to make that work. The readme on Github now includes the following example:
> To measure the error of an arbitrary function, define it when providing the command options:
>
> ```sh
> visualize_ulp_error plot 'let sin_fast
> function sin_fast(x::BigFloat) # accurate reference
> sin(x)
> end
> function sin_fast(x::Float64) # fast approximation of `sin(x)` for `abs(x) ≤ 0.125`
> # Found with Sollya, using this command: `fpminimax(sin(x), [|1, 3, 5|], [|D...|], [0; 0.125]);`.
> p = (0.9999999999763268, -0.16666663941291426, 0.008328683245851542)
> x * evalpoly(x * x, p) # odd polynomial composed from simpler polynomials
> end
> (;
> parent_dir = "/home/nsajko/ulp_error_plots",
> downsampled_length = 650,
> factor = 6000,
> window_size = 10,
> bf_precision = 140,
> no_scoped_values = true,
> width = 1100px,
> height = 500px,
> func = sin_fast,
> itv = (-0.125, 0.125),
> )
> end'
>
> ```
The result:
A catch is that a Julia app can not(?) load more Julia packages. So, if you want to measure the error of a function defined in some package, you would need to either:
- Redefine the function inline when calling the app, without referring to any package.
- Use the package directly from the REPL, instead of using the Julia app. There is no supported [API](https://github.com/JuliaMath/VisualizeULPError.jl/issues/13) yet, but if you just want to hack around, something like this works at the moment:
> [@GeorgeGkountouras](#):
>
> What about C functions?
I suppose one could wrap a C function using `@ccall`.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [February 4, 2026, 7:36am UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/13 "2026-02-04T07:36:22Z")
The 10^6 error for `asech(1.0)` looks bogus.
It would be better to make the plots
1. black, or at least dark blue,
2. with a larger axis labelling,
3. using thicker lines.
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [February 4, 2026, 9:31am UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/14 "2026-02-04T09:31:26Z")
> [@Tamas\_Papp](#):
>
> The 10^6 error for `asech(1.0)` looks bogus.
I doubt that. In general, the error may be underestimated, but I can’t think of how it could be overestimated. A closeup, with parameters chosen to disable all smart functionality, showing the error for the rightmost hundred `Float64` numbers in the domain of `asech`:
```sh
visualize_ulp_error -t5 -- plot '(;
parent_dir = "/home/nsajko/ulp_error_plots",
downsampled_length = 1000, # this is excessive but there is no harm in that
factor = 1, # disable downsampling
window_size = 1, # disable smoothing
bf_precision = 300, # extra high precision, just to be safe
no_scoped_values = true,
width = 500px,
height = 300px,
func = asech,
itv = (prevfloat(1.0, 99), 1.0), # only consider the last hundred `Float64` numbers in the domain of `asech`
)'
```
Plot:
Reading off the plot: the error alternates between huge and small for successive floating-point numbers at the right edge of the domain. Adding this as a usage example to the readme.
Indeed, it is easy to check this in the REPL starting from first principles:
```julia-repl
julia> const asech_accurate = Float64 ∘ asech ∘ big
Float64 ∘ asech ∘ big
julia> f(x) = (asech_accurate(x), asech(x))
f (generic function with 1 method)
julia> ulp_err(a, b) = abs(b - a)/eps(a) # simplified definition, does not handle edge cases
ulp_err (generic function with 1 method)
julia> x = 1.0
1.0
julia> y = f(x)
(0.0, 0.0)
julia> x = prevfloat(x)
0.9999999999999999
julia> y = f(x)
(1.4901161193847656e-8, 2.1073424255447017e-8)
julia> ulp_err(y...)
1.865452045155277e15
```
> [@Tamas\_Papp](#):
>
> It would be better to make the plots
>
> 1. black, or at least dark blue,
> 2. with a larger axis labelling,
> 3. using thicker lines.
Thank you. I intend to fix these issues without getting bogged down in such details of the presentation, by exporting the final data as Vega-friendly JSON, and/or relying on Vega.jl or Deneb.jl. Then the ecosystems around Vega should offer sane defaults for things like coloring, labeling, sizing, interactive zooming, etc. Issue: [JSON export? Vega export? Use Vega.jl? Use Deneb.jl? · Issue #7 · JuliaMath/VisualizeULPError.jl · GitHub](https://github.com/JuliaMath/VisualizeULPError.jl/issues/7)
---
### Author:  [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)
#### Post date: [February 4, 2026, 10:18am UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/15 "2026-02-04T10:18:45Z")
The large error for asech comes from `x->(inv(x)-1)`.
But I don’t think this really matters? People who call `asech`/`acosh` for values close to the singularity at `1` deserve what they get, same as people who call `log` for values close to `1`.
This is a good indication that we’re missing an `acosh1p` / `asech1m` in Base/stdlib though, analogue to `log1p`. (we could also consider `inv1p`)
PS. The fix would be to implement `acosh1p` and `inv1p` and then use `asech(x)=acosh1p(inv1p)` for values close to 1.
An more relaxed definition of relative error would be: `err(f_approx, f, x) = abs(f(x)-f_approx(x)) / max(eps(x), eps(f(x)))`. I would call this the “garbage in, garbage out” principle.
---
### Author:  [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)
#### Post date: [February 4, 2026, 12:08pm UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/16 "2026-02-04T12:08:47Z")
I don’t think users of `asech` deserve any worse than users of `acos`. As it happens `acos` gives a more accurate result for asech than the current Float64 `asech` implementation itself does for 0.999999991838298 \< x \< 1.
---
### Author:  [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)
#### Post date: [February 4, 2026, 12:41pm UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/17 "2026-02-04T12:41:47Z")
Fair enough. Then we should add `invm1(t) = inv(t) - one(typeof(t))` to Base, with appropriate specializations for floating point (probably use geometric series when t is close to 1, but magic float tricks are not my forte), and use it internally where appropriate. And then we also need to add `acosh1p` to Base (such that `asech(t) = acosh1p(invm1(t))` close to 1). And then there is no good reason not to have `asech1m` as well.
---
### Author:  [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)
#### Post date: [February 4, 2026, 2:38pm UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/18 "2026-02-04T14:38:14Z")
Or we could implement `asech` analogously to `acosh`, e.g. something like
```julia-auto
@noinline asech_domain_error(x) = throw(DomainError(x, "asech(x) is only defined for 0 ≤ x ≤ 1."))
function new_asech(x::T) where T <: Union{Float32, Float64}
isnan(x) && return x
if x < T(0) || x > T(1)
return asech_domain_error(x)
elseif x == T(1)
return T(0)
elseif x > T(0.5)
t = T(1) - x
return log1p((t + sqrt(T(2) * t - t * t)) / x)
elseif x > T(0.5)^28
y = 1 / x
t = y * y
return log(T(2) * y - 1 / (y + sqrt(t - T(1))))
else
return -log(x) + Base.Math.AH_LN2(T)
end
end
```
As a bonus we get a better domain error and reasonable results for denormalized input.
Plot doesn’t look amazing but vastly better than today:
---
### Author:  [@mikmoore](https://discourse.julialang.org/u/mikmoore)
#### Post date: [February 4, 2026, 4:17pm UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/19 "2026-02-04T16:17:25Z")
For (some) specific functions or limits of functions in certain ballparks, [Herbie](https://herbie.uwplse.org/demo/) can be a neat little tool for considering alternative implementations.
* * *
> [@foobar\_lv2](#):
>
> invm1(t) = inv(t) - one(typeof(t))
I don’t think this specific function actually needs a special implementation? For t \approx 0 the result is large and pretty accurate. For t \approx 1, the error of t^{-1} is of the same order as the input t. Do you mean \text{inv}(t+1) - 1? That one has accuracy issues, but should instead be computed as \frac{-t}{t+1} so probably doesn’t warrant a special implementation.
* * *
> [@nsajko](#):
>
> but also needs to be at least somewhat accurate.
One issue I take with these plots is that they measure the forward stability of the calculations. But I would contend that the backward stability is sometimes a better measure. I.e., is the result correct for a nearby value of the _input_. Although `asec(t)` looks really bad for t \approx 1, we see that
```julia-repl
julia> f = asec; x = nextfloat(1.0); oftype.(x, (f(x) .- f.(big(x) .+ eps(x)/2 .* (-1:1))) ./ eps(oftype(x,f(big(x)))))
3-element Vector{Float64}:
1.8654520451552772e15
1.0246318366302678
-1.4314116990281882e15
```
I.e., if you evaluate the function at values _that would round to the same `Float64(t)`_, `asec(t)` can be wrong by 10^{15} ULPs. You will never get accurate values of a function near a singularity if only because of your input-rounding. One can still insist that we _ought_ to compute the output accurately with the assumption that the input is exact, but this is only situationally useful (i.e., when you actually believe your input to be exact far beyond floating point precision). So the fact that `asec` is occasionally wrong by 10^{5} ULP is not as bad as it initially sounds. Not sure as to the best way to account for this in the above analysis, however.
In any case, putting the error on a log axis would at least let us see the errors of the functions on other parts of the domain.
---
### Author:  [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)
#### Post date: [February 4, 2026, 4:55pm UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/20 "2026-02-04T16:55:13Z")
> [@mikmoore](#):
>
> I don’t think this specific function actually needs a special implementation? For t \approx 0 the result is large and pretty accurate. For t \approx 1, the error of t^{-1} is of the same order as the input t.
If we hold it to the same extreme standards as `asech` in this thread, then it absolutely needs a special implementation. Do the same plot for `invm1 = t->inv(t)-1` and count ulps for `t = prevfloat(1.0)`.
This is where the perceived inaccuracy for asech come from: It forwards to `acosh(inv(t))`, which applies a good formula involving log1p to `t-1`.
The entire thing is of course somewhat silly – garbage in, garbage out, just as you stated in different words.
But as @GunnarFarneback correctly remarked, even users who are unwise about their stdlib usage deserve a good effort on our side. (examples of unwise calls are `log(1+epsilon)`, `acosh(1+epsilon)` or, the point of contention in this thread, `asech(1-epsilon)`. Such a call is unwise because most significant digits of `epsilon` are lost before we get to see them)
PS. edited for flagged language. Apologies, I got carried away.
---
### Author:  [@AntonReinhard](https://discourse.julialang.org/u/AntonReinhard)
#### Post date: [February 6, 2026, 12:40pm UTC](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392/21 "2026-02-06T12:40:37Z")
Just a shameless self-plug, I made a package PrecisionCarriers.jl a few months ago, with the very similar purpose of finding precision loss at specific numeric values, providing an interface to “benchmark” arbitrary functions easily.
Maybe the two packages could be coupled or merged in some way?
I also made a post on [discourse about it before](https://discourse.julialang.org/t/ann-precisioncarriers-jl-easy-detection-of-floating-point-precision-loss/130670).
[Next page](https://discourse.julialang.org/t/floating-point-accuracy-visualization-example-the-ulp-error-for-each-math-function-coming-with-julia/135392.md?page=2)