# Pkg DoubleFloats, some consts flawed

**URL:** <https://discourse.julialang.org/t/pkg-doublefloats-some-consts-flawed/111917>\
**Category:** Numerics\
**Tags:** package, doublefloats\
**Created:** [March 21, 2024, 5:58am UTC](https://discourse.julialang.org/t/pkg-doublefloats-some-consts-flawed/111917 "2024-03-21T05:58:09Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![derSchorsch](https://avatars.discourse-cdn.com/v4/letter/d/e8c25b/32.png) [@derSchorsch](https://discourse.julialang.org/u/derSchorsch)\
**Post date:** [March 21, 2024, 5:58am UTC](https://discourse.julialang.org/t/pkg-doublefloats-some-consts-flawed/111917/1 "2024-03-21T05:58:09Z")

</div>

Hi all, I have noticed that many of the constants related to pi in the file sequences.jl of pkg DoubleFloats are flawed. For example, the DD values for (15/32)\*%pi read:  
`"Double64(1.4726215563702156, -5.3616983752483455e-17),"`  
whereas my PY/MX/JL-scripts as well as the XL-addin XNumbers compute:

```julia
DDhi: +1.4726215563702156341e+00... , 3F F7 8F DB 9E FF EA 47
DDlo: -5.3616983752483473226e-17 ; BC 8E E8 78 60 39 D3 73 .

```

So in this example, DoubleFloats-DDlo is off by 3 ULPs. Any ideas??

---

<div class="post-metadata">

**Author:** ![JeffreySarnoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeffreysarnoff/32/1980_2.png) [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)\
**Post date:** [March 21, 2024, 9:19am UTC](https://discourse.julialang.org/t/pkg-doublefloats-some-consts-flawed/111917/2 "2024-03-21T09:19:45Z")

</div>

Hello. You earned this ![you earned this](https://global.discourse-cdn.com/julialang/original/3X/9/6/96a7079635a27f175114520b1f07cfc55895fa1c.jpeg)  
I am regenerating every constant in the repository.

(The current implementation does meet documented accuracies.)

The original values were transcribed from constants given by  
one of the original authors. There was a note that many people  
were writing to explain that some of the constants were inexact.  
The note stated the values as written are as intended.  
Any very low order mismatches were the result of subtle  
misapplication of representation interconversion, and maybe  
an incorrect assumption about the rounding techniques used  
with each part.

I will replace the constants and rerun the accuracy tests.