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)
>
> ..
gt; *From:* golan...@googlegroups.com [mailto:
>> golan...@googlegroups.com ] *On Behalf Of *Michael Jones
>> *Sent:* 2017 August 18, Fri 11:50
>> *To:* golang-nuts
>> *Subject:* [go-nuts] multiply and divide
>>
>>
>>
>> Here is a mi
John Souvestre - New Orleans LA
>
>
>
> *From:* golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com]
> *On Behalf Of *Michael Jones
> *Sent:* 2017 August 18, Fri 11:50
> *To:* golang-nuts
> *Subject:* [go-nuts] multiply and divide
>
>
>
> Here is a minor musing f
might be a better approach.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Michael Jones
Sent: 2017 August 18, Fri 11:50
To: golang-nuts
Subject: [go-nuts] multiply and divide
Here is a minor musing from
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
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)
...we might not expect much difference between the two in our code. Alas,
computer floating point does no
11 matches
Mail list logo
