multiply and divide

[Michael Jones]

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 not involve real numbers, rather it uses an approximation of them. If you will copy https://play.golang.org/p/IlDxtvx7IY to your computer, build and run it, (too much CPU for the playground) you'll find that the order makes a difference. Or, you can just remember this phrase, "multiply first, then divide." 

--

Michael T. Jones
michae...@gmail.com

[jimmy frasche]

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
remember to think about it like that.

> --
> 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/d/optout.

[John Souvestre]

Ø  "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 better approach.

 

John

    John Souvestre - New Orleans LA

--

[Michael Jones]

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 +/- 308 range. (1e200 * 1e-199 * 1e180 * 1e-170 and so on).

basically...it would be nicer if they were real numbers. :-)

--

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/d/optout.

--

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/d/optout.

[Lucio]

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 design (or even ivy :-).

Lucio.

--

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/d/optout.

--
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/d/optout.

[roger peppe]

Constructive reals in Go, anyone? :-)

--

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.

[Michael Jones]

I would REALLY like to see big types as normal declarations and syntax. The SSA framework seems suitable to automatically manage the temporaries.

[jimmy frasche]

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 <michae...@gmail.com> wrote:
> 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 <rogp...@gmail.com> wrote:
>>
>> Constructive reals in Go, anyone? :-)
>>
>> On 18 Aug 2017 17:50, "Michael Jones" <michae...@gmail.com> 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)
>>>
>>> ...we might not expect much difference between the two in our code. Alas,
>>> computer floating point does not involve real numbers, rather it uses an
>>> approximation of them. If you will copy https://play.golang.org/p/IlDxtvx7IY
>>> to your computer, build and run it, (too much CPU for the playground) you'll
>>> find that the order makes a difference. Or, you can just remember this
>>> phrase, "multiply first, then divide."
>>>
>>> --
>>> Michael T. Jones
>>> michae...@gmail.com
>>>
>>> --
>>> 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/d/optout.
>
>
>
>
> --
> Michael T. Jones
> michae...@gmail.com
>

> --
> 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.

[Tamás Gulácsi]

What is an arbitrary precision float? 1/3, Pi, ✓2 ?

[Michael Jones]

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 floating point math is tricky. He does it by making each variable carry a precision, allows users to change this, and has rules for the precision of results of operations between values of same or differing precisions.

One implication of this issue is in handling something like 1/3. I have software that converts such expressions to big.rat and then once the target big.float exists with its chosen precision, does the conversion. In one of these cases I have three different extended precisions going in the same application, one for parameters (50 digits plus guard digits), one for computation (less or more depending on dynamic precision needs), and one fast and tuned doubled-precision (128-bit float) for very intensive inner computations.

Situations like this make it a little complicated for fractions and also for constants (Pi, Tau, E, ...), which are no longer constants but must be functions since they need to work more or less based on the precision of the desired result.

A little messy.

On Sat, Aug 19, 2017 at 10:03 AM, Tamás Gulácsi <tgula...@gmail.com> wrote:

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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Gulácsi Tamás]

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 great and wanted, but arbitrary precision uint and float is nonsense.

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/d/optout.