HN user

koningrobot

177 karma
Posts2
Comments132
View on HN

It goes further back than that. In 2014, Li Yao et al (https://arxiv.org/abs/1409.0585) drew an equivalence between autoregressive (next token prediction, roughly) generative models and generative stochastic networks (denoising autoencoders, the predecessor to difussion models). They argued that the parallel sampling style correctly approximates sequential sampling.

In my own work circa 2016 I used this approach in Counterpoint by Convolution (https://arxiv.org/abs/1903.07227), where we in turn argued that despite being an approximation, it leads to better results. Sadly being dressed up as an application paper, we weren't able to draw enough attention to get those sweet diffusion citations.

Pretty sure it goes further back than that still.

how much livestock is grown and slaughtered specifically for leather

Yes and, I would hope that the majority of leather comes from cattle that are grown and slaughtered for meat. In that case, the amount of cattle put through the meat grinder is a function of both the demand for meat and the demand for leather, but it would be unlikely to be sensitive to both at the same time. I suspect, given that meat has so much turnover whereas leather lasts a long time, that we are meat-bound rather than hide-bound.

I think you're not aware of all the available evidence. The lab leak theory does not implicate China so much as it implicates particular people in the US who intentionally moved the research to China to evade the US' ban on gain-of-function research. These same people then got to be the experts with the authority to craft the official narrative on the subject.

The most important pieces of evidence (imho) are

  - No evidence for zoonotic origin has been uncovered, *and it's not for lack of trying*.
  - Peter Daszak applied for funding with DARPA to take a bat coronavirus and insert the furin cleavage site; his proposal was rejected.
  - The cover-up started with the "proximal origins" paper: a *peer-reviewed* paper in a *respectable journal* establishing zoonotic origin with certainty in the public eye. The Fauci emails show that the authors were far from certain, and several were leaning the other way.
US Right to Know does good journalism on this and other subjects: https://usrtk.org/category/covid-19-origins
Why Lisp? 3 years ago

The one thing that I most wish Python had is Common Lisp's restartable conditions. They're like exceptions but they don't break your whole process if you don't handle them in the code. If you forgot to define a variable, you'll have the option to define it and resume computation. If you forgot to provide a value, you'll be able to provide one now and resume computation. As it is, Python just dies if something unforeseen happens, which feels like a missed opportunity given that Python is a dynamic language (for which it pays a price).

I work in ML, and launching a job on a cluster just to have it fail an hour later on a typo got old ten years ago. Being able to resume after silly mistakes would easily reduce debugging time by an order of magnitude, just because I need to run the job only once and not ten times.

I notice it mentions Ctrl-a and Ctrl-x which "increment or decrement any number after the cursor on the same line". I hate these shortcuts because several times I've accidentally pressed them (e.g. on some level thinking I'm in Spacemacs or in readline) and introduced a hard-to-find bug into my code without knowing it.

It definitely works, JAX only sees the unrolled loop:

  x = 0
  x += y
  x += y
  x += y
  x += y
  x += y
  return x
The reason you might need `jax.lax.fori_loop` or some such is if you have a long loop with a complex body. Replicating a complex body many times means you end up with a huge computation graph and slow compilation.

You made a statement about "keto diets" in the plural, and "for control of obesity" in general. An anecdote would be you relating which of this plurality of keto diets you tried and what results you found with each of them. "Keto diets [...] are effective" is a conclusion one may or may not take away from such anecdotes, but it is not itself an anecdote.

Just an anecdote: keto diets for control of obesity are so effective it feels like a hack.

I'm genuinely fascinated that you prefaced this clearly-not-an-anecdote with "just an anecdote". If it had been an anecdote, it would have been fine without the preface. Instead it's a sweeping claim that at best requires several anecdotes to support it.

I don't think the author is talking about utilitarianism at all. They're talking about compressing their moral intuitions. They already believed it's bad to kill grandma, therefore "utilitarianism" must be beaten into shape to reach the same conclusion.

The fundamental unit of (classical) utilitarianism is good/bad sensations, not right/wrong actions. If you start by taking rightness/wrongness of actions as fundamental, you are very much not doing utilitarianism.

The grandma/surgeon examples do seem to suggest that killing grandma is good or dividing up the patient is good according to utilitarianism. That may or may not be right, depending on context -- who are the people involved, what do they bring to the table, what relationships do they have with each other and with people not mentioned in the story? You can fill out these details in ways that would lead "common sense morality" to the abhorrent conclusions also, or bite their own bullet and claim "the means justify the ends" somehow.

The argument being that it was better for someone who would only projected to make it to 50 years to die early than it would be if someone who was projected to make it to 75 years died early.

That's not what it says at all. It says that being exposed to a carcinogen isn't bad if you aren't going to live long enough to suffer the consequences. Plenty of things wrong with the memo but this little observation isn't it.

Yes, I've worked with this exact algorithm before, and others like it, and it should be much worse. Better than finite diffs or reinforce, but way worse than backprop's exact gradients, to the point of being unusable. Moreover the variance of the estimate grows with the number of parameters, so it gets worse still on bigger problems.

Interesting example they chose there. It requires no fewer than three deus ex machinas: apply this trick, then apply this very particular substitution, then find another substitution. If you encountered this integral in the wild without knowing whether/how it can be solved, yes you might have tried the trick, but you wouldn't realize that it had gotten you anywhere. Would you continue on and find the just-so substitutions, or would you backtrack and try something else?

It's great that we have the tricks we have, but at the same time most nontrivial integrals are just impenetrable regardless. Any demonstration of integration techniques you find will be on an integrand that is amenable to these techniques, and will only show the straight path to the solution, not the process of finding that path. I hate integrals!

I switched back to Firefox last week and I had the same experience -- Google apps and Slack were dog slow. But after a day or so they were working fine, I imagine it's a matter of populating the cache. YMMV.

You're right what you propose is not quite equivalent to batch size 1, as you don't update the parameters until processing the entire batch.

Still, having to process the examples in a batch sequentially seems like a very costly concession to make. Traditionally the reason to use batches has been because GPU-style parallelism makes them cheap. If you take away that reason by making the computation sequential, large batches become much harder to justify. Moreover it's not clear what you gain by making the computation sequential in this way -- do you think Adam actually has trouble keeping up with mean/variance of gradients so it needs more frequent updates? I would be surprised if so.

Mine too. My main gripe with object graphs is that often you need to make arbitrary decisions about what comes "first" -- should I represent my customers as a list of `(name, address)` records or a record `(names, addresses)` of lists? This is a silly decision to have to make, and an even sillier one to have to deal with when later you need to transpose the structure to more naturally fit some other task. Relational tables sidestep this issue.

Over the years I've found that these transposition problems are a huge drag on programs, and once you recognize them you start seeing them all over the place. They make simple and obvious relational tasks into dozens of lines of nested data structure traversal and manipulation.

The notion of transposition comes from the array programming world, where a multi-dimensional array/tensor can be seen as a tree structure, whose levels may be easily reordered by transposition. I sometimes use numpy arrays for general-purpose programming; it can be very powerful with a well-chosen representation. Unfortunately array concepts basically require the data to be rectangular -- `x[i]` has the same shape as `x[j]` -- which can be hard to adapt to general problems.

My dream then is a general-purpose data structure that takes the best of both the relational and array-programming worlds: the freedom and flatness of relational tables, enriched with tacit ideas like broadcasting that make array programming so ergonomic.

This reminds me of Squire & Trapp[1] which seems to be a special case. That paper provides a way of estimating Jacobian-vector products (aka forward-mode autodiff) by adding a tiny imaginary noise vector to the input. The complex output will have the function value in the real part and the Jacobian-vector product in the imaginary part.

The cool thing is you can make the noise vector arbitrarily small (up to machine precision), so it doesn't have the issues that finite differences has. I'm not sure if the same is true of the method described in the article.

[1] Using Complex Variables to Estimate Derivatives of Real Functions, https://pdfs.semanticscholar.org/3de7/e8ae217a4214507b9abdac...