After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 740897 - GVariant: add support for single precision floats
GVariant: add support for single precision floats
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gvariant
unspecified
Other All
: Normal normal
: ---
Assigned To: Allison Karlitskaya (desrt)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-11-29 19:12 UTC by Allison Karlitskaya (desrt)
Modified: 2018-05-24 17:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GVariant: add support for single precision floats (23.94 KB, patch)
2014-11-29 19:12 UTC, Allison Karlitskaya (desrt)
none Details | Review
GDBus: add support for GVariant floats to helpers (1.64 KB, patch)
2014-12-02 19:37 UTC, Allison Karlitskaya (desrt)
none Details | Review
GVariant: add support for single precision floats (22.91 KB, patch)
2014-12-03 02:15 UTC, Allison Karlitskaya (desrt)
none Details | Review

Description Allison Karlitskaya (desrt) 2014-11-29 19:12:41 UTC
Add a new type 'f' to correspond to single precision floating point
values.

This type was never added to D-Bus for two reasons:

 1) there is no benefit to using float rather than doubles as parameters
    for RPC

 2) classically, you shouldn't move bulk data over D-Bus

Now that we've decided that we want to use D-Bus for bulk data
transfers, it makes a good deal of sense to want to send an array of
floats or an array of fixed-sized tuples containing floats.
Comment 1 Allison Karlitskaya (desrt) 2014-11-29 19:12:43 UTC
Created attachment 291798 [details] [review]
GVariant: add support for single precision floats
Comment 2 Allison Karlitskaya (desrt) 2014-11-29 19:16:03 UTC
The patch currently has a problem with printing/parsing.

Consider:

  float r = random_float();
  str1 = g_ascii_dtostr (r);

  /* note: we convert to double then round to float */
  float f = g_ascii_strtod (str1);
  str2 = g_ascii_dtostr (f);


It's perhaps understandable (although annoying) that 'f' may not be the same as 'r' but it's a bit surprising to find out that str1 and str2 are not even the same.

This is currently tripping up one of the testcases.  Look for 'FIXME' in the patch.
Comment 3 Allison Karlitskaya (desrt) 2014-12-02 19:37:21 UTC
Created attachment 292022 [details] [review]
GDBus: add support for GVariant floats to helpers

Add support for G_VARIANT_TYPE_FLOAT to some helper functions.

We don't add support to the core serialiser because the sending side
already has a catch-all case for unsupported types (because of maybe
types) and the receiving side will never see floats on the wire.
Comment 4 Allison Karlitskaya (desrt) 2014-12-03 02:15:17 UTC
Created attachment 292033 [details] [review]
GVariant: add support for single precision floats

Remove an unrelated change which accidentally snuck in.
Comment 5 Alexander Larsson 2014-12-04 18:37:19 UTC
I don't understand how the rounding from a double to a float can result in a different value. g_ascii_strtod() is meant to reproduce the the double to withing a machine-epsilion. The initial float should be perfectly represented as a double, and then perfectly roundtripped via ascii. I don't see how converting the double to float then would cause any rounding. The float was extended using zero padding, so it should never need any rounding.
Comment 6 Alexander Larsson 2014-12-04 18:44:06 UTC
  float r = g_random_double ();

  char buf[G_ASCII_DTOSTR_BUF_SIZE];
  char buf2[G_ASCII_DTOSTR_BUF_SIZE];
  char *str1 = g_ascii_dtostr (buf, sizeof (buf), r);

  /* note: we convert to double then round to float */
  float f = g_ascii_strtod (str1, NULL);
  char *str2 = g_ascii_dtostr (buf2, sizeof (buf2), f);

  g_print ("str1: %s, str2: %s, eq: %d\n",
	   str1, str2, r == f);

I tried this, and it seems to always work here.
Comment 7 Alexander Larsson 2014-12-04 18:55:23 UTC
Review of attachment 292033 [details] [review]:

Looks good to me, and it makes a ton of sense. Also, i need this for gthree (to store vertex data for 3d objects).
Comment 8 GNOME Infrastructure Team 2018-05-24 17:17:41 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/964.