331–340 of 366 posts
Here's my implementation in Go, which runs in under 5 seconds. It doesn't use anything too obscure, only the built-in maps and no external libraries. It's also the fastest solution I've tested on my M3 Pro Mac. Eager to see what beats it! https://gist.github.com/corlinp/176a97c58099bca36bcd5679e68f...
Earlier quoted context omitted.
> but unfortunately most people fail to understand that a println in the config file’s global scope is different than inside a closure for a task description. Literally no one complaining about gradle being slow is doing that. Allmost all of gradle's problems come not from people using it, but from Gradle itself. I mean, you said it yourself: in 15 years the state of their API docs is "okayish". But somehow people ar…
So what other general purpose build tool do you recommend/vouch for? I actually really like Mill, but it is very small still. I’m unaware of too many playing in the same categories as Gradle.
I know of at least one project who just wrote everything in Python because current build tools invariably suck: https://tonsky.me/blog/python-build/
Earlier quoted context omitted.
Streaming calculation of the exact median with no storage at all is non-trivial at best in the general case, and I'm not aware of any way to calculate the mode at all. Any pointers to the methods you used in your interview answers? If you came up with them on the fly, then... well, sign here for your bonus. Can you start Monday?
> Streaming calculation of the exact median with no storage at all is non-trivial at best in the general case It's not "non-trivial" it's impossible . I'm not sure why people think median can be approximated at all. You need to look at every data point and store a counter for the lesser of: (a) all possible values, or (b) all elements. Just consider a data set with 1 million ones and 999,999 zeroes. Throwing away (or…
Earlier quoted context omitted.
This is done to simulate real-world performance. Your binary is not the only binary in the system and other services may be running as well. So fastest time is the happiest path and slowest is the unluckiest. The range of remaining three is what you expect to get 99% of the time on a real world system.
But this is a contrived test, and looking for the fastest solution, so your arguments point to taking the fastest: the one with the least interference.
The test is very well designed, we may say.
Earlier quoted context omitted.
But this is a contrived test, and looking for the fastest solution, so your arguments point to taking the fastest: the one with the least interference.
Yes, the one works the fastest in average case will be the fastest in the real world, and will be the one least affected by general noise present in the system. The test is very well designed, we may say.
Earlier quoted context omitted.
Yes, the one works the fastest in average case will be the fastest in the real world, and will be the one least affected by general noise present in the system. The test is very well designed, we may say.
The one that happens to not be benchmarked at the same time as cron jobs will be the fastest in the real world...?
Earlier quoted context omitted.
It looks like the problem is dominated by reading in the data file. Some fast solutions just read the whole file into memory.
It would be a more interesting challenge if the data file were larger than the memory. I would love to see what people would come up with on some baby vm with 512 mb of ram. Even more interesting would be small ram, little local storage and a large file only available via network, I would like to see something other than http but realistically it would be http.
Earlier quoted context omitted.
Perl is always going to be much faster than Java at tasks like this. Use stdin and chomp() instead of reading each line explicitly. This is really a small, trivial task for a perl script. Even with a billion lines this is nothing for a modern cpu and perl.
/r/perl would beg to differ: https://www.reddit.com/r/perl/comments/18ygpsi/1_billion_row...
Earlier quoted context omitted.
Streaming calculation of the exact median with no storage at all is non-trivial at best in the general case, and I'm not aware of any way to calculate the mode at all. Any pointers to the methods you used in your interview answers? If you came up with them on the fly, then... well, sign here for your bonus. Can you start Monday?
> Streaming calculation of the exact median with no storage at all is non-trivial at best in the general case It's not "non-trivial" it's impossible . I'm not sure why people think median can be approximated at all. You need to look at every data point and store a counter for the lesser of: (a) all possible values, or (b) all elements. Just consider a data set with 1 million ones and 999,999 zeroes. Throwing away (or…
A quick search shows that Boost.Accumulators have several median estimation implementations available to choose from: https://www.boost.org/doc/libs/1_84_0/doc/html/accumulators/...
> Median estimation based on the P^2 quantile estimator, the density estimator, or the P^2 cumulative distribution estimator.
Here's my implementation in Go, which runs in under 5 seconds. It doesn't use anything too obscure, only the built-in maps and no external libraries. It's also the fastest solution I've tested on my M3 Pro Mac. Eager to see what beats it! https://gist.github.com/corlinp/176a97c58099bca36bcd5679e68f...