Floating point arithmetic in go

[dja...@gmail.com]

Hi  all,

very strange behavior in float64,

http://play.golang.org/p/TYaE16-5Nw

can someone explain ?

thanks in advance

Djadala

  

[Jan Mercl]

On Wed, Sep 4, 2013 at 4:12 PM, <dja...@gmail.com> wrote:
> Hi all,
>
> very strange behavior in float64,
>
> http://play.golang.org/p/TYaE16-5Nw
>
> can someone explain ?

I think David Goldberg has something about it:
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

-j

[chris dollin]

On 4 September 2013 15:12, <dja...@gmail.com> wrote:

very strange behavior in float64,

http://play.golang.org/p/TYaE16-5Nw

Floating. Point. Numbers. Are. Not. Exact.

Chris

--
Chris "what's 1.0/3.0 in decimal notation?" Dollin

[Michael Jones]

Djadala, 

The float64 result is better, even though it is not what you want. It has much more precision in it's approximation of the unrepresentable idael numbers that you compute. It is good to think about this deeply before using floating point computation, because floating point numbers lack many of the properties of real numbers. In this case, you've proven that 1/(1/x) != x, not just for 0, but for most values of x.

It is likewise true that computer ints are not integers in the mathematical sense. As one example, -(-x) != x for at least one value of x, and (x*x)/x != x for most values of x.

Interestingly, since we all learn by exploring small cases and extrapolating, many programmers have not knowingly experienced these differences between computer arithmetic and axiomatized mathematical arithmetic. 

Michael

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[adon...@google.com]

On Wednesday, 4 September 2013 10:18:13 UTC-4, chris dollin wrote:

On 4 September 2013 15:12, <dja...@gmail.com> wrote:

very strange behavior in float64,

http://play.golang.org/p/TYaE16-5Nw

Floating. Point. Numbers. Are. Not. Exact.

Floating point rational numbers *are* exact.  There just aren't very many of them compared to rationals in general.

[Sonia Keys]

One explanation is that constant expressions in Go are evaluated at higher precision.  An important practice to learn from this example is to structure your code to move computations into constant expressions.  This both makes your code faster and more accurate.  It is faster because constant expressions are evaluated at compile time and more accurate because they are done at higher precision.

[Volker Dobler]

True. And boring :-)

How much more reals are there than floating point numbers?

That answer would be cool...

V.

[Alan Donovan]

That's easy.  ℵ₁ - ℵ₀ = ℵ₁.

[Dan Kortschak]

I think. that's an underestimate ;) (|{floating point}| < ℵ₀ unless you are using a true Turing machine).

[Volker Dobler]

Wow! Do you know something we mere mortals don't know?

Any arguments for that claim that |ℝ| =  ℵ₁ ?

[Rob Pike]

Everyone knows that, even though the proof is undecidable. This is
computing, not mathematics, where assertions count as proofs.

-rob

[Jonathan Amsterdam]

Despite its independence from the axioms of ZFC, it is still possible to provide evidence for the truth or falsity of the continuum hypothesis. You could argue for including additional axioms that imply CH or its negation, or you could try to show that certain higher reaches of set theory are more elegant or sensible with or without CH. See http://en.wikipedia.org/wiki/Continuum_hypothesis and the work of Woodin.

</waaay-off-topic>

[Thomas Bushnell, BSG]

I'm one of those Platonists who is quite sure that CH is false. 

But since this is computing, we should be making bold and unsubstantiated assertions about P=NP instead.

Nearly all the arguments for P!=NP amount to a variation on one of the following:

1: If there were a P algorithm for 3-sat, we would have found it by now, because we are such clever programmers.

2: If P=NP then all kinds of practical things which we think are hard would actually be easy.

(1) is obviously a stupid argument, but if you dress it up enough, it looks compelling to some people. (2) is not a stupid argument at all, in my opinion, but since its unstated middle premise is clearly false, it's uninteresting.

The unstated middle premise to (2) is "if P=NP then there is a polynomial-time Go program which solves 3-sat." 

But the world of set theoretic results is way more interesting than that. Here are some other possibilities in which P=NP but it doesn't make any hard problems into easy ones.

A. It could be that P=NP (provably) but nobody has a proof of it. 

B. It could be that P=NP (provably), but the shortest proof of P=NP is too large for physical realization, so nobody will ever have a proof of it.

C. It could be P=NP, but that P=NP => Axiom of Choice, and so it's hopelessly nonconstructive.

D. It could be that the shortest P algorithm for 3-sat is too large for physical realization.

And then notice that arguments 1&2 do not require P!=NP, they merely require the lack of polynomial Go programs to solve 3-sat. There are all kinds of meta-results in set theory which are just as well supported by 1&2, for example, it could be that P=NP is provably independent of ZFC, or maybe only that P=NP is provably consistent with ZFC, etc.

Thomas

[Jonathan Amsterdam]

And what about 

E. P=NP, but the exponent p is large enough that n^p > 2^n for physically realizable n.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/JEm7sjGlwSA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Thomas Bushnell, BSG]

That's commonly said as well. Sometimes it is said that it is common to find extremely bad polynomial algorithms and later make them better. But that's a bad response. After all, every problem in P has a degree: the least exponent p such that there is an O(n^p) algorithm to solve it. And even if 3-sat is in P, its degree might (as you say) be unfortunately large.