usgroup

Well, their leetcode rating says something about their ability to solve novel abstract problems using computer science tooling. All other things being equal, the candidate better at that is the better candidate.

Meanwhile, it is not a complete assessment. You can do all the other things you've stated and leetcode will still add value.

It depends on how its used. For example, if you have to repeat your performance in a live interview, you'll struggle to do so. Similarly, if the employer uses a confirmatory set which the LLMs get wrong (e.g. adventofcode does that), you will struggle.

The point of leetcode et al is to measure how able you are to solve problems which you have not seen before. It is not a comprehensive evaluation but a useful part of one.

Yeah but let’s not go crazy. Linear models perform very badly on partition-able tabular data where tree models excel. They are also obviously no replacement or competition in deep learning related tasks.

Point 3 — just pick the right basis — is very difficult outside a handful of kernels that are known to work. And how are you going to extrapolate your spline for prediction for example? Linearly is usually the answer…

Point 4 — sure for differentiable functions, but most people are fitting data not functions, and if you know it’s generating function why would you bother with a linear model?

Also see Shalizi’s “Data Analysis from an Elementary Point of View” is a good introductory textbook:

https://www.stat.cmu.edu/~cshalizi/ADAfaEPoV/

It is rightly over-weight on linear and additive models and simulation. 90% of the book is useless without a computer but that is a modern truth.

That variance increases with counts certainly make more sense for count data. E.g. 5% of buses are late should imply larger variance for larger counts.

It was confusing to me too once upon a time because most distributions are designed to have a homogeneous variance.

Bare in mind that Breiman's polemic was about generative vs discriminative methods. I.e. that we should not start an analysis by thinking about how the data generation can be modelled, but instead we should start with prediction. From that vein came boosted trees, bagging, random forests, xgboost and so on: non generative black box methods.

Still today most of the classical machine learning toolbox is not generative.

+1 for “in all likelihood” but it should be stated that the book explains a third approach which doesn’t lean on either subjective or objective probability.

xgb.cv(X,y) all-the-things.

Its far from a principled statistical approach to what is supposed to be at least an observational study in every case —- and have all the caveats and preparations thereof —- but it is very easy to explain to devs, and one cannot stop the tide unfortunately.

Meta occupies the "biggest X in the world spot". It is difficult to separate controversy specific to Meta from controversy inherent in occupying that spot. I think resultantly many people are agnostic to the ethics, for whom considerations on the basis of career progress, access to high tech and so on, is a much simpler decision criteria.

The article says the same:

> For the shoppers who were being paid under the new algorithm, we found that 40 percent of workers were earning more than 10 percent less than they would have under the old algorithm. What’s more, looking at data from all geographic regions, we found that about one-third of workers were earning less than their state’s minimum wage.

> It wasn’t a clear case of wage theft, because 60 percent of workers were making about the same or slightly more under the new scheme. But we felt that it was important to shine a light on those 40 percent of workers who had gotten an unannounced pay cut through a black box transition.

Those paragraphs are then literally followed by a graph showing the conservation of fees overall but the redistribution of wages to other workers.

Seems to me that workers started cherry picking assignments leaving a bulk of orders which could not be realised, so they decided to (1) change the algorithm to avoid this, and (2) not publish it so it couldn't be gamed as easily.

I think there was no such time , not least because numerical analysis today leans on computer science to an extreme degree. I also think the two had very different development trajectories with some overlap (like much of maths).

I'm not sure the bulk of programmers are implementing CS concepts, except perhaps in a tautological sense. I think the Haskell sphere gives one a sense of what developing applications would look like if programmers really were implementing CS concepts.

There was a time when Software Engineering was the application of a branch of Mathematics called Computer Science.

Easier than most people think ... to get started, but there are relatively few masters compared to the number of practitioners.

See clpBNR with SWI Prolog for a way to use interval arithmetic in the broader scope of logic programming.

https://github.com/ridgeworks/clpBNR

In many situations, it is difficult to attribute causality to age because it is correlated with so many other things. Age brings with it kids, side quests, sleepless nights, partners, and so on. There is also a creeping apathy towards the Nth repetition of the same technical challenges which makes us less attentive to their differences. If you play chess, note how much worse at it you are when you do not focus.

As a general tip, I typically say don't take notes, don't use spell checkers, don't scribble thoughts, and so on. Young or old, these are crutches you'll only ever lean on more as time goes on. Meanwhile, you'll get better at mentally storing, organising and imagining if you do it more, or at the least, you'll retain these abilities for longer.

In SWI for example, clpfd and friends rely on attribute values and hook predicates to interject the backtracking process with their own thing. SWI provides those things so that it can be extended.

Non trivial Prolog programs which only use pure predicates and do not use cut are sparse. Yet those are also the only circumstances in which things like clpfd will work without special consideration.

Run in backwards, so they say, but not really. Most things you'll write can't run backwards. You have to write them in a special way for that to be possible, and even then what it means is that you can do a depth first search to find the value.

There are some useful extensions like clpfd and asp but really if what you're doing is solving a constraint programming problem, you're much better of with OR-tools or MiniZinc.

Prolog is beautiful. I have practically no use for it. I've struggled to find something I can do better with Prolog than other tools, but I just love it aesthetically and that's enough for me sometimes.

Prolog variables are immutable by default. Data structures are the same as the immutable functional programming counterparts (no arrays, and tree based everything). Recursion is the only way to loop. Map, filter, fold(l/r), reduce, accumulate, etc, are staple predicates.

As I said, 80% of your code, or more, will look just like a functional programme.

In my opinion, if you are after the mystical experience of understanding functional programming, you're better off learning Prolog. I think it has more to offer in terms of insight, because wrapping your head around the language only takes a couple days, but wrapping your head around its consequences is a gift which keeps on giving for quite some time.

Immutable functional programming is basically what 80% of your Prolog code will look like. The benefit is that you'll be able to understand how everything works from end-to-end.

I'm not sure knowledge of technologies is ever more than a temporary distinguishing factor. I think engineers are distinguished more substantially by a depth of understand of the fundamentals. By definition, fundamentals do not change as much and are less subject to styles and fashions.

Perhaps you're asking "where will the low hanging fruit be in 5 years time"? I think that's always difficult to answer because software tech can go from obscurity to ubiquity and back again in a short cycle. I think it is roughly like picking winners on the stock market.

We live in a time when there are many more alleged machine learning roles than real ones.

I'd argue that if you are not spending >50% of your time in model development and research then it is not a machine learning role.

I'd also say that nothing necessitates the vast majority of an ML role being about data cleaning, etc. I'd suggest that indicates that the role is de facto not a machine learning role, although it may say so on paper.

They had a neurotypical control group, their effect size is massive, and clearly separates the autistic group from the control group. They reject the null hypothesis that there is no difference between the groups, and argue from literature for an alternative hypothesis. What's the problem?

I struggle to see why one may want to use an interactive analysis toolkit via C++. Could anyone who has used ROOT enlighten me on this? I understand why you may write it in C++, but why would you want to invoke it with C++ for this sort of work?

With a fixed architecture, and a fixed dataset, as mentioned. So, a specific kind of neural network, and a fixed dataset.

Is there some work on how small a model with some specific epsilon perplexity could theoretically be? Given a fixed architecture and a fixed dataset, I presume there is a minimal number of parameters required for optimal representation.

Well if you used to have attention and now you do not, for the same proposition, then the proposition is no longer as interesting as it used to be.

This may be due to reasons specific to your proposition or it may apply to propositions generally or categorically.

You ought to find out which effect is the case for you first.

From the article: “S7 is a new OOP system being developed as a collaboration between representatives from R-Core, Bioconductor, tidyverse/Posit, ROpenSci, and the wider R community, with the goal of unifying S3 and S4 and promoting interoperability.”

It then goes on to describe what that means in depth.

Yet you’re using OOP every time you call plot, predict, summary and so on: possibly without realising.

Those response rates are fairly awful with two groups that are markedly different. Seems very likely that they’d self-select on the face of it especially if they knew what the research question was.