rahimiali

Direct link to the line in question:

https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5...

(@dang, worth updating the link?)

It doesn’t matter who these people are. If you’ve seen patents before, you can cause from the screenshots how similar the diagrams are to the sources.

Python's main interpreter loop is a single 4k line function.

https://github.com/python/cpython/blob/main/Python/ceval.c#L...

Many of the comments seem to interpret this to mean "don't try to craft insights into your models. instead use dumb generic models and a lot of data." That's not how I read the article.

Not all convolutional neural nets do a good job at image classification, regardless of how much data you feed them. Dense neural nets are plain just plain bad at it. Not all brute force searches over chess plays win. Not all recurrent models translate text well.

The art of incorporating insights into model is still alive and well. Without introducing "structural biases" into models, none of our current methods would work. The problem is that we've managed to introduce a lot of structural biases without understanding them well. And we should do a better job of understanding these bits of side knowledge we introduce into models.

I also agree with the main point of the article that if you're at a crossroads between introducing a very blunt structural bias (like invariance under lighting for image classifiers), you're probably better off instead throwing compute at the problem (by, say, synthetically augmenting your dataset by 10x).

The strategy is a greedy one. You're maximizing the one-step-ahead information gain. But this can end you in a spot where two steps ahead, you're only left with low information-gain moves, or at least, lower than you would have if you had planned better. Why not unroll the search a few more iterations and pick the move that maximizes average information gain k steps ahead?

Here's another way to classify this mistake. Usually, engineers first get good at "technology". Then they learn to get good at "product". Somewhere in their careers, they learn about "distribution". And then they invariable wish they had learned these lessons in the reverse order: Start with the distribution opportunity, devise a product around that opportunity, and as a last resort, some times, you need some tech to build that product.

I find the distribution->product->tech pipeline a more constructive way to think about building a business than "product-market fit", or "starting from a pain point". And it's a lot more productive than the reverse tech->product->distribution pipeline.

IDE hints like this are useful when you're writing the code, but not so useful when you're reviewing it in online code review tools.

I wish code review tool could provide this hover functionality too.

time.sleep_seconds is appealing, but this approach doesn't work when a function takes additional arguments. for example, if your function is

  poll_file_descriptors(read_descriptors, write_desciptors, timeout_in_seconds)

it would be awkward to change the name of the function just because on of the arguments happens to refer to time.

The top comments aren’t doing the article justice. The article is really about the kinds of subjects that can be covered in depth as small sections that do not have dependencies between them. It explains the value of topics that can be presented this way, then explains these articles need to publicize this fact by claiming to be lists. Seriously well argued position and I recommend reading the whole thing.

Notability the article is not about hierarchical bulleted lists.

The article explains why lists aren’t just headings on top of paragraphs. For example, the list can be read in any order. There is no dependence between them.

Doesn't the comment right below the one you linked successfully refute Danny Sullivan's claim?

I don't think you get arrested for pulling a chair?

Could someone explain what a graph-relational database is? I'm not able to extract a technical definition from the paragraph below:

"What is a graph-relational database? EdgeDB is built on an extension of the relational data model that we call the graph-relational model. This model completely eliminates the object-relational impedance mismatch while retaining the solid basis of and performance of the classic relational model. This makes EdgeDB an ideal database for application development."

In the context of this article, and I presume the parent comment, “bare metal” refers to a hosted VM (like ec2 instances) not running your own data center.

Upvoted for the subtle and relevant use of “cooke”.

Let’s say that’s the manager’s only job. But “communicating requirements in a written doc” is serious hard work, the same way “typing code in a text editor” is a lot of work. To do the former requires negotiating with other teams, understanding the limits of the audience, estimating effort, and basically developing a rough sketch of the solution in your head to make sure the request is reasonable.

This sentence stood out to me most: “executioners often claimed the clothes that their clients wore to the execution”. The word “client” is what shook me.

aren’t like 0% of car accidents caused by faulty brakes?

A lot of valid criticism here about the measure of complexity, but considering the author’s initial motivation, I think the approach makes sense: “The magazine had a little travel article, and it was written in English on one page and Thai on the other. The Thai version was so much shorter that I started to wonder if it was more efficient.”

If the goal is to identify which language would have produced the most subjectively visual “short article” per the description above, the approach sounds ok. For example, concerns with serifs, variations in character sizes, the information content of characters, etc become moot because they contribute to visual clutter and typography, which the author would want to count against the language.

Ok. What is the art of building things that are good, but violate some constraints of the real world? I’d like to use the products from that discipline.

If you’re curious how they’ve adapted SQL to query JSON, here is the trick: The JSON “Must be an array of objects. Nested object fields are ignored”.

The main interpreter loop looks a lot like python’s. It uses the same pre processor tricks and jump tables to help both the reader and the compiler to make sense of the flow. It’s also near that integers are unboxed, at the expensive of their top two bits being reserved as a type hint.

In what way is this forth-like? The opcodes take immediates and registers as arguments, whereas forth-like would be much more stack-based than this, right?

Enlightenment doesn't come from actually using LISP, I've concluded, after years of feeling dumb about it. It comes from understanding how LISP is built. Once you understand how LISP is built, you'd never actually use it for a serious project.

My key take aways from learning how LISP is built: 1) Code & data can be unified into the same thing. This isn't particularly deep if you know the concept of an AST. 2) You can bootstrap a language from a simplified version of the language. Repeat this a few times and you get a fancy language. This isn't particularly deep if you've built any compiler, or if you've built LaTeX. 3) You can build beautiful things if you disregard the grittiness of reality. LISP offers an abstraction of physical computers that does not at all resemble a real computer. Some people like this abstraction. Maybe because they don't like how computers actually work.

The lighton device accelerates random linear projections. Its input is a vector x and its output is a vector W*x, where W is a fixed random matrix. This is useful for a class of machine learning algorithms, but not frequently used in deep learning.

When someone says "I like feature F in system S", I for one appreciate the response "F is actually called F' and exists in a purer form in system S'". It broadens my view of F in two ways! There might be nicer ways to phrase the response (along with links, maybe), but I for one appreciated the direct and very googleable approach the comment you're responding to took.

The pattern appears to follow stock market hypes. First China markets: construction, then child education. And now nft/metaverse, a US hype. Given there is no actual underlying product or business, it looks like a vehicle for pump and dumps.

It's interesting to see how they introduce a new binary format in their catalogue. I was expected to find a domain specific language to define the grammar of binary bitstreams, maybe as a context free grammar. Instead, they built a nice library of routines that helps them design custom parsers by hand for each new format.

how would an invading force defend itself against this form of domestic sabotage? is the only defense to make incompetence tantamount to treason and prosecute it as a crime?

People who're familiar with Newton's method might be surprised at the convergence rate. 1/k^2 is slower than the textbook rate for Newton's method with line search, which is 2^{-2^k}, basically implying convergence in a constant number of steps. The rate in this paper seems to be no faster than plain gradient descent on a strongly convex function! So why go through the trouble of the much more complicated update?

Because the textbook proof of the fast convergence of Newton's method make additional assumptions on the objective function, for example that it is strongly convex, or it is self concordant. This paper only assumes Lipschitz continuous Hessians.

The idea of dampening the Hessian is old (it's sometimes called "damped newton method", or "trust region newton method", or "levenberg-marquardt", though the latter two refer to more specific ideas). This paper offers a view to how much dampening to apply.