Please note that "cappio" means "loop" (as in, for hanging people) in Italian. Not sure if it's deliberate, but perhaps it's good for you to know :)
379 karma · joined April 19, 2014
Not that I'm here to defend Quora, but this level of heat makes me wonder whether the unnamed VC has some ongoing beef with it.
While the concept "Bayesian + flat prior = frequentist" is useful to explain a high level connection between the two worlds, there is a lot more to the topic - and in my opinion, it's something that can hardly be scratched without a formal education in the field.
Which is still a very strong position, but not entirely out of the park - it's quite common (not only in statistics, of course) to encounter situations where not every prerequisite of a certain methodology is met, and yet the obtained results are usable in a practical environment.
So if I have three fields - a, b and c - and by hypothesis I want to map all possible queries in a naive way, I will need to build, at the very least, the following indexes:
[a, b, c] [a, c, b] [b, a, c] [b, c, a] [c, a, b] [c, b, a]
all of which represent a different and valid way of querying my data. Anything less than this would leave some valid query uncovered by the indexes. These are 6 indexes, which is 3! (factorial). Add a fourth field and we have 12 indexes, and so on. Hence, geometrical growth (to be fair, factorial growth is even greater than geometrical).
Which is why I'm thinking that either (i) indexes get created automatically based on the most frequent / heavy queries, or (ii) indexing works differently for DocumentDB and they are actually able to map the document space in a more efficient way (but I'd say that we lack the technical details to jump at this conclusion, at the moment).
But there are cases where you need to build the query object programmatically (and dynamically), and I believe it's a bit awkward to do that to obtain an SQL statement. But possibly it's just my personal taste :)
I don't think it would be feasible to have "indexes for everything", as the numbers involved would scale geometrically.
Aside from that, the dashboard looks really nice :)
In this case, we are not looking at a model training, we are just evaluating the outcome of a (static) algorithm. On the other hand, in the context of ML you should try to include as much information as possible in your training dataset. This is a concept that comes by in many fields, some of them just tangentially related to machine learning (e.g. excitation signals for system identification, speaking both in terms of frequency domain and differential equations).
tl;dr: there is no "training set" to speak in the presented article - hence, concepts such as overfitting and information content (of the training set) do not quite apply here.
Specifically, it looks like a linearly scalable enterprise (consulting-like: they provide custom design on demand).
How is this appealing for an investor? I'm not deeply involved in the mechanics of looking for funding, but I thought investors kind of shunned consulting startups.
I'm especially liking the title's wording.
It is basically a very friendly wrapper around several javascript engines (including V8) with powerful marshalling capabilities out of the box, and the developing team is very responsive and attentive.
I see "here is something that looks like an enum, and its possible values are gold, silver and bronze. But you can also give 10, 42 or any number as a value and it will still work".
I don't mean to be overly critical (clearly this approach has worked well for the author), but I am a bit unsure about the perceived benefits.
But doesn't this implementation kind of defy the purpose of having an enum-like functionality in the first place?
Sure, why not?