[go-nuts] Re: [Proposal] Change how gofmt formats struct fields

[Amnon Baron Cohen]

The indent man page  (for formatting C 
code) has dozens of options to allow the user to tweak the output format.

The greatest thing about gofmt great thing about gofmt is that it has no 
such options. No style options. No new vs old mode.
Gofmt just produces a single canonical format.

Let's keep it that way.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fbaf8e58-b478-497b-b8b1-2d3265f70523%40googlegroups.com.

Re: [go-nuts] [Proposal] Change how gofmt formats struct fields

[Manlio Perillo]

On Saturday, February 1, 2020 at 12:45:23 AM UTC+1, David Riley wrote:
>
> On Jan 30, 2020, at 8:46 AM, Manlio Perillo  > wrote: 
> > 
> > Yes. 
> > 
> > In fact I wrote that alignment should be done by the editor, not gofmt. 
>
> In this scenario, the editor needs to understand Go formatting and apply 
> special formatting to tabs within struct fields? I strongly discourage 
> this. 
>
> It will also make structs look TERRIBLE when viewed as plain text (witness 
> the large corpus of C code which is only legible when viewed at a specific 
> tab width because their authors used this approach). 
>
> Go's current hard-tab predilection works currently because tabs are always 
> starting at a constant left offset (0) from the start of line; this is not 
> the case in struct fields, variable declarations, etc. 
>
>
> Please don't do this.  Or make it an opt-in.  This is not a good change to 
> force on users by default. 
>
>
You are right, thanks.
I guess the only possible solution is for gofmt to not align the fields, 
using only one space character between field name and field type.


Manlio 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/993c4faa-54ea-48e1-8565-9d25986fbe7b%40googlegroups.com.

[go-nuts] fast exif delete library

[Enes Furkan Olcay]

Hi, i made a small fast exif delete library, need your contributions.
https://github.com/xis/go-dexif

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/91960b8e-0093-4ee8-968c-56fbf7d97dc8%40googlegroups.com.

[go-nuts] Re: fast exif delete library

[Tamás Gulácsi]

2020. február 1., szombat 15:41:52 UTC+1 időpontban Enes Furkan Olcay a 
következőt írta:
>
> Hi, i made a small fast exif delete library, need your contributions.
> https://github.com/xis/go-dexif
>

Please implement error checking. As is, this is a very dangerous code!
And slow.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c5db0a2d-348d-494b-abd4-2f4c56460ab8%40googlegroups.com.

[go-nuts] Re: annoing: runtime error: cgo argument has Go pointer to Go pointer

[Andreas Otto]

No, because this is a *printf *like feature and the *callSig* is the format 
and the *option[] *are the arguments, which support many different types…

Am Donnerstag, 30. Januar 2020 06:15:28 UTC+1 schrieb Tamás Gulácsi:
>
> What does "argv" hold?
>
> Can it be a concrete type, not an interface ? That would allow passing it 
> - or if you copy it to a C.malloc-ed array..
>
> ...
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ea5a73dd-984d-4b80-b86d-aa1cfd99b808%40googlegroups.com.

Re: [go-nuts] Re: keep just 2 decimal places in a float64

[cratermoon]

Perhaps I'm doing something wrong or using the library outside of its 
intended purpose, but I found that this library doesn't handle Muller's 
Recurrence correctly. For those not familiar, Muller's Recurrence is 108 - 
(815-1500/z)/y

https://play.golang.org/p/sePTgjZzHeY

See 
https://latkin.org/blog/2014/11/22/mullers-recurrence-roundoff-gone-wrong/

On Sunday, January 26, 2020 at 8:46:16 AM UTC-8, Robert Engels wrote:
>
> Which is exactly what github.com/robaho/fixed and many others do!
>
> On Jan 26, 2020, at 10:34 AM, Michael Jones  > wrote:
>
> 
> ...thus the virtue of scaled integers. scaling by 100 makes cents whole, 
> scaling by 1*100 gives four decimal places beyond that. There is 
> nothing bad about floating point despite the reputation, it's just not the 
> number system from algebra; nor is binary floating point the same as 
> decimal floating point. The problems all start with false presumptions.
>
> On Sun, Jan 26, 2020 at 8:20 AM Robert Engels  > wrote:
>
>> Just an FYI, often that is not correct. Many financial systems require 
>> fractional pennies due to the volume of transactions. Think about taxing 
>> stock exchanges the pennies add up quickly at any tax rate, so they use 
>> fractional pennies to reduce the size of the error bucket. 
>>
>> On Jan 26, 2020, at 8:50 AM, Pat Farrell > 
>> wrote:
>>
>> 
>> never use floating point if you are trying to represent money, say 
>> dollars and cents or decimal values of the euro.
>> Store the money as integer number of pennies.
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/cc852ce3-6f88-40fd-8b19-877c76deec10%40googlegroups.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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/AF9827F5-C849-4F4E-8229-005D6C9A0E03%40ix.netcom.com
>>  
>> 
>> .
>>
>
>
> -- 
>
> *Michael T. jonesmichae...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/46cadc14-9c8e-4c3a-9c6b-d0af7b621061%40googlegroups.com.

Re: [go-nuts] Re: keep just 2 decimal places in a float64

[Robert Engels]

fixed only supports 8 decimals places - fixed. Without digging into the 
algorithm I’m sure that is the source of your issue. 


> On Feb 1, 2020, at 4:03 PM, craterm...@gmail.com wrote:
> 
> 
> Perhaps I'm doing something wrong or using the library outside of its 
> intended purpose, but I found that this library doesn't handle Muller's 
> Recurrence correctly. For those not familiar, Muller's Recurrence is 108 - 
> (815-1500/z)/y
> 
> https://play.golang.org/p/sePTgjZzHeY
> 
> See https://latkin.org/blog/2014/11/22/mullers-recurrence-roundoff-gone-wrong/
> 
>> On Sunday, January 26, 2020 at 8:46:16 AM UTC-8, Robert Engels wrote:
>> Which is exactly what github.com/robaho/fixed and many others do!
>> 
 On Jan 26, 2020, at 10:34 AM, Michael Jones  wrote:
 
>>> 
>>> ...thus the virtue of scaled integers. scaling by 100 makes cents whole, 
>>> scaling by 1*100 gives four decimal places beyond that. There is 
>>> nothing bad about floating point despite the reputation, it's just not the 
>>> number system from algebra; nor is binary floating point the same as 
>>> decimal floating point. The problems all start with false presumptions.
>>> 
 On Sun, Jan 26, 2020 at 8:20 AM Robert Engels  wrote:
 Just an FYI, often that is not correct. Many financial systems require 
 fractional pennies due to the volume of transactions. Think about taxing 
 stock exchanges the pennies add up quickly at any tax rate, so they 
 use fractional pennies to reduce the size of the error bucket. 
 
>> On Jan 26, 2020, at 8:50 AM, Pat Farrell  wrote:
>> 
> 
> never use floating point if you are trying to represent money, say 
> dollars and cents or decimal values of the euro.
> Store the money as integer number of pennies.
> -- 
> 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 golan...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/cc852ce3-6f88-40fd-8b19-877c76deec10%40googlegroups.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 golan...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/AF9827F5-C849-4F4E-8229-005D6C9A0E03%40ix.netcom.com.
>>> 
>>> 
>>> -- 
>>> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/46cadc14-9c8e-4c3a-9c6b-d0af7b621061%40googlegroups.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/F99914BF-7D69-4CEF-9C00-B583615B44AD%40ix.netcom.com.

Re: [go-nuts] Re: keep just 2 decimal places in a float64

[Manlio Perillo]

Even if fixed supports 7 decimal places, those 7 decimal places should have 
the same value (after rounding) as the result provided by math.Big.
I suspect the precision loss is in the Div method: 
https://github.com/robaho/fixed/blob/master/fixed.go#L232


Manlio Perillo

On Sunday, February 2, 2020 at 12:11:08 AM UTC+1, Robert Engels wrote:
>
> fixed only supports 8 decimals places - fixed. Without digging into the 
> algorithm I’m sure that is the source of your issue. 
>
>
> On Feb 1, 2020, at 4:03 PM, crate...@gmail.com  wrote:
>
> 
> Perhaps I'm doing something wrong or using the library outside of its 
> intended purpose, but I found that this library doesn't handle Muller's 
> Recurrence correctly. For those not familiar, Muller's Recurrence is 108 
> - (815-1500/z)/y
>
> https://play.golang.org/p/sePTgjZzHeY
>
> See 
> https://latkin.org/blog/2014/11/22/mullers-recurrence-roundoff-gone-wrong/
>
> On Sunday, January 26, 2020 at 8:46:16 AM UTC-8, Robert Engels wrote:
>>
>> Which is exactly what github.com/robaho/fixed and many others do!
>>
>> On Jan 26, 2020, at 10:34 AM, Michael Jones  wrote:
>>
>> 
>> ...thus the virtue of scaled integers. scaling by 100 makes cents whole, 
>> scaling by 1*100 gives four decimal places beyond that. There is 
>> nothing bad about floating point despite the reputation, it's just not the 
>> number system from algebra; nor is binary floating point the same as 
>> decimal floating point. The problems all start with false presumptions.
>>
>> On Sun, Jan 26, 2020 at 8:20 AM Robert Engels  
>> wrote:
>>
>>> Just an FYI, often that is not correct. Many financial systems require 
>>> fractional pennies due to the volume of transactions. Think about taxing 
>>> stock exchanges the pennies add up quickly at any tax rate, so they use 
>>> fractional pennies to reduce the size of the error bucket. 
>>>
>>> On Jan 26, 2020, at 8:50 AM, Pat Farrell  wrote:
>>>
>>> 
>>> never use floating point if you are trying to represent money, say 
>>> dollars and cents or decimal values of the euro.
>>> Store the money as integer number of pennies.
>>>
>>> -- 
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/cc852ce3-6f88-40fd-8b19-877c76deec10%40googlegroups.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 golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/AF9827F5-C849-4F4E-8229-005D6C9A0E03%40ix.netcom.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>>
>> *Michael T. jonesmichae...@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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/46cadc14-9c8e-4c3a-9c6b-d0af7b621061%40googlegroups.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7e232e7a-3177-4a8a-bbcb-7271e58110b3%40googlegroups.com.

Re: [go-nuts] Re: keep just 2 decimal places in a float64

[Michael Jones]

Your expectations are wrong in the sense of being overly optimistic.

This is a chaotic attractor, under any form of rounding or precision it
will “fail” in the way you mean (and “succeed” in proving the power of a
strong attractor!)

I have this as a test at home that does each step in 32, 64, doubled
precision (~120 bit fp at 1/4 of full speed), and big. I’ll send it later
today.

No matter what you choose to do, the chaotic attractor will win.

Michael

On Sat, Feb 1, 2020 at 2:02 PM  wrote:

> Perhaps I'm doing something wrong or using the library outside of its
> intended purpose, but I found that this library doesn't handle Muller's
> Recurrence correctly. For those not familiar, Muller's Recurrence is 108
> - (815-1500/z)/y
>
> https://play.golang.org/p/sePTgjZzHeY
>
> See
> https://latkin.org/blog/2014/11/22/mullers-recurrence-roundoff-gone-wrong/
>
> On Sunday, January 26, 2020 at 8:46:16 AM UTC-8, Robert Engels wrote:
>>
>> Which is exactly what github.com/robaho/fixed and many others do!
>>
>> On Jan 26, 2020, at 10:34 AM, Michael Jones  wrote:
>>
>> ...thus the virtue of scaled integers. scaling by 100 makes cents whole,
>> scaling by 1*100 gives four decimal places beyond that. There is
>> nothing bad about floating point despite the reputation, it's just not the
>> number system from algebra; nor is binary floating point the same as
>> decimal floating point. The problems all start with false presumptions.
>>
>> On Sun, Jan 26, 2020 at 8:20 AM Robert Engels 
>> wrote:
>>
>>> Just an FYI, often that is not correct. Many financial systems require
>>> fractional pennies due to the volume of transactions. Think about taxing
>>> stock exchanges the pennies add up quickly at any tax rate, so they use
>>> fractional pennies to reduce the size of the error bucket.
>>>
>>> On Jan 26, 2020, at 8:50 AM, Pat Farrell  wrote:
>>>
>>> never use floating point if you are trying to represent money, say
>>> dollars and cents or decimal values of the euro.
>>> Store the money as integer number of pennies.
>>>
>>> --
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/cc852ce3-6f88-40fd-8b19-877c76deec10%40googlegroups.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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/AF9827F5-C849-4F4E-8229-005D6C9A0E03%40ix.netcom.com
>>> 
>>> .
>>>
>>
>>
>> --
>>
>> *Michael T. jonesmichae...@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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/46cadc14-9c8e-4c3a-9c6b-d0af7b621061%40googlegroups.com
> 
> .
>
-- 

*Michael T. jonesmichael.jo...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQzsFhP%3DwxVwAkp38HyQWDEH7ys90XSm%2BLOe%3Dct5EwhV3w%40mail.gmail.com.

Re: [go-nuts] Re: keep just 2 decimal places in a float64

[Jason E. Aten]

I appreciate the sophisticated and math conscious discussion here.

For those reading this thread in the future, I note the state of the art in 
Go at the moment seems to be this
arbitrary precision decimal library created by the CockroachDB guys for APD 
standard/postgresql conformance.
Note that arbitrary doesn't mean infinite, it means you can pick the 
precision your application needs.

https://github.com/cockroachdb/apd

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/dde824b9-f200-43df-8461-1d5fc26c1cce%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Jason E. Aten]

I miss named function arguments too.

The closest replacement I've discovered in Go is pass a struct literal, or 
pointer to such, which can then document or leave out arguments as desired. 
e.g.

type temperature struct {
  fahrenheit float64
  celciusfloat64
}

func set(temperature{celcius: 38.5}) {
   ...
}

which reads rather nicely. No need to fill in all the unused arguments, as 
they get zero values.



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f1f6e3e1-dbc8-48cb-847e-fac7cb7b46db%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Jason E. Aten]

I miss named function arguments too.

The closest replacement I've discovered in Go is pass a struct literal, or 
pointer to such, which can then document or leave out arguments as desired. 
e.g.

type temperature struct {
  fahrenheit float64
  celciusfloat64
}

// define
func set(t temparature) { ... }

// call
set(temperature{celcius: 38.5})

which reads rather nicely. No need to fill in all the unused arguments, as 
they get zero values.

It would be nice if there was language support for this idiom.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/323fda0c-5478-463e-beac-963c5d61dccb%40googlegroups.com.

[go-nuts] Any chance of not deprecating GOPATH ?

[Randall O'Reilly]

Apologies for being really slow on the uptake here, but I’m just now realizing 
that the master plan is to actually get rid of the GOPATH mode!  Is there any 
chance of possibly retaining it?  Is it too much work to maintain both modules 
and GOPATH modes?  I have absolutely no qualms with the modules and recognize 
that it is essential and a major improvement (and a huge amount of work).

But I really like GOPATH!  See: https://divan.dev/posts/gopath/ for some 
similar sentiments.

In short, GOPATH is great for simple, transparent, easy access to the source 
code, and in general it tends to work fine most of the time.  I have always 
thought of the modules as a kind of extra-hassle mode for “business types” that 
really need reproducible builds all the time, whereas “casual / lazy hackers” 
can just live in GOPATH and do just fine, especially when mostly dealing with 
their own code space (and especially across multiple packages).

So far, I’ve just been treating modules as something to update whenever I make 
an official tagged release, but that strategy seems to not work very well in 
practice, and, being lazy, have just been advising my users to turn 
GO111MODULE=off.  I’ve also generally been ignoring discussions of modules and 
apologize if this is a retread — just point me to the relevant discussion 
(didn’t find it in a quick search, except maybe in golang issues which are too 
long!)

Has someone written a short guide to replicate the “live source” mode of GOPATH 
within modules, so you can easily be updating code across multiple packages 
(and repositories) without having to do a lot of extra work to get one package 
to use the current version of the other etc?  That at least would be super 
handy, if it is possible.

- Randy

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/BAA3A299-9EC9-4A8F-9A44-9F6098CB618B%40gmail.com.

Re: [go-nuts] Re: keep just 2 decimal places in a float64

[Michael Jones]

As promised, some careful results from one of the tests in my
doubled-precision library.

Rows are iteration's of Jean-Michel Muller's roundoff-intolerant Œ()
function:

http://perso.ens-lyon.fr/jean-michel.muller/

Columns are 32-bit floating point,64-bit floating point, my fast 128-bit
library, Go big float, and Go rationals (printed as float)

Answers are good for a while, and then fail as they must. compare always to
the right column.

Also, Dr. Kahan on the topic -- always read his every word!

How Futile are Mindless Assessments of Roundoff In Floating-Point
Computation ?
Professor W. Kahan
§ 5, page 14
https://www.cs.berkeley.edu/~wkahan/Mindless.pdf


=== RUN   TestMuller
  0:   4.0   4.00
+4.000e+00 4.000
4.00…
  1:   4.25000   4.25
+4.250e+00 4.250
4.25…
  2:   4.470588684   4.470588235294115975
+4.4705882352941176470588235294117e+00 4.4705882352941176470588235294118
4.4705882352941176470588235294117647058823529411764705882352941176470588…
  3:   4.644744873   4.644736842105217534
+4.6447368421052631578947368421047e+00 4.6447368421052631578947368421053
4.6447368421052631578947368421052631578947368421052631578947368421052632…
  4:   4.770706177   4.770538243625082941
+4.7705382436260623229461756373816e+00 4.7705382436260623229461756373938
4.7705382436260623229461756373937677053824362606232294617563739376770538…
  5:   4.859214783   4.855700712568562949
+4.8557007125890736342042755341875e+00 4.8557007125890736342042755344418
4.8557007125890736342042755344418052256532066508313539192399049881235154…
  6:   4.983123779   4.910847498660629640
+4.9108474990827932004402592585550e+00 4.9108474990827932004402592637887
4.9108474990827932004402592637886755533814357343769108474990827932004403…
  7:   6.395431519   4.945537395530507752
+4.9455374041239167247733836966321e+00 4.9455374041239167247733838031676
4.9455374041239167247733838031676461798983962546070325729654348042633728…
  8:  27.632629395   4.966962408040998866
+4.9669625817627005987119363335665e+00 4.9669625817627005987119384872579
4.9669625817627005987119384872578590383346845054961655244646085209448470…
  9:  86.993759155   4.980042204293013697
+4.9800457013556311612685646399287e+00 4.9800457013556311612686079942904
4.9800457013556311612686079942903718963021236734644222853921922457735370…
 10:  99.255508423   4.987909232795786352
+4.9879794484783922601392624051427e+00 4.9879794484783922601401328939769
4.987979448478392260140132893976940072111033913186330660946103656976…
 11:  99.962585449   4.991362641314552206
+4.9927702880620680974721416957309e+00 4.9927702880620680974895925483283
4.9927702880620680974895925483282696604561239860070565468956074766812844…
 12:  99.998130798   4.967455095552267608
+4.9956558915066340262745164361610e+00 4.9956558915066340266240282615671
4.9956558915066340266240282615670560447223264138375322338595040105640829…
 13:  99.08447   4.429690498308829660
+4.9973912683813441058976817599037e+00 4.9973912683813441128938690216426
4.9973912683813441128938690216425944791795065582105346913888017869771418…
 14: 100.0  -7.817236578459315410
+4.9984339439448167790186456309858e+00 4.9984339439448169190138971781902
4.9984339439448169190138971781902382881448247682045125641413593279228615…
 15: 100.0 168.939167671064581100
+4.9990600719708910670530314075958e+00 4.9990600719708938678168396062869
4.9990600719708938678168396062869249162956010827138675312945769521384463…
 16: 100.0 102.039963152059272034
+4.9994359371467831224113039612204e+00 4.9994359371468391479978508864998
4.9994359371468391479978508864997899689960802031068986343509970885820809…
 17: 100.0 100.099947516249699220
+4.9996615241026469022949297281691e+00 4.9996615241037675377868879857271
4.9996615241037675377868879857270921122953326315959962489248369318086283…
 18: 100.0 100.004992040972439327
+4.9997969006910037174292363662054e+00 4.9997969007134179126629930746330
4.9997969007134179126629930746330014204806141590496819671038715851326606…
 19: 100.0 100.000249579237305397
+4.9998781350296295179302235821482e+00 4.9998781354779312492317320300204
4.9998781354779312492317320300204045157850179321411177471298083841044938…
 20: 100.0 100.12478620163847
+4.268705383513445350585201744e+00 4.268795045999044664529810255
4.268795045999044664529810255297667014507019629318651153480676099193…
 21: 100.0 100.00623921607712
+4.559477336189227766623157740e+00 4.561270611577381190152822945
4.561270611577381190152822944886054388799381889725655444194135741792…
 22: 100.0 100.00031195796169
+4.700894239992550386653856177e+00 4.736760057124445790151493568
4.7367600571244457901514935676437

Re: [go-nuts] Re: keep just 2 decimal places in a float64

[Michael Jones]

forgot the code...final test is what generates the report above.

float128.go: https://play.golang.org/p/2MzjllLC3qT
float128_test.go: https://play.golang.org/p/ZQwsFh0_Apt

On Sat, Feb 1, 2020 at 7:32 PM Michael Jones 
wrote:

> As promised, some careful results from one of the tests in my
> doubled-precision library.
>
> Rows are iteration's of Jean-Michel Muller's roundoff-intolerant Œ()
> function:
>
> http://perso.ens-lyon.fr/jean-michel.muller/
>
> Columns are 32-bit floating point,64-bit floating point, my fast 128-bit
> library, Go big float, and Go rationals (printed as float)
>
> Answers are good for a while, and then fail as they must. compare always
> to the right column.
>
> Also, Dr. Kahan on the topic -- always read his every word!
>
> How Futile are Mindless Assessments of Roundoff In Floating-Point
> Computation ?
> Professor W. Kahan
> § 5, page 14
> https://www.cs.berkeley.edu/~wkahan/Mindless.pdf
>
>
> === RUN   TestMuller
>   0:   4.0   4.00
> +4.000e+00 4.000
> 4.00…
>   1:   4.25000   4.25
> +4.250e+00 4.250
> 4.25…
>   2:   4.470588684   4.470588235294115975
> +4.4705882352941176470588235294117e+00 4.4705882352941176470588235294118
> 4.4705882352941176470588235294117647058823529411764705882352941176470588…
>   3:   4.644744873   4.644736842105217534
> +4.6447368421052631578947368421047e+00 4.6447368421052631578947368421053
> 4.6447368421052631578947368421052631578947368421052631578947368421052632…
>   4:   4.770706177   4.770538243625082941
> +4.7705382436260623229461756373816e+00 4.7705382436260623229461756373938
> 4.7705382436260623229461756373937677053824362606232294617563739376770538…
>   5:   4.859214783   4.855700712568562949
> +4.8557007125890736342042755341875e+00 4.8557007125890736342042755344418
> 4.8557007125890736342042755344418052256532066508313539192399049881235154…
>   6:   4.983123779   4.910847498660629640
> +4.9108474990827932004402592585550e+00 4.9108474990827932004402592637887
> 4.9108474990827932004402592637886755533814357343769108474990827932004403…
>   7:   6.395431519   4.945537395530507752
> +4.9455374041239167247733836966321e+00 4.9455374041239167247733838031676
> 4.9455374041239167247733838031676461798983962546070325729654348042633728…
>   8:  27.632629395   4.966962408040998866
> +4.9669625817627005987119363335665e+00 4.9669625817627005987119384872579
> 4.9669625817627005987119384872578590383346845054961655244646085209448470…
>   9:  86.993759155   4.980042204293013697
> +4.9800457013556311612685646399287e+00 4.9800457013556311612686079942904
> 4.9800457013556311612686079942903718963021236734644222853921922457735370…
>  10:  99.255508423   4.987909232795786352
> +4.9879794484783922601392624051427e+00 4.9879794484783922601401328939769
> 4.987979448478392260140132893976940072111033913186330660946103656976…
>  11:  99.962585449   4.991362641314552206
> +4.9927702880620680974721416957309e+00 4.9927702880620680974895925483283
> 4.9927702880620680974895925483282696604561239860070565468956074766812844…
>  12:  99.998130798   4.967455095552267608
> +4.9956558915066340262745164361610e+00 4.9956558915066340266240282615671
> 4.9956558915066340266240282615670560447223264138375322338595040105640829…
>  13:  99.08447   4.429690498308829660
> +4.9973912683813441058976817599037e+00 4.9973912683813441128938690216426
> 4.9973912683813441128938690216425944791795065582105346913888017869771418…
>  14: 100.0  -7.817236578459315410
> +4.9984339439448167790186456309858e+00 4.9984339439448169190138971781902
> 4.9984339439448169190138971781902382881448247682045125641413593279228615…
>  15: 100.0 168.939167671064581100
> +4.9990600719708910670530314075958e+00 4.9990600719708938678168396062869
> 4.9990600719708938678168396062869249162956010827138675312945769521384463…
>  16: 100.0 102.039963152059272034
> +4.9994359371467831224113039612204e+00 4.9994359371468391479978508864998
> 4.9994359371468391479978508864997899689960802031068986343509970885820809…
>  17: 100.0 100.099947516249699220
> +4.9996615241026469022949297281691e+00 4.9996615241037675377868879857271
> 4.9996615241037675377868879857270921122953326315959962489248369318086283…
>  18: 100.0 100.004992040972439327
> +4.9997969006910037174292363662054e+00 4.9997969007134179126629930746330
> 4.9997969007134179126629930746330014204806141590496819671038715851326606…
>  19: 100.0 100.000249579237305397
> +4.9998781350296295179302235821482e+00 4.9998781354779312492317320300204
> 4.9998781354779312492317320300204045157850179321411177471298083841044938…
>  20: 100.0 100.12478620163847
> +4.268705383513445350585201744e+00 4.268795045999044664529810255
> 4.268795045999044

[go-nuts] Any chance of not deprecating GOPATH ?

[Tamás Gulácsi]

See the "replace" directive of go.mod. 
replace my/pkg => ../../my/other/pkg
Will use that other pkg instead of my/pkg.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/920b-244f-4c5a-a188-c1a723ec8d76%40googlegroups.com.

Re: [go-nuts] Any chance of not deprecating GOPATH ?

[Randall O'Reilly]

Thanks for the tip — that led me to these other relevant discussions:

* 
https://groups.google.com/forum/#!searchin/golang-nuts/gohack$20replace$20modules
* 
https://www.reddit.com/r/golang/comments/cvapcu/go_mod_how_to_get_it_to_find_packagesmodules_in/
* And now I understand the point of this tool: 
https://github.com/rogpeppe/gohack
* And here’s a very helpful tutorial: 
https://dev.to/maelvls/why-is-go111module-everywhere-and-everything-about-go-modules-24k

(It is worth noting that the official blogs don’t really address this issue — I 
just looked for “replace” in these blogs and it isn’t discussed: 
https://blog.golang.org/v2-go-modules)

The issue I’m having is well summarized from the reddit thread:

> Eg. Say I’m developing a library and a program at once. If I make changes to 
> the library, I also need to upload it to its git repo so it downloads it. 
> Alternatively, I can use the redirect. But then when I commit it to git, I 
> then need to remove the redirect line, otherwise the user who downloads the 
> program source needs to manually download the other library.
> It just makes development between two separate git repos really really 
> fucking hard. Before, I could just leave them In gopath and then I could edit 
> them both and work on them together. Then someone grabbing just the app would 
> just grab the dependency and it was done.

Given the prevalence and advantages of splitting large projects into different 
libraries & packages, the extra difficulties in dealing with this situation 
seem like a real impediment (and gohack doesn’t really solve the problem it 
seems — more for minor hacking but not for full-scale parallel development 
across packages / repos).

The current support for both GOPATH *and* modules seems like an ideal situation 
to me: there are two effective “branches” of the code (even without the extra 
hassle of git branches): the current GitHub code, and the tagged released 
versions with go.mod’s as needed for those releases.  Anyone who needs a stable 
build gets the tagged release and gets their reliable build using modules.  And 
the developers and bleeding edge folks can just live out of GOPATH as before.  
No need to remember to remove replace directives, etc — everyone’s happy (once 
you get past setting GO111MODULE appropriately)!  So maybe it could just be 
left this way :)

- Randy

> On Feb 1, 2020, at 10:50 PM, Tamás Gulácsi  wrote:
> 
> See the "replace" directive of go.mod. 
>replace my/pkg => ../../my/other/pkg
> Will use that other pkg instead of my/pkg.
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/920b-244f-4c5a-a188-c1a723ec8d76%40googlegroups.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/FDA3AE68-8C9F-4D53-B731-EB2C39517462%40gmail.com.