[go-nuts] Re: Confusing type rules

To answer the first point - the keyword is "*assignable*" here - an slice []int{1,23} is not assignable to a slice []I where I is a type of int. See https://golang.org/ref/spec#Assignability ( also golang treats slices as types in themselves ie https://golang.org/ref/spec#SliceType ) ..Howeve

[go-nuts] Re: go fmt adds newline in var declaration when comment is last line before closing bracket

forgot - https://play.golang.org/p/VWQGAXs7WM -- 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, visit h

[go-nuts] go fmt adds newline in var declaration when comment is last line before closing bracket

This : package main var ( a int b string //test c float32 //test ) func main() { } becomes : package main var ( a int b string //test c float32 //test ) func main() { } Is the extra newline between the c float and the second commented //test intentional

[go-nuts] Re: How do I test an func which depends on (pseudo)-random numbers, e.g. rand.Intn()?

> > > Also, am I seeding math.rand correctly in the Init() function? Will > seeding it in the Init() function override any seeding I do in my tests? > > You're using time.Now().UTC().UnixNano()) but time.Now().UnixNano() or time.Now().Unix() seem just as good Note UnixNano() may be beyon

[go-nuts] Re: How do I test an func which depends on (pseudo)-random numbers, e.g. rand.Intn()?

https://golang.org/pkg/math/rand/#Seed *"Seed uses the provided seed value to initialize the default Source to a deterministic state. If Seed is not called, the generator behaves as if seeded by Seed(1). "* So even without calling rand.Seed your output will be the same everytime you run the

[go-nuts] Re: What happens when appending to a slice exceeds the backing capacity?

Slightly better example to above https://play.golang.org/p/eGCw4ldGiZ both pointer checks fail, but initially the underlying arrays are the same, not so after the append. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from thi

Re: [go-nuts] Re: What happens when appending to a slice exceeds the backing capacity?

On Monday, 13 March 2017 21:14:27 UTC, Dave Cheney wrote: > > A few clarifications, b does not point to a. a and b are variables of type > []int. The value of each slice's ptr fields point to a backing array of > some capacity. > > If you append to a, this does not change th length or cap fiel

Re: [go-nuts] Re: What happens when appending to a slice exceeds the backing capacity?

On Monday, 13 March 2017 07:20:57 UTC, Jan Mercl wrote: > On Mon, Mar 13, 2017 at 8:05 AM st ov > > wrote: > > > I know it can be accessed the question relates to this > > > http://stackoverflow.com/questions/36706843/how-to-get-the-underlying-array-of-a-slice-in-go > > Let me ask what do

[go-nuts] Re: No Allman-Style, No go!

Duh .. Apologies for the previous post - I only read the first page of responses - didn't realise this discussion had extended to several pages .. it probably repeats stuff that had been said several times before. -- You received this message because you are subscribed to the Google Groups "go

[go-nuts] Re: No Allman-Style, No go!

Attempt to clarify the behaviour - your problem is happening because of the line in the specification in https://golang.org/ref/spec#Semicolons which states *When the input is broken into tokens, a semicolon is automatically inserted into the token stream immediately after a line's final to

[go-nuts] 17.3 trace.exe malware flag on win32

Not sure if this is known but I seem to be getting a malware flag on go/pkg/tool/windows_386/trace.exe ie https://golang.org/pkg/runtime/trace/ of Trojan:Win32/Skeeyah.A!rfn ie https://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?name=Trojan%3aWin32%2fSkeeyah.A!rfn when sc

[go-nuts] Re: tidy way to write a repeat-until in golang

On Saturday, 8 October 2016 20:19:37 UTC+1, Egon wrote: > > > > In this code you could use empty blocks, e.g.: > > { > i := 0 > loop: > fmt.Println(i) > if i < 10 { > i++ > goto loop > } > } > > or: > > i := 0 > { > loop: > fmt.Println(i) > if i < 10 { > i++ > goto loop > } > } > > or: > > i :=

[go-nuts] Re: tidy way to write a repeat-until in golang

If you can stomach GOTO the code : i := a loop1: //stuff //..fmt.Println(i, a, b) //stuff if i != b { i = i + b - a goto loop1 } should compile to something fairly sane without the extra variables and 'ifs' ..but it lacks local scope, and the indentation

[go-nuts] tidy way to write a repeat-until in golang

Any suggestions on a way to write a repeat until loop equivalent in golang that looks tidy currently I do : ib := true for i := a.X; i != b.X || ib; i = i + b.X - a.X { ib = false //stuff } for loops that need to be executed once under all conditions.. maybe there's neater or better way ?

[go-nuts] Re: truncate float32 to lesser precision (22 bit mantissa)

On Thursday, 22 September 2016 19:43:35 UTC+1, Jamie Clarkson wrote: > > Sure, as you say for your use case it might be best for you, and you might > need different information from the test anyway. Usually in a fast ray > tracer you'd pre-calculate the inverse of the direction components and

[go-nuts] Re: truncate float32 to lesser precision (22 bit mantissa)

Thanks for those links - I started using a something similar to what is described as Smit's algorithm (Slab method) in the Amy Williams paper. My code us subtly different to that usually given because I check the "back face" intersection first -for an early terminate ; this basically involves s

[go-nuts] Re: truncate float32 to lesser precision (22 bit mantissa)

Yes thanks. I decided on catching the missed ON (edge/corner) case at the end of the function with an extra if statement when the numerical work returns EXITS_BOX=true, ENTERS_BOX=false - then I do a relatively simple check for the 'ray' outside the box - if Ray.Origin was outside and EXITS_BO

[go-nuts] truncate float32 to lesser precision (22 bit mantissa)

ok I have a problem with rounding errors on floats which I think is unavoidable. Just as specific background this is happening for me on tests of vectors (lines) intersecting with bounding boxes (ie oblongs, axis aligned). Two code snippets shows the core of the maths.. front_n = (x_front - s.X

Re: [go-nuts] Re: Assigning +Inf to a float32 ..

On Monday, 12 September 2016 23:39:09 UTC+1, Michael Jones wrote: > > Actually, you would also want a way to say “which type of NaN” as there > are two classes and several subclasses. I wrote code for this a while back > and posted it here (IIRC). > > > yes -I'm aware of 'signalling' and 'quie

[go-nuts] Re: Another divide by zero (float) question

I see - so if I understood correctly the spec for constants disallowing divide by zero has accidentally been applied to divide by zero for float32s Does this mean there will be a fix at some distant point ? -- You received this message because you are subscribed to the Google Groups "golang-nu

[go-nuts] Another divide by zero (float) question

https://play.golang.org/p/tLSyUw1Ojq This operation is caught by the compiler a:=float32(1) / float32(0) ok This has been asked before - but not with a satisfactory answer afaict The spec says ( https://golang.org/ref/spec#Arithmetic_operators ) *The result of a floating-point or complex

Re: [go-nuts] Re: Assigning +Inf to a float32 ..

On Sunday, 11 September 2016 14:25:29 UTC+1, Ian Lance Taylor wrote: > > On Sun, Sep 11, 2016 at 6:06 AM, > > wrote: > > > > Also curious as why the implementation is as math.NaN() rather than just > > math.NaN (function/method not constant). It doesn't seem to help with a > > potential int

[go-nuts] Re: Assigning +Inf to a float32 ..

ok thanks - that seems to be them all I think the library would benefit from more 'obvious' , built in constant, or single parameterless function to generate these - more commonly as values to test output against, rather than inputs. I'll put in that request and see if it gets picked up. Also

[go-nuts] Re: Assigning +Inf to a float32 ..

afaict there is no support in /math to generate a signed zero. ? -- 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 mor

[go-nuts] Assigning +Inf to a float32 ..

ok I want to assign +Inf as a float32. Currently I work around like this : package main import ( "fmt" ) func main() { var a,b,c float32 a=1 b=0 //c=float32(1.0)/float32(0.0) //can't do it //c=+Inf //doesn't work - not a keyword c=a/b //kludge fmt.Println (a,b,c) } Couldn't find a way to do t

Re: [go-nuts] Why don't the embedded T1 and T2 clash?

On Wednesday, 7 September 2016 15:59:50 UTC+1, Jan Mercl wrote: > > On Wed, Sep 7, 2016 at 4:42 PM T L > > wrote: > > See https://golang.org/ref/spec#Selectors and explain why do you think a > clash should happen. > -- > > -j > More specifically this (in the spec) "For a value x of type T or

[go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?

agree with Korshak above In fact T L's experience reminds me very much of probably my first experience with go .. I had read the specification completely, and I thought 'thoroughly' - then immediately tried this : https://play.golang.org/p/or1Ikhr4en package main import ( "fmt" ) func main()

[go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?

Just an example to show that the compiler is not performing any sort of sub-type analysis, even on the simplest cases https://play.golang.org/p/gB2nNyROXQ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop r

[go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?

.. Maybe part of the confusion here is the difference between the representation of these slice types (ie in memory) and the definition of these slice types (in the language definition) - ? They don't exactly align - it's the language specification that is 'the barrier' to conversion in simple

[go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?

In the above "the compiler does not split slices and find the underlying representation" should say "the compiler does not split slices and find the underlying types" There's a difference - I'm not referring to the way the data is stored, but the language specification. Hope that doesn't conf

Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?

> > > Ok, the alternative of my question is: why []T2 and []T1 have different > underlying representations when T2 and T1 have the same underlying > representation? > > There is a difference - the compiler does not split slices and find the underlying representation of the non-slice part (examp

[go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?

As an aside - there is a complication to this if this (original post) were allowed/added to the language specification var ( a float32 = 1.0 aa []float32 = []float32{1.0, 2.0, 3.0} ) b := float64(a) //is ok bb := ([]float64)(aa) //not ok If the second conversion bb was allowed it wou

[go-nuts] Re: Why a **T value can't call methods of *T and T if a *T value can call methods of T?

On Friday, 26 August 2016 16:32:47 UTC+1, T L wrote: > > > > On Thursday, August 25, 2016 at 9:30:01 PM UTC+8, xiio...@gmail.com wrote: >> >> I get the original points. Though the current behaviour is in my opinion >> consistent with https://golang.org/ref/spec#Method_declarations >> "[Receiver

[go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?

*"I feel the effort is made to forbid converting []Age into []int instead now."* I don't agree that allowing this conversion would be 'easier' than not allowing. Allowing it requires the additional step of splitting/extracting from the slice the element type and checking that (for assignabilit

[go-nuts] Re: Why a **T value can't call methods of *T and T if a *T value can call methods of T?

[edit] Just retracting the statement *"if you have pointers to pointers in this context you're probably doing something wrong/unnecessary*." I made earlier - which is clearly wrong on a moments thought. Sorry.. -- You received this message because you are subscribed to the Google Groups "go

[go-nuts] Re: Why a **T value can't call methods of *T and T if a *T value can call methods of T?

I get the original points. Though the current behaviour is in my opinion consistent with https://golang.org/ref/spec#Method_declarations "[Receiver] must be of the form T or *T (possibly using parentheses) where T is a type name" and https://golang.org/ref/spec#Method_sets I can see the case for

[go-nuts] Re: Why a **T value can't call methods of *T and T if a *T value can call methods of T?

It doesn't/wouldn't seem to be any technical issue implementing methods on any depth of pointer type .. as demonstrated in the unsafe example linked from a previous related discussion (ie https://groups.google.com/forum/#!msg/golang-nuts/qf76N-uDcHA/DTCDNgaF_p4J ) It's not allowed by the speci

Re: [go-nuts] Weired or not?

This is *The method set of any other type T consists of all methods declared with receiver type T. * [me] (but not *T) and *The method set of the corresponding pointer type *T is the set of all

[go-nuts] Re: Closures vs structs with embedded functions (I call 'em pseudo-closures)

On Saturday, 13 August 2016 00:57:10 UTC+1, simon place wrote: > > aren't your "pseudo-closure"'s commonly know as "objects"? > > In languages that have "objects" (and not the structs I'm using here that serve the same function) the answer is yes. Of course this is already known eg https://www

[go-nuts] Closures vs structs with embedded functions (I call 'em pseudo-closures)

I don't think I've seen this discussed once with respect to golang, and interested to see what others think, and more generally if anyone can give insight into pratfalls for the non closure method Here's a simple program using the usual introduction to what closures can do https://play.golang.

Re: [go-nuts] bodyless functions in standard libary

Thanks - so I assume the exported function Frexp is a golang fallback if the relevant architecture assembly file isn't found (?) Is there any official (or unofficial) documentation on linking assembly from packages? -- You received this message because you are subscribed to the Google Grou

[go-nuts] Re: overflow, underflow, carry, zero etc in integer ops

On Tuesday, 12 July 2016 17:40:17 UTC+1, Uli Kunitz wrote: > > You need compare the result with one summand to detect overflow. > > See here: https://play.golang.org/p/3Uh0eFSbQW > > Programming languages usually don't provide access to machine level flags, > because they support combining multi

[go-nuts] bodyless functions in standard libary

(newb question) Bodyless functions - such as https://golang.org/src/math/frexp.go?s=469:514#L6 found in the standard library are currently mystifying me.. There's an unexported function of the same name and signature on the same file but no call to it. Is this explained somewhere (I read the

[go-nuts] Re: any way to save an image to 8-bit indexed png format?

On Wednesday, 13 July 2016 03:32:55 UTC+1, sleepy wrote: > > I need to shrink images to as small as possible with an acceptable quality. > found https://tinypng.com/ could convert the image to 8-bit indexed png, > which is best fit my requirement. > > however, I need to do this by my go program,

[go-nuts] Re: [ANN] Vermeer - physically based rendering (raytracing) with Go

> > cool -. I've been using a very simple raycaster in go for a short while > just for fun / test some visualisation ideas of mine -- one minor issue > I've had is lack of native (standard library) support for hdr colors, as > well as transparency (ie transparency != alpha blend) .. > (my jun

[go-nuts] overflow, underflow, carry, zero etc in integer ops

Is there an 'easy' way to get this cheap from integer ops eg to check for carry on addition of two uint8s I need to do something like https://play.golang.org/p/IFuQcUgJlR (best I can think of) I really wanted something like var a,b uint8 = 200,100 x,error : = a+b gives x=44, with error.carry