FAQ
As far as I tested, it breaks a few things for float32 values in strconv
and xml.

Using the xml package, a 0.1 float64 behaves well:
<float64>0.1</float64>
while a 0.1 float32 not so much
<float32>0.10000000149011612</float32>

Mitică

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Rémy Oudompheng at Feb 19, 2013 at 10:29 pm

    On 2013/2/19 wrote:
    As far as I tested, it breaks a few things for float32 values in strconv and
    xml.

    Using the xml package, a 0.1 float64 behaves well:
    <float64>0.1</float64>
    while a 0.1 float32 not so much
    <float32>0.10000000149011612</float32>

    Mitică
    strconv supports both.

    I think xml was fixed recently:
    http://code.google.com/p/go/source/detail?r=49173f8346f0

    Rémy.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Itmitica at Feb 20, 2013 at 5:22 am

    On Wednesday, February 20, 2013 12:29:52 AM UTC+2, Rémy Oudompheng wrote:
    strconv supports both.
    As far as I know it doesn't: http://play.golang.org/p/gd2Hx9LF5L.

    Mitică

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rui Maciel at Feb 20, 2013 at 7:51 am

    On 02/19/2013 09:58 PM, itmitica@gmail.com wrote:
    As far as I tested, it breaks a few things for float32 values in strconv
    and xml.

    Using the xml package, a 0.1 float64 behaves well:
    <float64>0.1</float64>
    while a 0.1 float32 not so much
    <float32>0.10000000149011612</float32>
    The IEEE754 32-bit floating point data type has a 23-bit mantissa, which
    means that it can only reproduce accurately about 7 decimal digits. If
    you try to get more than 7 decimal digits from a single precision
    floating point type then you are trying to extract information which
    isn't there. Hence, you get results that don't appear right in base 10.


    Rui Maciel

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Itmitica at Feb 20, 2013 at 9:08 am

    On Wednesday, February 20, 2013 9:51:49 AM UTC+2, Rui Maciel wrote:

    The IEEE754 32-bit floating point data type has a 23-bit mantissa

    Informative, but I'm afraid it has nothing to do with the problem at hand.

    For the specified packages, float32 is converted to float64 before
    processing, because some of their functions are only designed to work with
    float64.

    This gives a longer precision for float32 values, together with an odd
    outcome: float32 values are verbosely displayed in contrast with float64
    values.

    Mitică

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Feb 20, 2013 at 9:21 am
    When you call FormatFloat with a value that is originally a float32 and
    tell the function it's a float64, why would it not believe you and print
    all the significant digits you told it exist.

    http://play.golang.org/p/JMMp_3LL62

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Itmitica at Feb 20, 2013 at 9:45 am

    On Wednesday, February 20, 2013 11:21:23 AM UTC+2, kortschak wrote:

    When you call FormatFloat with a value that is originally a float32 and
    tell the function it's a float64

    I am not the one to blame here, this is the func signature:
    func FormatFloat(f float64, fmt byte, prec, bitSize int) string

    And, for the xml package, I'm not telling anything about the value's type.

    Mitică

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Feb 20, 2013 at 10:04 am
    Looking at the source for encoding/xml at tip, it looks like that will
    be fixed since the marshalSimple method now takes into account the size
    of the float, which go1.0.3 does not.

    http://tip.golang.org/src/pkg/encoding/xml/marshal.go?s=7563:7580#L240

    You are however telling the function what the size of the float is in
    the last parameter. This is why when you call that function with 32 the
    correct representation is returned, but when you call with 64 you get
    extra digits.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Itmitica at Feb 20, 2013 at 10:07 am

    On Wednesday, February 20, 2013 12:04:04 PM UTC+2, kortschak wrote:

    You are however telling the function what the size of the float is in
    the last parameter. This is why when you call that function with 32 the
    correct representation is returned, but when you call with 64 you get
    extra digits.
    ...which is exactly my point.
    I'm not arguing float types differences, I'm arguing mechanisms and outcome.

    Mitică

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rui Maciel at Feb 20, 2013 at 10:11 am

    On 02/20/2013 10:07 AM, itmitica@gmail.com wrote:
    ...which is exactly my point.
    I'm not arguing float types differences, I'm arguing mechanisms and outcome.
    You are trying to argue against the correct outcome.


    Rui Maciel

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Itmitica at Feb 20, 2013 at 10:37 am

    On Wednesday, February 20, 2013 12:11:16 PM UTC+2, Rui Maciel wrote:

    You are trying to argue against the correct outcome.
    No, I'm can assure that I'm not. You should read top to bottom.

    The numeric outcome is correct, float types are not the issue.

    The mechanism by which one gets the displayed outcome is questionable:
    float32 has to go as float64 in order to be processed, which results in
    longer precision displayed.


    OT
    It's easy for me to misunderstand your intentions, so I'd appreciate if
    you'd keep out remarks which can be mistakenly read as flaming: "And no,
    that site isn't broken either." or anything close to that.

    I'm just not dealing well with this kind of interpretable messages.

    Thanks.


    Mitică

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Feb 20, 2013 at 10:48 am

    On Wed, 2013-02-20 at 02:37 -0800, itmitica@gmail.com wrote:
    The mechanism by which one gets the displayed outcome is
    questionable:
    float32 has to go as float64 in order to be processed, which results
    in longer precision displayed.
    This is not true, as your first playground snippet showed. When you call
    FormatFloat with a float32 that has been converted to a float64 because
    of the signature requirement, *and you pass bitSize as 32*, the correct
    representation is returned. If you pass bitSize as 64, yes, you get the
    wrong answer. This is not a surprise.

    package main

    import (
    "fmt"
    "strconv"
    )

    func main() {
    var f32 float32 = 0.1
    fmt.Println(strconv.FormatFloat(float64(f32), 'f', -1, 32)) // The 32 here is important.
    }

    // Output:
    // 0.1

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Itmitica at Feb 20, 2013 at 11:08 am

    On Wednesday, February 20, 2013 12:48:08 PM UTC+2, kortschak wrote:

    This is not true, as your first playground snippet showed.

    It's also true, based on my first post, about the xml package.
    It's also true for math's Abs, and probably for a few more.

    While useful, I'm not looking for solutions, or float type explanations or
    precision arguments upon conversion between types.

    I'm only looking for the reason as to why float64 has been thought of as
    base for some stdlib methods, and why float32 didn't have methods of it's
    own. Which sometimes gives odd outcome which may require adjustments (or
    may not, I don't really care).

    Mitică

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rui Maciel at Feb 20, 2013 at 11:06 am

    On 02/20/2013 10:37 AM, itmitica@gmail.com wrote:
    No, I'm can assure that I'm not. You should read top to bottom.

    The numeric outcome is correct, float types are not the issue.

    The mechanism by which one gets the displayed outcome is questionable:
    float32 has to go as float64 in order to be processed, which results in
    longer precision displayed.

    This was the code you've presented:

    http://play.golang.org/p/gd2Hx9LF5L

    Read the code you've used:

    fmt.Println(strconv.FormatFloat(float64(f32), 'f', -1, 64))


    Read what the documentation has to say about it:

    http://golang.org/pkg/strconv/#FormatFloat


    You wrote a set of instructions to assume a value was a 64-bit float.
    In return, you get a decimal representation of a 64-bit float. How is
    that not the correct outcome? If you don't want your code to display
    the rounding error then don't write code with the explicit purpose of
    displaying the rounding error.


    Rui Maciel

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Itmitica at Feb 20, 2013 at 11:15 am

    On Wednesday, February 20, 2013 1:06:36 PM UTC+2, Rui Maciel wrote:

    This was the code you've presented

    In the first post there's an example where I didn't "manipulate" values,
    yet the outcome, arguably, is not the desired one.
    Can it be "fixed"? Sure, but I'm not looking at that.

    Iţm not looking to an explanation on why it happens. I can work with or
    past that.

    All I'm looking for is a reason as to why float32 doesn't have methods on
    it's own in some packages in the stdlib.

    I'm hoping it's clearer now and I apologize if it's my fault we're
    revolving around float types precision differences instead.

    Mitică

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyle Lemons at Feb 20, 2013 at 7:53 pm

    On Wed, Feb 20, 2013 at 3:15 AM, wrote:
    On Wednesday, February 20, 2013 1:06:36 PM UTC+2, Rui Maciel wrote:

    This was the code you've presented

    In the first post there's an example where I didn't "manipulate" values,
    yet the outcome, arguably, is not the desired one.
    Can it be "fixed"? Sure, but I'm not looking at that.

    Iţm not looking to an explanation on why it happens. I can work with or
    past that.

    All I'm looking for is a reason as to why float32 doesn't have methods on
    it's own in some packages in the stdlib.
    Because having both would be too many, and float32 only is insufficient.

    I'm hoping it's clearer now and I apologize if it's my fault we're
    revolving around float types precision differences instead.

    Mitică

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Russ Cox at Feb 21, 2013 at 9:23 pm
    encoding/xml is fixed at tip and will be fixed in Go 1.1.

    FormatFloat takes a float64 because all float32 values can be converted to
    float64 losslessly. This is the same reason FormatInt takes an int64 and
    FormatUint takes a uint64, and similarly for the ParseXxx functions.
    Package strconv used to be a cacophany of conversion functions. We
    simplified it quite a bit by passing the expected size as an argument.

    Russ

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Feb 21, 2013 at 9:27 pm

    On 2013/2/20 <itmitica@gmail.com>:
    On Wednesday, February 20, 2013 1:06:36 PM UTC+2, Rui Maciel wrote:

    This was the code you've presented

    In the first post there's an example where I didn't "manipulate" values, yet
    the outcome, arguably, is not the desired one.
    Can it be "fixed"? Sure, but I'm not looking at that.

    Iţm not looking to an explanation on why it happens. I can work with or past
    that.

    All I'm looking for is a reason as to why float32 doesn't have methods on
    it's own in some packages in the stdlib.

    I'm hoping it's clearer now and I apologize if it's my fault we're revolving
    around float types precision differences instead.

    Mitică
    I don't know any use for float32 except for a more compact storage than float64.
    I don't see why people would ever compute with float32s and don't
    think there is a need for that. Do you know one?

    Thus the float32-enabled functions are mostly oriented toward I/O and
    serialization. I think there could have been FormatFloat32 and
    FormatFloat64 instead of a single FormatFloat with a bitsize argument,
    but it is coherent at least with the integer routines.

    Rémy.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rui Maciel at Feb 20, 2013 at 10:10 am

    On 02/20/2013 09:08 AM, itmitica@gmail.com wrote:
    Informative, but I'm afraid it has nothing to do with the problem at hand.

    For the specified packages, float32 is converted to float64 before
    processing, because some of their functions are only designed to work with
    float64.

    This gives a longer precision for float32 values, together with an odd
    outcome: float32 values are verbosely displayed in contrast with float64
    values.
    You didn't understood what was said. Instead of explaining again why
    nothing you've pointed out is broken, and how this is exactly what
    anyone gets from a working floating point implementation, I'm simply
    going to point out a site which lets you experiment with IEEE 754 floats
    at the bit level.

    http://www.h-schmidt.net/FloatConverter/IEEE754.html

    Pay attention to how the "after casting to double precision" field in
    that site produces 0.10000000149011612 when converting 0.1 from a
    single-precision representation to a double precision one. And no, that
    site isn't broken either.


    Rui Maciel

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 19, '13 at 9:58p
activeFeb 21, '13 at 9:27p
posts19
users6
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase