Open iain-clark opened 3 months ago
Iain, I have a (temporary) fork of Tetra3 that, among other things, improves how patterns are selected during database construction. As you have found, Tetra3's current database construction approach misses out on a lot of bright stars; the fork solves this problem such that even a much smaller database yields better solve rates.
There are also other solve-time improvements that speed up solves in many cases.
I would be really interested to see your results applied to the fork. It is at https://github.com/smroid/cedar-solve.
Thanks, -Steven
Hi Iain,
I ran exercise_tetra3.py against the cedar-solve fork of Tetra3 on my Rpi4. Results:
pattern_catalog length: 1560560
...
fail_count = 0
max solve time 319.1519810061436
min solve time 23.127488006139174
mean solve time 42.431422849657245
Number of T_solve results above mean = 3646 Out of 10000
I don't have the visualizations as I was not running on a graphical system. It does seem that the cedar-solve fork of Tetra3 exhibits greater uniformity of solve times, and it accomplishes this with 1/8 database size.
I've made some further improvements on cedar-solve. Results:
pattern_catalog length: 1424136
...
fail_count = 0
max solve time 77.0800780155696
min solve time 24.100307025946677
mean solve time 36.910300016851394
Number of T_solve results above mean = 4125 Out of 10000
Hi:
Please see description and code in attached .txt file.
late_sol_patterns.txt
![tsolve_v_radec_side](https://github.com/esa/tetra3/assets/23509586/03c3e39c-4e9b-4ef4-8bf4-a903e9fcaa48)