BWStat v3.0.2 sneak preview

We zijn aan een upgrade van BWStat aan het werken. Verschillende verbetingen werden ondertussen al geïmplementeerd in versie 3.0.2. De eerste interne testen zijn achter de rug. Nu zijn de externe testers aan de beurt. Alle commentaren, bedenkingen, opmerkingen en suggesties kunnen helemaal onderaan deze pagina achtergelaten worden in de reacties. Wanneer deze versie aan het grote publiek vrijgegeven wordt, zal ze versie 3.1 genoemd worden.

Nous travaillons sur une mise à jour de BWStat. Plusieurs améliorations ont été implémentées dans la version 3.0.2. Les premiers tests internes sont terminés. C'est maintenant au tour des testeurs externes. Tous les commentaires, pensées, remarques et suggestions peuvent être laissés tout en bas de cette page dans les commentaires. Lorsque cette version sera diffusée au grand public, elle s'appellera version 3.1.

We are working on an upgrade of BWStat. Several improvements have already been implemented in version 3.0.2. The first internal tests have been completed. Now it's the turn of the external testers. All comments, concerns, remarks and suggestions can be left in the comments section at the bottom of this page. When this version is released to the general public, it will be called version 3.1.


afbeelding van Theo Scheffers

dat ziet er mooi uit!

yes bedankt voor deze fijne opmerking

Het volgende voorstel voor de legend van Shapiro-Wilk, bijna letterlijk uit de EN689 Annex E
If p (normal) > p (lognormal) it may be concluded that a normal distribution fits the results better than a lognormal distribution (EN689 Annex E)
The power of the test to reject (log)normality is too limited for the small sample numbers considered here

Ik merk dat BWstat niet met kleine meetresultaten met meer dan 2 cijfers na de komma kan rekenen, voor blootstelling aan metalen met lage concentraties en lagen grenswaarden zou dit wel nodig/nuttig zijn.

Goede vraag, Peter.

BWStat heeft niet echt beperkingen op het aantal beduidende cijfers in de input.
BWStat rekent vervolgens met 16 beduidende cijfers.
BWStat rondt de output af op drie cijfers na de komma, wat in principe meer dan voldoende is voor de nauwkeurigheid van dit type van metingen.

We twijfelen er niet aan dat je iets hebt opgemerkt in verband met kleine meetwaarden, maar zoals blijkt uit wat voorafgaat, kunnen we je uitspraak over 2 cijfers na de komma niet reproduceren.

We zouden je vraag nauwkeuriger kunnen beantwoorden als je ons je dataset zou kunnen doorsturen en als je ons zou kunnen aanduiden welke problemen er zich daarmee voordoen in BWStat.

The data input doesn't allow six different workers but only 5

This is accepted:

1.467 A1 1 TRUE 0.3 0.1
1.136 A2 2 TRUE 0.3 0.1
1.022 A3 3 TRUE 0.3 0.1
0.857 A4 4 TRUE 0.3 0.1
0.771 A5 5 TRUE 0.3 0.1
1.081 A5 6 TRUE 0.3 0.1

This is not accepted

1.467 A1 1 TRUE 0.3 0.1
1.136 A2 2 TRUE 0.3 0.1
1.022 A3 3 TRUE 0.3 0.1
0.857 A4 4 TRUE 0.3 0.1
0.771 A5 5 TRUE 0.3 0.1
1.081 A6 6 TRUE 0.3 0.1

Onother problem is that is not understable if the software read LOD/LOQ

in the example file LOD & loq are inverted:


value worker date detect lod loq
43,3 1 6 TRUE 0,16 0,04
190,07 1 7 TRUE 0,16 0,04
319,44 1 5 TRUE 0,16 0,04
234,22 1 5 TRUE 0,16 0,04
294,16 1 1 TRUE 0,16 0,04
143,17 1 3 TRUE 0,16 0,04

First, thank you, Eugenio, for trying out our version 3.0.2. And second, thank you for your feedback. You have identified some very pertinent issues.

  1. There is no limit on the number of workers allowed in data input. However, BWStat may behave strangely in response to certain datasets.

For datasets with more than one worker, BWStat performs a between worker subgroup analysis (hence the name “BW”Stat). This requires the division by dfw = n - k (degrees of freedom within subgroups = sample size – number of subgroups). It is easy to see that dfw = 0 when every subgroup has exactly one datapoint.

When this occurs, BWStat currently produces a fatal error, which means that the application needs to be restarted. This is due to the fact that BWStat currently is lacking error handling code to capture this exception. This is still a relic of the first development versions, which were rather “quick and dirty”. Before your comment, we had received no user reports about this issue. Thanks to your input, we will address this problem in the next bugfix update. In the meanwhile, you can bypass the problem by using just one label in the worker column when you have a dataset with n = k.

  1. What does BWStat do with the columns LOD and LOQ?

Currently, only the first four columns are used (TWA-8h, worker, date, detect). All the other columns, if any, are discarded. However, if data are present in columns 5 and 6, BWStat expects them to be numbers with a decimal point. If this is not the case, BWStat will produce a fatal error. The selection option for the decimal comma will not work for columns 5 and 6. Actually, this is also a remnant of the first development versions that never even reached final release. That’s why the “download dataset” button currently still returns six columns in the output file “dataset.csv” (value;worker;date;detect;lod;loq). Since this leads to confusion, the two last columns should be removed from the output file in the next bugfix update. Nevertheless, it is highly recommended to restrict data input to four columns only.

  1. How are censored data treated by BWStat?

The values in the first columns are treated as measured values where the value in the fourth column is “TRUE”. In the rows where the fourth column is “FALSE”, the values in the first column are treated as censoring limits. EN 689 only considers LOQ, but if you prefer, you could use the value of LOD as well. Therefore, the labels “detect” in the input area and “nondetect handling” in the left pane could lead to confusion. They should probably be replaced by something like “censored” and “handling of censored values” in the next bugfix update.

BWStat offers four methods to manage censored values. The first method treats them as measured values, which of course introduces false information in the dataset and therefore is absolutely unacceptable. This method is purely offered for academic purposes. From the three remaining methods, only the robust regression on order statistics method uses the values of the censoring limits. Users should be aware that the two other ROS methods do not make use of this value, but merely of the presence of the censored datapoints.

  1. In some built-in example datasets, the columns 5 and 6 are swapped.

Indeed, this is visible in the output file of the dataset in the tab “Download”. Columns 5 and 6 are titled “lod” and “loq”. In the output of some built-in example datasets however, the output values in the column “lod” are larger than the output values in the column “loq”. This is another remnant of the first draft versions. It is in fact harmless because those columns are not used, as explained above. However, in this case, they should not appear in the output file. Another point of attention for the next bugfix update.

Reactie toevoegen