Ragib_Zaman

Answering a technical question takes more time and effort than making general comments.

Ok sure. This explains a lot. If that's the problem you're getting, then it is indeed testing basic programming skills. But the general landscape has gone far beyond this. Nowadays this solution would probably not get you the job. Instead of sorting, you should create hashmaps storing counts of each character and checking equality of the hashmaps. And if you didn't produce the hashmaps solution within 10 minutes, you would not be competitive with the hoardes of people drilling these problems and thus producing the hashmaps solution within 5 minutes. What most people here are complaining about are being expected to solve significantly harder problems within tight timeframes. If you are interested in what these ridiculous problems can be, go to Leetcode and browse the "Hard" problems.

I'm assuming you have never needed to practice these problems as you already have basic programming skills and are thus able to do every Leetcode Hard within 30 minutes of first seeing the problem?

In those subjects they choose different units so that the speed of light is 1 of that unit, but it still has that unit associated to it. So it is not dimensionless.

The speed of light has units. The fine structure constant is a dimensionless quantity, like pi.

I highly recommend watching this video:

https://youtu.be/Kvh4D_osFXs

Sunlight gives us vitamin D and nitric oxide (which improves blood flow and reduces hypertension). Vitamin D is crucial for the functioning of our immune systems, and the 1000IU dosage of many supplements is laughably small. A light skinned person in a singlet standing outside at noon for 30 minutes will produce between 10,000IU and 20,000IU in their skin. I would recommend supplementing 5,000IU vitamin D while also getting some exposure in the morning or afternoon (but avoiding the sun when it is high in the sky).

The thirst mechanism becomes less reliable with age, so older people may find those products beneficial. But yes, for most healthy young to middle aged people, "drink when you're thirsty" is generally fine. Maybe with the added subpoint that if your urine is often colored, try to drink a little more.

I think it's specific to web development, in particular it tests for performance under user load.

It's generally pretty rare for a market maker to lose money over a whole year. Colour me surprised.

Facebook's tendency to display content which reflect more extreme versions of the opinions that the user already has is probably a sizeable force behind our societies growing division. They know this, but they also know that type of content stops people from clicking off their site and drives up engagement, giving them more opportunities to advertise to you. They are a net negative to society.

There's a spectrum of roles. The role you describe is that of a trader at the extreme end (little coding ability required, manual monitoring of strategies/opportunities). But there are many traders who spend a majority of their time doing data analysis and programming while monitoring mostly automated strategies out of the corner of their eye. There are researchers who focus purely on statistics and ML projects. Some even get to spend a good portion of their time reading papers, expanding their knowledge and doing basic research, not just applying their existing knowledge to financial datasets. There are also Devs. Some work on ultra low latency systems (though this is not Jane Streets expertise). Some work on Jane Street's OCaml compiler.

Apart from the OCaml compiler, everything else is fairly typical of the spectrum of roles you can find at the very large high frequency firms. And mid-sized firms are similar yet again, minus the basic research. I would say it is definitely worth working in this industry if anything above sounds interesting to you.

Most fruit are nowhere near as healthy as most people expect they are. They have been selectively bred over many hundreds of years to be far larger, sweeter and more devoid of micronutrients than they were hundreds of years ago. The amount of sugar (especially fructose) in fruits like apples, oranges and bananas is shockingly high, and can cause or exacerbate conditions such as obesity, fatty liver, type 2 diabetes, gout and other metabolic or inflammatory diseases.

Replacing some fruit with vegetables instead, and choosing less sweet fruit like various berries or melons may be a good idea for most people.

Correct. Perhaps even more important than vitamin D is nitric oxide. The summarised advice is to avoid the sun when it is high in the sky (noon-ish), get some sun in the mornings/evenings, and supplement vitamin D. This ensures good levels of vitamin D and nitric oxide while reducing skin cancer risk.

Details here: https://youtu.be/Kvh4D_osFXs

Too much Vitamin D without sufficient Vitamin K can lead to high levels of serum calcium that are not absorbed into the bones. One function of Vitamin K is to shuttle calcium into the bones. You can often purchase combined Vitamin D and Vitamin K supplements to avoid those issues.

Vitamin D has a relatively long half life in the body, so taking a large dose weekly results in essentially the same bodily concentration as taking smaller doses daily. Some people prefer taking their doses weekly as a matter of convenience.

Which algorithm?

I used to use a LaTeX resume until a recruiter told me their ATS couldn't scan it properly :(

Another way to reduce the acidity is to mix in ground up egg shells into the ground coffee. As you brew this mixture, the calcium carbonate of the egg shells (alkaline) partially neutralises the acids from the coffee beans.

You can even combine this with the two usual methods for low acidity coffee that you mentioned (cold brewing and using dark roasts). I haven't actually tried this combo yet but I'm keen to!

I'll take a stab at it (sorry if I'm not getting to the heart of your question and wrote about things you're already familiar with). I think there are two key levels of understanding about the kernel trick (the observation that often you only ever use a "kernel function" k(x,x') which roughly measures similarity between samples, rather than all the features of the samples themselves).

> "... if there was actually a simple transformation, I would just transform it in the first place and use a linear model"

The first level of usefulness of the kernel trick is that it allows us to bypass this. Even when we know the transformation, bypassing the explicit transformation can be vastly more computationally efficient.

Say our data comes as x = (x_1, ..., x_n) but we suspect that better features would be the the second degree terms: T(x) = (x_i x_j)_{1 <= i <= j <= n}. So T maps R^n to R^{n^2}. So our data matrix could go from 10^3 wide to 10^6 wide (terrible!). And then we want to compute the inner products of two samples mapped into this higher dimensional space R^{n^2}, which will be an O(n^2) operation.

Alternatively, if we focus in on the fact that we really only need the inner product of the transformed samples (not actually the transformed samples themselves), we see that what we want is:

Sum_{1<=i<=j<=n} (x_i x_j) (x'_i x'_j) = [Sum_{1<= i <= n} x_i x'_i ]^2 = <x,x'>^2

where <x,x'> is the normal inner product in R^n. So we can define k(x,x') = <x,x'>^2, and computing k(x,x') like this is only an O(n) operation (whereas not using the kernel trick and going the explicit transformation route leads to O(n^2) operations for computing inner products in the higher dimensional space).

So we've seen that, even when the transformation to be applied is simple and known, avoiding it with the kernel trick can vastly improve the speed and memory usage of the model.

The second level of understanding the kernel trick is observing that a kernel is simply measuring similarity between two samples in some way. We can conjure kernel functions that create a notion of similarity that we want to try out (or suspect would be good for our data), without ever having to think about what kind of transformation of the data would lead to an inner product in a higher dimension space that leads to that similarity.

Let's make one right now. Say we want two samples x and x' to be similar if they are close (in R^n) and not similar if they are not close, but we really want to exaggerate this. We may imagine there's some threshold (that if two samples are 1 unit away from each other, that's quite similar, but being 3 units away isn't 1/3rd as similar but far far less similar) we really want to "peak" similarity in a tight radius. Then we could use k(x,x') = exp(- |x-x'|^2), since this only has a value near 1 if x and x' are quite close and drops off rapidly to 0 as x and x' get further apart. How rapidly should the similarity drop off as they get further apart? That's probably a parameter we may want to experiment with, let's go with k(x,x') = exp(- gamma * |x-x'|^2) instead. We've just invented Radial Basis Function (RBF) kernels (or Gaussian kernels) ! Do we have any idea what explicit transformation we would do to our data to get an inner product in a higher dimensional space that leads to this same function k(x,x')? Nope. Regardless, do we have a notion of similarity that may be very useful for our data? Yup.

So the kernel trick transforms the harder problem of thinking up a transformation to a higher dimensional space where the data can be easily separated, into the easier problem of thinking up good notions of similarity between samples. But you're right - you still need to have some type of understanding of your data to intuit what a good kernel function will be for your problem. That's part of the art (unfortunately, less of a science) of being good at training SVMs. If you have no idea at all, most people will go with a Gaussian kernel and just see how that goes. Knowing all the common kernels and when to use which is basically the SVM equivalent of hyperparameter tuning in NNs - the model doesn't learn itself which ones are good, despite that there are some common-wisdom good defaults, and you can squeeze out some extra performance by knowing how to select the good ones from experience (or brute force searching all options). I need some practice in being more concise, but hopefully some of this helps.

Not allowing multi-line lambdas is beneficial for code readability. If your lambda needs multiple lines, you should write a function.

It's useful when the object being assigned to those variables are literals instead of reference types, which in my experience is most of the time when you want to do the simultaneous assignment. When you do want to do reference types, you can do a,b = [], [].

Maybe I am misremembering the roadmap but 3nm mass production by 2022 sounds surprisingly quick to me. How will they recoup their investment into the 5nm chips they are developing in such a short tim

I used to listen/watch everything at 1.5x-2x speed but found a similar result. Now I only increase the speed if it's information I only need to process once (e.g the news) but not remember later (lectures, tutorials etc).

Along these lines, Project Euler is great.

It's brilliant really. How else would you select for people straight out of school (age), with the time (few commitments and probably no dependents) and willingness (willing to jump through arbitrary hoops before you're even their boss) to grind all variations of the interview problems, all while maintaining plausible deniability to discriminating in these ways?

As someone who graduated recently and is going through this process right now - I always thought I would be set because I'm a decent problem solver, aced all my algorithms and data structures classes and generally could solve most interview style problems I came across. I've learned that this is not enough. An organic problem solving process might involve trying several promising approaches, or starting with a suboptimal algorithm and realising improvements to it, and then you might figure out an optimal solution. In many of these interviews the time constraints can be absurd, you basically have to have done the questions or variants of them recently to be able to write down the optimal solution in your first iteration.

Today my friend had a first round online screening from Atlassian - 5 questions in 90 minutes, and none of them were trivial warm up level questions. Compound this with the fact that it's often harder to solve problems and think creatively when you're under time pressure in an interview, and you realise that your only option is to do 200+ Leetcode problems and just hope your interview overlaps with those problems.

The network that you train in that tutorial is quite small. Your networks have to get quite large before the overhead of transferring the network onto the GPU is negligible to the cost of training it. You'll see the benefit of the GPU with larger models.

> Note that we call sort O(n log n) under the assumption that addition and comparison is O(1), just like the author did with multiplication. If you’re trying to make the point that arbitrarily large inputs have non-constant complexity, you should be consistent.

I have been consistent. I agreed above that is buuble sort was one part of a program that you only call on elements of size up to 10 and the input of the program, n, is something else then the bubble sort piece is O(1). But if n refers to the size of an array input into a bubble sort, then it is not O(1). Big-O considers what happens when the size of the _input_ grows. For a comparison sort we consider what happens where the _number_ of elements goes to infinity, but the elements themselves are assumed to bounded (e.g. 32 bit ints). This ensures comparison is O(1) not matter which two elements of the array you chosen from an arbitrarily large array. I don't see why you think the addition involved in a comparison sort wouldn't be O(1) as the addition addition that is required to increment pointers by 1.

> No operations on arbitrarily large numbers are constant on the number of digits, but that is not a good model for predicting actual runtimes of actual programs that use doubles. When I use ints or longs or doubles, it is not just appropriate to use O(1) for the basic arithmetic operations, it is incorrect to assume larger complexity when that larger complexity does not apply to your program.

You're describing the common situation when analysing a program is that the input of the program is some parameter (E.g. the size of an array) and all the integer arithmetic that arises during that program is on ints or doubles, so the program executes correctly _even as_ the input grows.

The key difference for this project Euler example is that there the input n is actually an integer that we do the main arithmetic on. The point of the program is to sum integers up to n. As I've explained before, if you then say "but practically we limit n to ints so it's O(1)" then _any_ function I write whose only input is an int is O(1) and the notion is meaningless.

>By definition, big-O is for predicting the run-time growth of a specific implementation. It doesn’t directly apply to formulas. And it’s not an abstract concept that applies to arbitrary inputs that the program you’re analyzing can’t process by design. You cannot assume arbitrarily large inputs.

Time complexity is usually for specific algorithms, though it can also be studied for a general problem itself (e.g. any comparison sort is at least O(n log n), regardless of algorithm or implementation). It is precisely a concept that applies to arbitrarily large inputs, that condition is at the core of its very definition.

If I designed a hardware board that runs bubble sort on any array that fits into its 16GB of memory and gave documentation printing out its (large) constant predictable run time, that still wouldn't make it correct to say Bubble sort is a constant time operation.

>Your bubble sort example is contrived, but the answer is that it is okay to call a sort of 10 elements constant if that’s one component of a system and it doesn’t grow as the size of your input grows...if the sort inside doesn’t change as your input changes, then that piece is constant.

We aren't talking about running on 10 elements and it staying at 10 elements as the size of the input grows (that would indeed be O(1)). For the original example in the link, we are talking about a piece (arithmeticSum) whose input is n, which tautologically does grow as the size of the input grows.

I disagree. Why would it be reasonable to assume "multiplication without a specific implementation is constant"? By definition, Big-O complexity describes what happens as a certain parameter gets arbitrarily large. If we say "ok but if we restrict that parameter to common sizes, it's actually O(1)", then everything is O(1). There is some constant C where Bubble sort will sort any array that fits into your RAM within C seconds, so is it okay to call Bubble sort constant time until you use huge array methods that process arrays on your hard drive?

>...where I discover the hidden complexity of a simple programming problem.

I thought it was very ironic that soon after that sentence, the author claims the arithmeticSum method is O(1) when it is actually O(log(n) log(log(n))).

Many people seem to assume that multiplication is a constant time operation. There is actually immense "hidden complexity" in doing multiplication of arbitrarily large integers efficiently. David Harvey proved last year that multiplication of two n bit integers can be done in O(n log n). It is still an open conjecture that this is the best possible.