Change in libosmocore[master]: add osmo_float_str_to_int() and osmo_int_to_float_str_*()

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.org
Tue Oct 6 23:52:42 UTC 2020


Hello 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>


More information about the gerrit-log mailing list