asked on September 7, 2018
Hi,
it seems that some values are counted twice when data are imported. Attached are the csv file sent to flexmonster, and 2 screenshots of result shown in Flexmonster.
If we have 2 values starting with the same 3 charracters, the calculation for the first value includes both, check the screenshot row N ARG has 20, ARGD has 10, CYS 20, CYSD 10 ...
The real number is 10.
Do you have an idea why it is happening and how to fix it ?
Thanks, regards
Patrick
⋅ September 7, 2018
Hello Patrick,
Thank you for writing. We have looked through the screenshots and the data sample but the described behavior is not reproducible on our side. The count aggregation returns the correct results. For the ARG member it is 10 and for the ARGD it is also 10. Therefore, could please provide the access to your environment, where the issue is reproducible? That will definitely help us in our investigation.
Waiting to hear from you.
Regards,
Dmytro
⋅ September 7, 2018
Yes I know, I checked locally and it looks ok.
below are credentials to connect to our demo web site, please do not delete and change anything.
This will be open for the next 12 hours
https://preprod-pne.adisseo.com/users/sign_in?locale=en
login = ************
Left column, click on Statistics => Pivot Table
Select a few days in June and then data will be shown in Flexmonster
Let me know
Thanks
Patrick
⋅ September 7, 2018
Hello Patrick,
Thank you for providing us with the access to your environment. We have checked the case and everything seems to work as expected. Please find the video example: https://www.screencast.com/t/yRltgzhkj1G. As you can see in the video example the drill through displays the rows from the row data. Therefore, according to the data, the results are correct. In such case, we recommend carefully checking all the input data. We suppose that the reason for the described behavior can be hidden there.
Please let us know if everything works fine for you.
Regards,
Dmytro
⋅ September 10, 2018
Hello Dmytro,
OK you're right but for us there is something strange because it came from the same sample (check flex-nir-double attached).
I have 2 other questions, it seems that the CV calculation is wrong, check them in flex-sd, you will see that some of them are wrong, why ? and it seems that you round to the low number (if average is 4.7075, it will show 4.70).
Finally the last problem to us is columns' order, check the raw_export file, parameter column is ordered like it should be but in Flexmonster that is shown in an alphabetical order, is it possible to change that ?
Thanks, regards
Patrick
⋅ September 10, 2018
Hello Patrick,
Thank you for writing. As we can see from the screenshot "flex-nir-double.png" there are 6 visible rows for the "ARG (G/100G)" member and we suppose that there are 2 hidden rows with the "ARG (G/100G)". All together it equals 8 which is correct for such data slice.
Speaking of "flex-sd.png" screenshot we cannot find there any 4.70 results for CV calculation. If you observe any mistakes in calculations please provide us with a working sample where the issue is reproducible. That will help us to investigate the issue and fix it.
Speaking of column order it is difficult to catch the idea since the results_export_201809101223.csv file does not include the first header row only the data columns. If you need to define the sorting in Flexmonster please refer to the following article: https://www.flexmonster.com/doc/sorting/.
Let us know in case of any other question.
Regards,
Dmytro
⋅ September 11, 2018
Hi Dmytro
About CV calculation, check the screenshot attached, you will see that they are all wrong
if CV = (sted / average) * 100, then 1st column should be 4.12, 2nd should be 1,28 ...
Thanks
Patrick
⋅ September 12, 2018
Hello Patrick,
Thank you for writing. It took us some time to check your case and make all the necessary tests. We tried the same case with the same slice on your environment and found that the provided screenshot does not tell the whole story. The thing is that you are using "maxDecimalPlaces" for formatting for all measures. Such formatting rounds the results and when you decide to check the calculations using the rounded input data the information will be lost and you will get miscalculation. Here is the example you suggested: formatted Stdev = 0.3, formatted Average = 7.28. For such input data, CV (Stdev / Average) equals 0.0412. However, the result data is rounded and it does show the whole picture. If we look at the none formatted input data which Flexmonster pivot uses for the calculation the result will look different. Here is the example with 4 decimal places Stdev = 7.2843, Average = 0.3035. For such input data, CV equals 0.0416 which is much closer to what Flexmonster's result is. Flexmonster uses the raw data for its calculations and also does not round the data between calculations that is why the suggested results are correct. As you can see the difference is only 0.0004 which is not a very big deal but when you multiply it by 100 the difference equals 0.04 which is a quite significant miscalculation. Therefore, after all the tests we want to ensure you that the result provided by Flexmonster are correct.
Please let us know in case of any other question.
Regards,
Dmytro
⋅ September 12, 2018
Hi Dmytro,
Attached is another example of wrong display, there are no value but CV is 0.11 % ?
And you don't answer to my question about rounded number, why is Flexmonster displaying 4.70 if real result is 4.708 ?
Thanks
Patrick
⋅ September 13, 2018
Hello, Patrick,
Thank you for providing these additional details.
It really helped us to reproduce the issue when CV is showing 0.11% and there is no underlying data. The fix for this issue will be released on October the 8th.
As about your second question, about rounding numbers, we weren't able to detect the issue. Please have a look at the following demonstration: http://take.ms/lgh4T. Here 5.938% is rounded to 5.94%, which seems correct. If you see the cases when the rounding in incorrect, we would be grateful to know about it.
One more observation, we have noticed you are using "maxDecimalPlaces": 2 for all formats, which leads to the situations when not more than 2 decimals are shown after the decimal separator.
Please share your feedback with us.
Regards,
Tanya
⋅ October 10, 2018
Hello Patrick,
We are glad to inform you that the version with the fix for the 0.11% issue has already been released.
You are welcome to try it.
Regards,
Dmytro
