Bug#888733: hyantesite: test failures on most architectures
Control: retitle -1 should hyantesite be part of buster? Hi, On Tue, 21 May 2019 07:24:17 +0200 Andreas Tille wrote: > On Mon, May 20, 2019 at 08:05:09PM +0100, Rebecca N. Palmer wrote: > > On 19/05/2019 18:15, Andreas Tille wrote: > > > So what is the plan to fix this bug? Create new references to craft > > > a valid test or ignore these tests? > > > > ...or decide that something that's abandoned and doesn't follow its > > documentation (even after the above fixes) doesn't belong in Debian stable > > and let it be removed? I have no strong opinion. > > > > The above fix was written as part of an attempt to find fixes for all RC > > bugs in debian-science testing; I hadn't heard of the package before seeing > > this bug. > > Same for me. If nobody else might rise an opinion we probably let it go > and the package will be removed now from testing. The real usage of > this package[1] is below 20 users (but anyway there are 20) and I'm > intentionally CCing Debian Science user list to possibly reach some of > these users. If by now, you think the package should be removed, can we have an RM bug please, such that others don't have to spend the time reading the bug report? Paul signature.asc Description: OpenPGP digital signature
Bug#888733: hyantesite: test failures on most architectures
On Mon, May 20, 2019 at 08:05:09PM +0100, Rebecca N. Palmer wrote: > On 19/05/2019 18:15, Andreas Tille wrote: > > So what is the plan to fix this bug? Create new references to craft > > a valid test or ignore these tests? > > ...or decide that something that's abandoned and doesn't follow its > documentation (even after the above fixes) doesn't belong in Debian stable > and let it be removed? I have no strong opinion. > > The above fix was written as part of an attempt to find fixes for all RC > bugs in debian-science testing; I hadn't heard of the package before seeing > this bug. Same for me. If nobody else might rise an opinion we probably let it go and the package will be removed now from testing. The real usage of this package[1] is below 20 users (but anyway there are 20) and I'm intentionally CCing Debian Science user list to possibly reach some of these users. Kind regards Andreas. [1] https://qa.debian.org/popcon-graph.php?packages=libhyantes-dev+libhyantes0+hyantesite_vote=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1 -- http://fam-tille.de
Bug#888733: hyantesite: test failures on most architectures
On 19/05/2019 18:15, Andreas Tille wrote: So what is the plan to fix this bug? Create new references to craft a valid test or ignore these tests? ...or decide that something that's abandoned and doesn't follow its documentation (even after the above fixes) doesn't belong in Debian stable and let it be removed? I have no strong opinion. The above fix was written as part of an attempt to find fixes for all RC bugs in debian-science testing; I hadn't heard of the package before seeing this bug.
Bug#888733: hyantesite: test failures on most architectures
Hi, On Mon, May 06, 2019 at 09:48:18AM +0100, Rebecca N. Palmer wrote: > It looks like ra_pareto was also broken on amd64 (probably for the same "two > variables with the same name" reason, though I haven't tested this), giving > a constant output within its range circle, and the ra_pareto.out reference > used that broken version (it's identical to ra_disk.out). > > Hence, I now consider it likely that the two fixes above do work, and the > test references are wrong. > > Furthermore, the documentation doesn't match the actual behaviour (with or > without these fixes): > - It shows amortized_disk as a cone; it's now actually 1/(1+distance). > - It shows nonzero output extending outside the distance=range circles, > which is now not possible (hyantes_run.c:82). > > The definitions of amortized_disk and pareto are also weird in that they > change shape (not just scale) when range is changed. > > Upstream appears to be abandoned (last commit 6 years ago, last upload by > the sole Uploader (who is also upstream) nearly 7 years ago). So what is the plan to fix this bug? Create new references to craft a valid test or ignore these tests? Kind regards Andreas. -- http://fam-tille.de
Bug#888733: hyantesite: test failures on most architectures
It looks like ra_pareto was also broken on amd64 (probably for the same "two variables with the same name" reason, though I haven't tested this), giving a constant output within its range circle, and the ra_pareto.out reference used that broken version (it's identical to ra_disk.out). Hence, I now consider it likely that the two fixes above do work, and the test references are wrong. Furthermore, the documentation doesn't match the actual behaviour (with or without these fixes): - It shows amortized_disk as a cone; it's now actually 1/(1+distance). - It shows nonzero output extending outside the distance=range circles, which is now not possible (hyantes_run.c:82). The definitions of amortized_disk and pareto are also weird in that they change shape (not just scale) when range is changed. Upstream appears to be abandoned (last commit 6 years ago, last upload by the sole Uploader (who is also upstream) nearly 7 years ago).
Bug#888733: hyantesite: test failures on most architectures
However, the "obvious" fix
seems to break ra_pareto, for unknown reasons.
It's not this change that breaks ra_pareto: it was _already_ totally
broken on i386 (all-0s output).
Not using the name 'tmp' for two different variables gives some nonzero
output:
--- a/src/hyantes.c
+++ b/src/hyantes.c
@@ -65,7 +65,7 @@ hs_config_t g_config = { NULL,0,0,0,500,0,0 }; //
global configuration used by d
#define SMOOTHING_FUN EXPONENTIAL
#include "hyantes_run.c"
-#define PARETO(pot,dst,res,range) do{data_t tmp = POW2(dst);
res=(pot)*(1./(1+(2/(range)*POW2(tmp;} while (0)
+#define PARETO(pot,dst,res,range) do{data_t tmpp = POW2(dst);
res=(pot)*(1./(1+(2/(range)*POW2(tmpp;} while (0)
#define SMOOTHING_FUN PARETO
#include "hyantes_run.c"
but still some big differences. (ra_pareto is the only test using this
smoothing function.)
Bug#888733: hyantesite: test failures on most architectures
Control: tags -1 upstream
(probably - I haven't actually tried)
The missing centre points (0 instead of max at distance=0) are probably
due to rounding error in the great circle distance
(src/hyantes_run.c:80): equal coordinates should give tmp=acos(1)=0, but
rounding error might make it acos(just over 1)=NaN, causing this point
to be skipped by if(tmpthe normalization step.
However, the "obvious" fix
--- a/src/hyantes_run.c
+++ b/src/hyantes_run.c
@@ -76,8 +76,10 @@ static void DO_RUN (data_t lonMin, data_t latMin,
data_t lonStep, data_t latStep
for(size_t i=imin;i+
COS(latMin+latStep*i)*COS( t[k].lat ) * (
COS(lonMin+lonStep*j)*COS(t[k].lon)+SIN(lonMin+lonStep*j)*SIN(t[k].lon))
+ SIN(latMin+latStep*i)*SIN(t[k].lat);
data_t tmp =
- 6368.*
ACOS(COS(latMin+latStep*i)*COS( t[k].lat ) * (
COS(lonMin+lonStep*j)*COS(t[k].lon)+SIN(lonMin+lonStep*j)*SIN(t[k].lon))
+ SIN(latMin+latStep*i)*SIN(t[k].lat));
+ (tmp0 >= 1.) ? 0. :
(6368.* ACOS(tmp0));
/* if distance from town is within range, set
contribution */
if( tmp < range ) {
/* The next line will be replace by cpp to
match the wanted smoothing function*/
seems to break ra_pareto, for unknown reasons. (It also still doesn't
pass family, but that appears to be a bug in the test suite: there are
some missing centre points *in the family.out reference*, which are
probably also why this bug isn't visible on amd64.)
Bug#888733: hyantesite: test failures on most architectures
Control: found -1 1.3.0-1.1 Control: retitle -1 hyantesite: test failures on most architectures At least on i386, this *isn't* just -0 vs +0 and last-digit rounding errors: in test 'family' (which applies a cone smoother to a regularly spaced set of spikes), centre points drop from highest to 0, e.g. -9.00 4.99 0.109082 -9.00 5.00 0.228827 -9.00 5.01 0.109082 +9.00 4.99 0.110345 +9.00 5.00 0.00 +9.00 5.01 0.110345 It also fails in 1.3.0-1.1 if the tests are run (they aren't by default). This fails even on amd64 buster, though not as badly: only a last-digit error (in test 'ra').
