Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub#140 ⁃ SphinxQL protocol rounds float attributes to 6 decimal places #140
Describe the environment
Manticore Search version: 2.6.2 0bbd194@180223 release
OS version: "Ubuntu 14.04.5 LTS
Build version: 0bbd194
Describe the problem
Description of the issue: SphinxQL protocol rounds float attributes to 6 decimal places
Steps to reproduce:
For comparison from the API
The same of course also happens when using a plain index, and data is direct from mysql,
which is how found this.
The attribute is being written ok (as evidenced by the SPhinxAPI query), just rounded in SphinxQL. Getting the 6decimal place value in both mysql CLI client, and PHP code, so dont think its the client doing the rounding. (of and of course can get full more accurate result from mysql directly
This demonstrates that a decimal latitude recomputed from the truncated radians value is wrong by a small amount (about 50m in real world :)
The API provided value 0.95289313793182 is still not exactly the same as provided as input, but not expected as exact. But looks like if got 10 decimal places back from SPhinxQL, then would be able to reproduce the original decimal lat/long to 6 dp.
btw, just realized can get slightly better results doing the conversion back to degrees, directly in searchd itself.
But interestingly notice its still not quite right, getting 54.596756 as opposed to 54.596755 what was stored in mySQL originally.
MySQL doing the conversion back to degrees, using the value stored in attribute
would give 54.596755 again.
Hi. Thanks for pointing this out. Indeed the precision is lost at some point. The same actually happens in mysql too by default:
but there you can get a higher precision by using FORMAT():
We'll need to think what we can do about this.
MySQL and just printf('%f%') in general round to 6 dp since it provides the precision guarantee. More practical would be to round to 7 dp (as this study https://www.exploringbinary.com/decimal-precision-of-binary-floating-point-numbers/ shows) since it would cover about 90% of cases. But ideally we would have FORMAT(value, dp) instead to let users decide whether they want a higher precision with higher chance of mistake or lower precision with the guarantee of no mistake.
Thanks for investigating. I admit not aware of the default 6dp with sprintf.
Looks like 8dp does allow reproducing the original lat/long from radians
(note in this case teh lat/long database columns are explicit DECIMAL(10,6) columns so hid that mysql is could provide 6 dp too. But this query does demonstrate that mysql expressions can produce more thatn 6dp, maybe expressions are actully done as
Note have found this this seems to work mostly ok in the meantime :)
because it still using 6dp, get a few extra digits. Seems more reliable than using the radians>degree multiplication in manticore, presumably due to rounding errors. But is still a tiny bit out. degrees(0.95289648): 54.59694661687226 - which would round (rather than truncate) as 54.596947.
changed the title
SphinxQL protocol rounds float attributes to 6 decimal places
Jan 24, 2019
Behavior corrected @ 14ff372 with proposed way: output 6 digits, parse back to float and compare with original. If equal, return this. If not - output 8 digits.
Note that it is still talk about 'float' numbers, not doubles. So, it will trigger sometime, but really seldom, since for majority of floats 6 digits is really enough, only few may be printed in 8 digits more precisely (and in the flow they are mostly result of functions like sin, ln, tan, and even rand).