Bug Report: “Download Factors” Exports Inconsistent Precision
1 — Summary
The Precision (2 – 8, leave empty for no rounding) option in Research → Tools → Download Factors does not behave as documented:
- Leaving the box blank (supposed to be “no rounding”) creates a mix of short and long decimals.
- Explicitly entering 8 (the maximum allowed) still rounds many rows to just 2 or 3 decimals.
The result is a file with inconsistent numeric formats.
2 — Steps to Reproduce
# | Action |
---|---|
1 | Go to Research → Tools → Download Factors. |
2 | Choose any factor (e.g., AvgDailyTot(200) ), frequency Weekly, date range 06 Jul 2024 – 28 Jun 2025. |
3a | Case A: leave Precision blank and click Download. |
3b | Case B: type 8 in Precision, then Download. |
3 — Expected Result
All rows should share the same precision:
- Blank field → full double precision (≈16 digits) for every row.
- 8 → exactly eight decimals for every row.
4 — Actual Result
Both cases yield a mix of formats (sample rows):
# Case A – Precision blank
06/07/2024 4737 IBM 0.87
13/07/2024 4737 IBM 0.8677354709418837
…
17/05/2025 4737 IBM 0.892
…
28/06/2025 4737 IBM 0.8962075848303394
# Case B – Precision = 8
06/07/2024 4737 IBM 0.87
13/07/2024 4737 IBM 0.86773547
…
17/05/2025 4737 IBM 0.892
…
28/06/2025 4737 IBM 0.89620758
Many rows are cut back to only 2–3 decimal places, whereas others keep eight-digit or full (~16-digit) precision.
5 — Why This Matters
- ETL issues – Inconsistent decimals trigger unwanted coercion or rounding.
- Accuracy risk – Mixed precision alters factor ranks and back-tests.
- Expectation gap – “No rounding” or “8-dec” options don’t deliver.
6 — Environment
- Browser: Chromium Version 137.0.7151.103 (Official Build, ungoogled-chromium) (64-bit) on Windows 11 (10.0.26100)
- Date Tested: 30 Jun 2025
- Factor Used:
AvgDailyTot(200)
7 — Attachments
Screenshot – Download Factors settings dialog with Precision Blank
8 — Suggested Fix
Ensure the export routine outputs uniform precision:
- Blank → full stored double precision.
- Explicit value → exactly that many decimals for every row.
Thanks for looking into this, happy to supply extra logs or test cases if needed.