Alan,
> On 9. Dec 2021, at 17:39, Alan Brown via subsurface
> wrote:
>
> I see the PR has now been merged. The problem has been with the
> calculation of EAD and END. I am assuming these stand for Equivalent Air
> Depth and Equivalent Narcotic Depth. I believe the Bühlmann ZH16
> algorithm
Robert,
Alan Brown via subsurface writes:
> The fgetround test produces the following
>
> rounding using to-nearest rounding:
> rint (2.3) = 2.0
> rint (3.8) = 4.0
> rint (-2.3) = -2.0
> rint (-3.8) = -4.0
I see the PR has now been merged. The problem has been with the
calculation of EAD and
Robert Helling writes:
>
> depth * 1000.0 / 1000.0 which for a depth of 30m seemed to end up just a
> tiny bit below 30.
>
> That implies that we (once again) didn't do proper rounding.
>
> I suspect just short-circuiting it for zero helium hides the problem
> rather than fixing it.
>
>
Robert Helling writes:
>
> I suspect just short-circuiting it for zero helium hides the problem
> rather than fixing it.
>
> Linus
>
> what does the test program on
> https://www.cplusplus.com/reference/cfenv/fegetround/ produce on your
> machine? I am a but afraid to explicitly
Alan,
> On 5. Dec 2021, at 23:07, Linus Torvalds
> wrote:
>
> On Sun, Dec 5, 2021 at 2:03 PM Robert Helling via subsurface
> wrote:
>>
>> depth * 1000.0 / 1000.0 which for a depth of 30m seemed to end up just a
>> tiny bit below 30.
>
> That implies that we (once again) didn't do proper
On Sun, Dec 5, 2021 at 2:03 PM Robert Helling via subsurface
wrote:
>
> depth * 1000.0 / 1000.0 which for a depth of 30m seemed to end up just a
> tiny bit below 30.
That implies that we (once again) didn't do proper rounding.
I suspect just short-circuiting it for zero helium hides the
Alan,
> On 5. Dec 2021, at 21:42, Alan Brown via subsurface
> wrote:
>
> It looks like it failed again, but we are down to just a couple of
> differences. It looks like they are with END (certainly on
> exportprofile) rather than EAD.
>
>
"Robert.Helling" writes:
>
> Yes, that is related. Rather than simply adding/subtracting 1 to convert
> between depth in mm and ambient pressure, these functions properly take into
> account the surface pressure (not
> exactly 1 bar) and the density of water (not exactly 1000 kg/m^3).
Hi everyone,
> On 5. Dec 2021, at 00:16, Alan Brown via subsurface
> wrote:
>
> Is this related to the warnings I am seeing in the build log, which I am
> seeing following the patch?
>
> --snip--
> /home/alan/src/subsurface/core/profile.c: In function
> ‘calculate_gas_information_new’:
>
"Robert.Helling" writes:
> Hi,
>
> On 4. Dec 2021, at 13:09, Berthold Stoeger via subsurface
> wrote:
>
> Yes, in particular Robert's new code reads as
>
> entry->ead = mbar_to_depth(depth_to_mbar(entry->depth, dive) ...);
>
> depth_to_mbar() returns an int, and 1 bar is 10 m, thus 1 mbar
Hi,
> On 4. Dec 2021, at 13:09, Berthold Stoeger via subsurface
> wrote:
>
> Yes, in particular Robert's new code reads as
>
> entry->ead = mbar_to_depth(depth_to_mbar(entry->depth, dive) ...);
>
> depth_to_mbar() returns an int, and 1 bar is 10 m, thus 1 mbar is 10 mm which
> is precisely
On Freitag, 3. Dezember 2021 23:12:39 CET Linus Torvalds via subsurface wrote:
> On Fri, Dec 3, 2021 at 1:48 PM Alan Brown via subsurface
>
> wrote:
> > Thanks for looking into this. The test still fails but the number of
> > lines in the diffs are fewer.
>
> Still seems to be that EAD line if
On Fri, Dec 3, 2021 at 1:48 PM Alan Brown via subsurface
wrote:
> Thanks for looking into this. The test still fails but the number of
> lines in the diffs are fewer.
Still seems to be that EAD line if I count the columns right.
We do have a few places where we end up converting to an integer
Robert Helling via subsurface writes:
> this is an excellent observation. I completely missed the fact that for no
> good reason, the fraction fn2 and fhe are rounded to integers. As
> intermediate values, they should be kept double. While I
> was at it, I made MOD, END, EAD, EAAD integers
Hi everyone,
> On 3. Dec 2021, at 12:58, Berthold Stoeger via subsurface
> wrote:
>
> Indeed, by rounding one down, I get the "alternative" value. And of course,
> ceil() and floor() would exhibit the same instability depending on whether you
> are eps above or below the integer. So I reckon
On Freitag, 3. Dezember 2021 12:49:48 CET Berthold Stoeger via subsurface
wrote:
> Hi Robert,
>
> On Donnerstag, 2. Dezember 2021 08:38:25 CET Robert Helling via subsurface
>
> wrote:
> > fn2 = (int)(1000.0 * entry->pressures.n2 /
>
> amb_pressure);
>
> This looks ill-defined. You
Hi Robert,
On Donnerstag, 2. Dezember 2021 08:38:25 CET Robert Helling via subsurface
wrote:
> fn2 = (int)(1000.0 * entry->pressures.n2 /
amb_pressure);
This looks ill-defined. You probably want lrint(...) or (int)(round(...)) or
(int)(ceil(...)) or (int)(floor(...)) for
On Wednesday, 1 December 2021 14:21:28 PST Linus Torvalds via subsurface
wrote:
> I'm not seeing what's going on, but it smells like some instability in
> the calculations rather than some extra non-ieee precision of the
> i387.
An easy way to verify if it is the 387 extra precision is to remove
Hi everybody,
> On 1. Dec 2021, at 23:21, Linus Torvalds
> wrote:
>
> It's certainly not a known issue, the FP precision thing was just a guess.
>
> And honestly, the differences seem to be too big to be FP precision
> issues, particularly the i386 kind where the most common issue is that
>
On Wed, Dec 1, 2021 at 12:53 PM Alan Brown via subsurface
wrote:
>
> Scratch that, I hadn't chrooted into the build environment properly. The
> profiles in x86_64 built by TestProfile are identical to the reference
> files. Repeating the tests in the i686 environment does produce a lot of
>
Alan Brown via subsurface writes:
> When I look at the generated files in the build directory they are empty
> ls -al exportprofile*
> -rw-r--r-- 1 alan alan 0 Nov 29 16:23 exportprofile.csv
> -rw-r--r-- 1 alan alan 0 Nov 29 16:23 exportprofileVPMB.csv
Scratch that, I hadn't chrooted into the
Linus Torvalds writes:
> Rerun just that test:
>
> cd build/tests
> ./TestProfile
>
> and you should now have the two output files in that directory:
> exportprofile.csv and exportprofileVPMB.csv.
>
Thanks for you reply,
Ran this test on my x86_64 machine and got the result
*
On Sunday, 28 November 2021 08:50:04 PST Linus Torvalds via subsurface wrote:
> > I am trying to package version 5.0.5 for void linux. The build seems to
> > pass all of the tests for x86_64, aarch64, armv7l, armv6l but fails on
> > i686 on the testprofile. Does anyone k
On Sun, Nov 28, 2021 at 8:29 AM Alan Brown via subsurface
wrote:
>
> I am trying to package version 5.0.5 for void linux. The build seems to
> pass all of the tests for x86_64, aarch64, armv7l, armv6l but fails on
> i686 on the testprofile. Does anyone know why this might
Hi,
I am trying to package version 5.0.5 for void linux. The build seems to
pass all of the tests for x86_64, aarch64, armv7l, armv6l but fails on
i686 on the testprofile. Does anyone know why this might be happening
specifically for this architecture?
Thanks
Alan
* Start testing
25 matches
Mail list logo
