Reading only is safe, but you will have a data race if two goroutines
access the same variable concurrently and at least one of the accesses is a
write. Here is an article that gives some rules of thumb on how to
efficiently schedule parallel computation on separate CPUs:
That's a tough one. If your interviewer is an excellent engineer without an
ego, you may want to point out that it might be better to keep concurrency
and data structures separated. Perhaps you could even tell the story of the
deprecated Java Vector class.
If your interviewer want you to show
I prefer the first line to the second, even though it requires a dot import.
*Sin*(*Pi*/2)**Sin*(*Pi*/2) + *Cos*(*Pi*)/2
*math.Sin*(*math.Sin*/2)**math.Sin*(*math.Pi*/2) + *math.Cos*(*math.Pi*)/2
But of course in this case there is an even better solution. :)
*0.5*
On Wednesday, April 4,
The philosophy of Go (in my interpretation) is that exported and unexported
identifiers are only used to describe the public interface of a package and
to guard against certain programming errors; they are not intended to be a
security measure or hide or protect any information. In fact, it's
I don't know why it's not part of the standard library, but here is a piece
of code that does the job. (It's written in a slightly roundabout way to
make sure that the constants are untyped.)
const BitsPerWord = 32 << (^uint(0) >> 63) // either 32 or 64
const (
MaxInt =
in-go.html#2>])
>
> does not print "foo magic" to the console as expected but "base magic".
>
> You can have a look at that article as it shows a solution how to get
> accomplished what you were trying to do.
>
> Am Donnerstag, 8. Februar 2018 17:47:04 U
Here is a short article about how to do OOP in Go with composition,
structurally typed interfaces and, in some special cases, embedding. I
believe this can often be a better approach than traditional OOP modeling
using inheritance. I'd love to hear you thoughts.
Inheritance and OOP: Go one
I fully understand that this can be implemented in many different ways.
That's not my question. Splitting words about "consists of" and "has a"
doesn't add much to the discussion.
On Monday, November 27, 2017 at 3:12:31 PM UTC+1, Jan Mercl wrote:
>
> On Mon, Nov
.
On Monday, November 27, 2017 at 2:58:21 PM UTC+1, Jan Mercl wrote:
>
> On Mon, Nov 27, 2017 at 2:43 PM Stefan Nilsson <trollerip...@gmail.com
> > wrote:
>
> Having a dynamic type does not imply having a/any type descriptor included
> in the value of an interface v
I see the dynamic type, which is part of every interface variable, as more
than an implementation detail. The language spec, which is typically very
careful to avoid talking about implementation issues, explicitly states
that an interface variable has a dynamic type:
Variables of interface
An interface value in Go consists of two parts: a concrete value and a type
descriptor. What is the preferred terminology when talking about this?
The language specification says "dynamic value" and "dynamic type".
However, this doesn't seem to have caught on. The term "concrete value"
seems
Oops, I missed that one.
On Monday, November 27, 2017 at 7:44:03 AM UTC+1, Miki Tebeka wrote:
>
> Thanks! I do show sort.Strings there (first one).
>
> On Saturday, November 25, 2017 at 1:31:31 PM UTC+2, Stefan Nilsson wrote:
>>
>> Very nice!
>>
>> J
Very nice!
Just one comment: you may want to use sort.Strings instead in the sorting
example.
On Saturday, November 25, 2017 at 9:39:56 AM UTC+1, Miki Tebeka wrote:
>
> Hi,
>
> To help Python people switching to Go I've created a cheatsheet -
> https://www.353.solutions/py2go/index.html
>
>
NaN is not equal to NaN. This means that if you use NaN as a key in a
map[float64]string you will not be able to retrieve it again:
https://play.golang.org/p/A7KGgoM3o6
I guess this is the way it should be, but it's still a little bit
disconcerting. What's your thoughts on this?
--
You
There is a whole bunch of interesting and efficient (both in practice and
in theory) searching and sorting algorithms that rely on bitwise
operations. Only a few weeks ago, I wrote a short text about ints and
bitwise operations:
https://github.com/yourbasic/int
It covers radix sorting,
This may not be what you want, but starting from Go 1.9 it's possible to
declare a type alias using the syntax
type MyString = string
As opposed to a type definition, an alias declaration doesn't create a new
distinct type different from the type it's created from. Type aliases are
not meant
As a Midsummer greeting from the Northern Hemisphere to all fellow
golang-nutters,
here's a text about a somewhat unusual case of functional programming in Go:
https://github.com/yourbasic/func
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
is pretty good for this one as well. Thanks for the idea
Thomas!
Stefan
On Tuesday, June 13, 2017 at 8:47:36 PM UTC+2, Stefan Nilsson wrote:
>
> That's an interesting challenge! What the algorithm really does is to
> first find a permutation that will sort the string slice, and t
ut an interface (similar to sort.Interface) which would
> permit a solution for either or both of these cases? The former should be
> fairly simple to do without sacrificing the speedup; the latter might be
> trickier.
>
> Thomas
>
>
> On Tue, Jun 13, 2017 at 6:20 AM Stefan Nilss
It's well known that radix sort can be faster than comparison-based methods
for string sorting. With that in mind, I wrote this optimized version of
MSD radix sort:
https://github.com/yourbasic/radix
It's equivalent to sort.Strings in the standard library and on my machine
it's twice as
20 matches
Mail list logo
