Awesome, thanks!
I just can't match "arbitrary precision" and "float" expressions: 1/3 is
rational, but can't be represented with float-like data structure.
The same problem is with arbitrary precision uint: what will ^uint-1 be?
So, arbitrary precision int and user-specified-precision float is g
Jimmy, thank you for the tip! i went there and added my modest suggestions
to the proposal.
https://github.com/golang/go/issues/19623
Tamás, you make a very important point. It is one that GRI did a very good
job of in big.Float. The question of how to specify precision for
variable-precision floa
What is an arbitrary precision float? 1/3, Pi, ✓2 ?
--
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+unsubscr...@googlegroups.com.
For more options, vi
There's https://github.com/golang/go/issues/19623 for making int
arbitrary precision in Go2 (yes, please) there could also be an
arbitrary precision float to go with float32/float64 :D
On Sat, Aug 19, 2017 at 8:04 AM, Michael Jones wrote:
> I would REALLY like to see big types as normal declarati
I would REALLY like to see big types as normal declarations and syntax. The
SSA framework seems suitable to automatically manage the temporaries.
On Sat, Aug 19, 2017 at 7:14 AM, roger peppe wrote:
> Constructive reals in Go, anyone? :-)
>
> On 18 Aug 2017 17:50, "Michael Jones" wrote:
>
>> Her
Constructive reals in Go, anyone? :-)
On 18 Aug 2017 17:50, "Michael Jones" wrote:
> Here is a minor musing from something that came up yesterday.
>
> Sometimes we see a real number expression as simple as...
>
> x*y/z
>
> ...and knowing from basic algebra that...
>
> (x*y)/z == x*(y/z)
>
> ..
You'd get pretty far if the FPU could be persuaded to treat an arbitrary FP
expression as a unit and perform optimisation and specifically isolate
mantissa and exponent internally. But it seems that FPU designers are a
long way from adopting APL as the programming language for the devices they
Integer is a different matter because of truncation. The order is
significant.
Floating point is tricky there. the fractional parts can be multiplied in
any order in terms of precision. however, the exponents add so best of all
would be a kind of alternating summation that keeps them in the +/- 30
Ø "multiply first, then divide."
While often the right method, I don’t think that it always is. Consider:
-Integer: It is as long as the product doesn’t overflow (before the
divide).
-Floating: I’m inclined to think that combining numbers of the same
magnitude first might be a
This always caught me up until I was reading TAOCP one day and Knuth
pointed out that every FP op was really "round(x OP y)"—that's when it
really clicked for me.
round(round(x * y) / z) and round(x * round(y / z)) can be different.
I've since found it much easier to reason about FP code if I can
10 matches
Mail list logo
