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

If the computation doesn’t change observable value - then it’s the same value… (when use as a key/equality) - which is why a better detection of change might be on the “value added” - but if that isn’t stored, you’ll be back to same spot. > On Feb 22, 2020, at 3:06 PM, 'simon place' via golang-n

Re: [go-nuts] Bound checks elimination hint.

On 2/23/20, Bruno Albuquerque wrote: > Would adding an explicit len() check before the loop help the > compiler in any way (can not test right now)? I don't know. Sorry. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this g

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

are you sure? surely floats can have, say, a small number added, that depending of the value, sometimes doesn't change them and sometimes does. seems to me the same issue. On Saturday, 22 February 2020 19:58:09 UTC, robert engels wrote: > > float equality is useful for determining if “something

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

float equality is useful for determining if “something changed” (e.g. the record has changed), you can also use float keys - the equality matters, the actual value not so much. > On Feb 22, 2020, at 1:50 PM, 'simon place' via golang-nuts > wrote: > > absolutely, though even an epsilon is a bi

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

absolutely, though even an epsilon is a bit of a hack IMHO. given the more ops you do the greater the potential discrepancy, and, i guess, you get a normal dist. of values, so any epsilon only has a probability of working, albeit potentially astronomically high probability. so then why even hav

Re: [go-nuts] [security] Vulnerability in golang.org/x/crypto/ssh

On Saturday, February 22, 2020 at 9:36:30 AM UTC+1, Jakob Borg wrote: > > On 20 Feb 2020, at 19:40, Filippo Valsorda > wrote: > > > Version v0.0.0-20200220183623-bac4c82f6975 of golang.org/x/crypto fixes a > vulnerability > > > Am I the only one to think that this kind of versioning is not ideal

Re: [go-nuts] help with using %q in fmt

Thanks a lot, i seem to have been a bit fixated on there already being more direct symmetry between print and scan. anyway, i hacked up something that is working as i wanted; https://play.golang.org/p/BZ437rSo5DU (when you think about it, a recursive solution was always going to need a buffer.

[go-nuts] Re: [ANN] Renderview v0.1.0 with go mod, Gio, and Fyne support

As far as Windows goes, the Shiny backend works fine to draw a pannable, zoomable image with Renderview on Windows, and as far as I am aware, requires no further dependencies. But there is still not an editable text widget in Shiny, and while I was able to find a third-party multi-line text edi

Re: [go-nuts] Bound checks elimination hint.

Fair enough. This would never happen in practice but the compiler has no way to know. Would adding an explicit len() check before the loop help the compiler in any way (can not test right now)? Concerning Swizzle: Although what I am doing is technically a color space conversion, going from RGB to

Re: [go-nuts] Bound checks elimination hint.

Ah. Now it makes more sense. I completely abstracted away overflows (again, not a scenario that would happen in practice in any case). On Sat, Feb 22, 2020 at 3:54 AM Nigel Tao wrote: > On 2/22/20, Bruno Albuquerque wrote: > > https://play.golang.org/p/P2JPI42YJa8 > > > > ... > > > > So, in thi

Re: [go-nuts] Bound checks elimination hint.

On Saturday, 22 February 2020 11:54:43 UTC, Nigel Tao wrote: > > > If the step (e.g. 3) does not divide the length evenly, then e.g. "i > += 3" can overflow such that i becomes negative, even though the > "len(a)" in the "i < len(a)" condition is a legitimate array or slice > length: a non-negat

Re: [go-nuts] Bound checks elimination hint.

On 2/22/20, Bruno Albuquerque wrote: > https://play.golang.org/p/P2JPI42YJa8 > > ... > > So, in this simplified case, if the step divides the length evenly, then > there are no bound checks. If it does not, then bound checks are inserted. > > This seems to be an unnecessary check If the step (e.g

Re: [go-nuts] Bound checks elimination hint.

On 2/22/20, Bruno Albuquerque wrote: > https://play.golang.org/p/Y7ICg7t4_nd > > ... > > Unfortunately, I could not find an incantation that would remove the bound > checks. The code from that play.golang.org link is: func NRGBA(rgbData []byte) []byte { nrgbaData := make([]byte, len

Re: [go-nuts] Preserving extra properties using JSON unmarshal / marshal?

Looks like your thoughts are the right ones: https://stackoverflow.com/questions/33436730/unmarshal-json-with-some-known-and-some-unknown-field-names -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receivin

Re: [go-nuts] [security] Vulnerability in golang.org/x/crypto/ssh

On 20 Feb 2020, at 19:40, Filippo Valsorda mailto:fili...@golang.org>> wrote: Version v0.0.0-20200220183623-bac4c82f6975 of golang.org/x/crypto fixes a vulnerability Am I the only one to think that this kind of versioning is not ideal for a module that's important (

[go-nuts] Re: [ANN] Renderview v0.1.0 with go mod, Gio, and Fyne support

For Windows, this will draw an image on screen: https://play.golang.org/p/-KDo9pHXZCj without external dependencies. It's non-interactive, but nice to just see an image. It comes in two versions: dev=SCREEN draws over the primary monitor, over everything else without borders. The image disappear