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.

2. 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.

3. 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.

4. 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.