#pi^-100 precision

31 messages · Page 1 of 1 (latest)

leaden agate
#

Looking for help with fixing this code snippet. Basically doing pi^-100 and the output should be this: 1.9275814160560204e-50

but when I run the below code it always ends up being this (1.9275814160560202e-50) regardless of how I change the precision etc

package main

import (
    "fmt"
    "math"
)

func powPI(x float64) float64 {
    return math.Pow(math.Pi, x) * (1 + 9.4e-16)
}

func main() {
    fmt.Println(powPI(-100))
    // output powPI(-100):1.9275814160560202e-50,
}
last hornet
#

you are reaching the limits of precision with floating point numbers

leaden agate
#

Hmm. So what’s the solution? I tried doing it using math/big too and same issue

night notch
#

And how did you set precision on math/big?

leaden agate
night notch
#

can you give me entire code with big if you still have it?

leaden agate
#

I don’t have the code anymore unfortunately

little turret
#

not all decimal are representable in binary (take 0.1 as an example)

old acorn
#

all decimals are representable in binary, provided you have a sufficient amount of bits. they might not be in IEEE 754 though

fast hearth
#

in the traditional floating point model there is no way to represent it exactly without infinite bits (just like representing 1/3 cannot be done exactly in any finite number of decimal digits)

#

but i’m not sure how applicable the example really is here

old acorn
#

in floating point sure, but there exists other ways to store decimals than floating-point

fast hearth
#

sure, that’s clearly not what you meant in your original message though 😁 you can’t just throw more bits at it

#

that’s why i said “in the traditional floating point model”

old acorn
old acorn
#

for infinite precision floating point simply isn't suited

little turret
#

I am answering op giving a much simpler example (0.1). not sure what you’re saying. but the fact is there is no 0.1 in float64

little turret
#

not sure why in the context of go I would need to specify that “binary” is binary as available in float64 or big.Float internal representation or how that’s incorrect or misleading

old acorn
fathom tokenBOT
#
Package github.com/cockroachdb/apd/[email protected]

Types: 8
Functions: 2

Package apd implements arbitrary-precision decimals.

apd implements much of the decimal specification from the General Decimal Arithmetic (http://speleotrove.com/decimal/) description, which is refered to here as GDA. This is the same specification implemented by pythons decimal module (https://docs.python.org/2/library/decimal.html) and GCCs decimal extension.

Features

Panic-free operation. The math/big types don’t return errors, and instead panic under some conditions that are documented. This requires users to validate the inputs before using them. Meanwhile, we’d like our decimal operations to have more failure modes and more input requirements than the math/big types, so using that API would be difficult. apd instead returns errors when needed.

Support for standard functions. sqrt, ln, pow, etc.

Accurate and configurable precision. Operations will use enough internal precision to produce a correct result at the requested precision. Precision is set by a "context" structure that accompanies the function arguments, as discussed in the next section.

More documentation omitted...

old acorn
#

float64 can't, math.Big can't, but it's not impossible. Idk maybe I got the context wrong and they were just experimenting with big numbers

little turret
#

how is fixed point, which indeed is a must for say, currency calculations, relevant to math.Pi

#

and btw big.Rat would handle 0.1 fine (1, 10) without needing another package

old acorn
#

This seemed like an example and not their actual usecase

#

I've probably misunderstood it, seeing the response from my own comment. It was a bit aggressive too, I apologize for that

little turret
#

thanks, I appreciate it