Re: [go-nuts] Type func binding and interfaces

> > Any code that keeps data aligned to memory page and disk page sizes is > automatically significantly faster, because misalignment automatically > doubles the amount of memory that has to be accessed to satisfy a request. > This is why Binary Heaps are way slower than B-heaps. My opinion

Re: [go-nuts] Type func binding and interfaces

Always the elements are inserted according to greater than and less than. equal can't happen. The first value inserted will be the root to begin with, but if the tree gets heavy on one side, you rotate the root to rebalance. from any given node, you know that you will find the element you are

Re: [go-nuts] Type func binding and interfaces

> > I worked for a little while on the C++ server application for the Steem > network node, and I was intending to remove a whole swathe of code relating > to protocol changes at various hard forks. The number of times I ran across > poorly ordered if/then (not even using switch!) that would

Re: [go-nuts] Type func binding and interfaces

On 25 April 2018 at 10:24, Louki Sumirniy wrote: > As you look deeper into the link discussing the B-heap you can see that > actually I am pretty much exactly following the same general structure in my > algorithm. The structure will align neatly with page

Re: [go-nuts] Type func binding and interfaces

On 25 April 2018 at 10:08, Louki Sumirniy wrote: > I think that it's not necessarily non-idiomatic to use closures instead of > interfaces in Go, it's more that Go has had interfaces longer than it's had > closures, and so more code has been written this way.

Re: [go-nuts] Type func binding and interfaces

Roger is right. A heap can be a good structure for a priority queue but not for search. That is because it is partially ordered and siblings are not in any sorted order. In any case heaps are typically implemented with a vector. Go already has a pkg for it. go doc heap. Seems like you’re doing

Re: [go-nuts] Type func binding and interfaces

As you look deeper into the link discussing the B-heap you can see that actually I am pretty much exactly following the same general structure in my algorithm. The structure will align neatly with page boundaries and that means less page faults and reduced pressure on the virtual memory mapping

Re: [go-nuts] Type func binding and interfaces

I think that it's not necessarily non-idiomatic to use closures instead of interfaces in Go, it's more that Go has had interfaces longer than it's had closures, and so more code has been written this way. In Angular 2+ you have the option of embedding HTML, CSS and TS code inside one file, or

Re: [go-nuts] Type func binding and interfaces

On 25 April 2018 at 08:05, Louki Sumirniy wrote: > https://stackoverflow.com/questions/6531543/efficient-implementation-of-binary-heaps > > Pretty much what I'm working on here is this, except with left to right sort > instead of vertical. I think this guy's work

Re: [go-nuts] Type func binding and interfaces

https://stackoverflow.com/questions/6531543/efficient-implementation-of-binary-heaps Pretty much what I'm working on here is this, except with left to right sort instead of vertical. I think this guy's work will help me iron out the performance issues. Another thing, that is more on topic more

Re: [go-nuts] Type func binding and interfaces

> > I'd suggest starting with the basic algorithm without any abstraction > (just hard-code in the type you want to store), then benchmark/tweak > the algorithm, and only then try to make it general. This is my conclusion too. Abstracting the code is a lot of churn if we’re not sure

Re: [go-nuts] Type func binding and interfaces

Reading through the wikipedia description of a heap, and especially a binary heap... it's a heap. But that's not a sexy name! Technically it's not a heap because it sorts left to right, heaps sort bottom to top. I am stripping down my code and directly declaring the struct variables as

Re: [go-nuts] Type func binding and interfaces

I spent a bit of time thinking about all the indirections in my code and decided I'm going hybrid functional/procedural on this, and minimising the visible overhead that the OOP constructs are clearly creating. One nice thing about Go's hostile attitude towards OOP is that when you find the way

Re: [go-nuts] Type func binding and interfaces

On 24 April 2018 at 12:59, Louki Sumirniy wrote: > I'll just be brief this time and hit the points quickly: > > Yes, technically it is a Complete Binary Tree but you won't find a Complete > Implementation of one anywhere, I have looked, and there isn't. The

Re: [go-nuts] Type func binding and interfaces

I'll just be brief this time and hit the points quickly: Yes, technically it is a Complete Binary Tree but you won't find a Complete Implementation of one anywhere, I have looked, and there isn't. The concept has been rejected without being tested by anyone who has considered it at least what

Re: [go-nuts] Type func binding and interfaces

On 24 April 2018 at 09:58, Louki Sumirniy wrote: > > > On Tuesday, 24 April 2018 11:15:34 UTC+3, rog wrote: >> >> On 23 April 2018 at 19:58, Louki Sumirniy >> wrote: > > >> >> > I set many of those identifiers to export because I wanted

Re: [go-nuts] Type func binding and interfaces

Looking more into "Complete" binary trees, it's somewhat relevant in that this structure probably should be pushed upwards and the upper reaches of the tree made as complete as possible. Given a random source of data to fill the tree with, the odds are that the middle values will dominate due

Re: [go-nuts] Type func binding and interfaces

I just dug into the data structure spec for Btrfs, figuring it would have trees in it, and no, they are not implemented in the way I am working here either. Yes, it may well be that I am on a wild goose chase with this, but hey, I've learned an awful lot of cool stuff now that will serve me

Re: [go-nuts] Type func binding and interfaces

On Tuesday, 24 April 2018 11:15:34 UTC+3, rog wrote: > > On 23 April 2018 at 19:58, Louki Sumirniy > wrote: > > > I set many of those identifiers to export because I wanted to keep > separate > > derived libraries that replaced the storage types embedded into

Re: [go-nuts] Type func binding and interfaces

On 23 April 2018 at 19:58, Louki Sumirniy wrote: > The type function bindings are not the problem, the problem is the fact that > despite in every other way the signatures match, they will not be found by > the compiler to bind to the type, and thus the need to

Re: [go-nuts] Type func binding and interfaces

On Mon, Apr 23, 2018 at 8:58 PM Louki Sumirniy < louki.sumirniy.stal...@gmail.com> wrote: > The type function bindings are not the problem, the problem is the fact that despite in every other way the signatures match, they will not be found by the compiler to bind to the type, and thus the need

Re: [go-nuts] Type func binding and interfaces

The type function bindings are not the problem, the problem is the fact that despite in every other way the signatures match, they will not be found by the compiler to bind to the type, and thus the need to wrap the invocations. I maybe should explain that I have had some experience

Re: [go-nuts] Type func binding and interfaces

On 22 April 2018 at 23:20, Louki Sumirniy wrote: > I essentially am trying to find an effective method in Go, preferably not > too wordy, that lets me create an abstract data type, a struct, and a set of > functions that bind to a different data type, and that I