This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
neels gerrit-no-reply at lists.osmocom.orgHello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/libosmocore/+/20331 to look at the new patch set (#3). Change subject: add osmo_float_str_to_int() and osmo_int_to_float_str_*() ...................................................................... add osmo_float_str_to_int() and osmo_int_to_float_str_*() This will be useful to handle latitude and longitude numbers for GAD, which is the location estimate representation used for LCS (Location Services). The OsmoSMLC VTY user interface will provide floating-point strings like "23.456" while GAD stores them as micro-degress 23456000. The osmo_gad_to_str* will also convert latitude and longitude to floating-point string. There was code review concerns against adding this API, upon which I tried to use floating point string formats. But I encountered various problems with accuracy and trailing zeros. For global positioning data (latitude and longitude), even inaccuracy on the sixth significant decimal digit causes noticeable positional shift. To achieve sufficient accuracy on the least significant end, I need to use double instead of float. To remove trailing zeros, the idea was to use '%.6g' format, but that can cause rounding. '%.6f' on a double looks ok, but always includes trailing zeros. A test program shows: %.6g of ((double)(int32_t)23230100)/1e6 = "23.2301" <-- good %.6g of ((double)(int32_t)42419993)/1e6 = "42.42" <-- bad rounding %.6g of ((double)(int32_t)23230199)/1e6 = "23.2302" <-- bad rounding %.6f of ((double)(int32_t)23230100)/1e6 = "23.230100" <-- trailing zeros %.6f of ((double)(int32_t)42419993)/1e6 = "42.419993" <-- good %.6f of ((double)(int32_t)23230199)/1e6 = "23.230199" <-- good It looks like when accepting that there will be trailing zeros, using double with '%.6f' would work out, but in the end I am not certain enough that there aren't more hidden rounding / precision glitches. Hence I decided to reinforce the need to add this API: it is glitch free in sufficient precision for latitude and longitude data, because it is based on integer arithmetic. The need for this precision is particular to the (new) OsmoSMLC vty configuration, where reading and writing back user config must not modify the values the user entered. Considering to add these functions to osmo-smlc.git, we might as well add them here to libosmocore utils, and also use them in osmo_gad_to_str_*() functions. Change-Id: Ib9aee749cd331712a4dcdadfb6a2dfa4c26da957 --- M include/osmocom/core/utils.h M src/utils.c M tests/utils/utils_test.c M tests/utils/utils_test.ok 4 files changed, 1,000 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/31/20331/3 -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/20331 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: Ib9aee749cd331712a4dcdadfb6a2dfa4c26da957 Gerrit-Change-Number: 20331 Gerrit-PatchSet: 3 Gerrit-Owner: neels <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de> Gerrit-CC: laforge <laforge at osmocom.org> Gerrit-CC: pespin <pespin at sysmocom.de> Gerrit-MessageType: newpatchset -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20201006/727c0738/attachment.htm>