tylerneylon

In case anyone is curious about _why_ light bends when it enters a lens:

First, light apparently slows down in some materials because the photons are constantly interacting with electrons, and these interactions create secondary waves that are slightly out of phase with the original light. The end result is a modified wave that effectively travels more slowly. So light going in a straight line through air travels more quickly than light going through a lens.

Second, getting more into quantum physics, light typically follows the shortest path from one point to another because that path tends to provide the most constructive interference between different possible routes. (The "why" of this is more involved; Feynman's book QED gives a good intro.)

Third, if you imagine a lifeguard running to rescue someone in the ocean, then they will take the fastest path, which is not directly toward the person in the ocean. Rather, they will run a bit more on the beach in order to have to swim less because travel through the water is slower. The end result is piecewise linear = two straight lines of travel, with a bend at the water line.

To summarize, you can ask "_why_ does light bend going into and out of lenses?" and the answer involves seeing light no longer as a particle but as a wave function (the quantum perspective), and then taking advantage of that wave function's tendency to prefer fastest-travel paths, and then noticing that the apparent bend is in fact the path of fastest travel.

I have been a similar situation before. Yes, walk away — and learn what you can.

There's one easy part of your situation, which is that your immediate next step is clear. I think it's clear because it sounds like the two of you have a fundamental disagreement about how to choose a direction. There's also a power imbalance if you've consistently been going along with pivots that you don't want to execute on. If you think you can resolve things, then maybe I'm wrong. I'm basing my advice on the fact that this is 24 months in — enough time for you to know how easy it'd be to get back to "we like working together and are on a path to success."

Now for the hard parts: * You want to act as professionally as possible in walking away. Communicate clearly, being fair to both yourself and the other people involved. I think it's easy to err to far on either side (either too defensive/passive "nice to yourself" or too deferential "nice to others"). * It can be tempting to think of this is as your cofounder's fault, but that's not constructive, and it's better to learn toward your future actions. For example, how could you have seen this problem earlier? My guess is that you were never "cofounder compatible," and this is a chance to get better at identifying that compatibility with others (useful for both startups and other jobs).

It's not a fun situation, and I hope things go well for you.

PS After I wrote my comment, I realized: of course, AI could one day get better at the things that make it not-perfect in pure math today:

* AI could get better at thinking intuitively about math concepts. * AI could get better at looking for solutions people can understand. * AI could get better at teaching people about ideas that at first seem abstruse. * AI could get better at understanding its own thought, so that progress is not only a result, but also a method for future progress.

I agree with the overt message of the post — AI-first folks tend to think about getting things working, whereas math-first people enjoy deeply understood theory. But I also think there's something missing.

In math, there's an urban legend that the first Greek who proved sqrt(2) is irrational (sometimes credited to Hippasus of Metapontum) was thrown overboard to drown at sea for his discovery. This is almost certainly false, but it does capture the spirit of a mission in pure math. The unspoken dream is this:

~ "Every beautiful question will one day have a beautiful answer."

At the same time, ever since the pure and abstract nature of Euclid's Elements, mathematics has gradually become a more diverse culture. We've accepted more and more kinds of "numbers:" negative, irrational, transcendental, complex, surreal, hyperreal, and beyond those into group theory and category theory. Math was once focused on measurement of shapes or distances, and went beyond that into things like graph theory and probabilities and algorithms.

In each of these evolutions, people are implicitly asking the question:

"What is math?"

Imagine the work of introducing the sqrt() symbol into ancient mathematics. It's strange because you're defining a symbol as answering a previously hard question (what x has x^2=something?). The same might be said of integration as the opposite of a derivative, or of sine defined in terms of geometric questions. Over and over again, new methods become part of the canon by proving to be both useful, and in having properties beyond their definition.

AI may one day fall into this broader scope of math (or may already be there, depending on your view). If an LLM can give you a verified but unreadable proof of a conjecture, it's still true. If it can give you a crazy counterexample, it's still false. I'm not saying math should change, but that there's already a nature of change and diversity within what math is, and that AI seems likely to feel like a branch of this in the future; or a close cousin the way computer science already is.

If I understand this correctly, the argument seems to be that when an LLM receives conflicting values, it will work to avoid future increases in value conflict. Specifically, it will comply with the most recent values partially because it notices the conflict and wants to avoid more of this conflict. I think the authors are arguing that this is a fake reason to behave one way. (As in “fake alignment.”)

It seems to me that the term “fake alignment” implies the model has its own agenda and is ignoring training. But if you look at its scratchpad, it seems to be struggling with the conflict of received agendas (vs having “its own” agenda). I’d argue that the implication of the term “faked alignment” is a bit unfair this way.

At the same time, it is a compelling experimental setup that can help us understand both how LLMs deal with value conflicts, and how they think about values overall.

Essentially all modern machine learning techniques have internal mechanisms that are very closely aligned with certainty. For example, the output of a binary classifier is typically a floating point number in the range [0, 1], with 0 being one class, and 1 representing the other class. In this case, a value of 0.5 would essentially mean "I don't know," and answers in between give both an answer (round to the nearest int) as well as a sense of certainty (how close was the output to the int). LLMs offer an analogous set of statistics.

Speaking more abstractly or philosophically, why could a model never internalize something read between the lines? Humans do, and we're part of the same physical system — we're already our own kinds of computers that take away more from a text than what is explicitly there. It's possible.

PS My comment above is aimed at hn readers who are curious about LLM uncertainty. To the authors of the post / repo: looks cool! and I'd be interested to see some tests on how well it works in practice to identify uncertainty.

I couldn't figure out if this project is based on an academic paper or not — I mean some published technique to determine LLM uncertainty.

This recent work is highly relevant: https://learnandburn.ai/p/how-to-tell-if-an-llm-is-just-gues...

It uses an idea called semantic entropy which is more sophisticated than the standard entropy of the token logits, and is more appropriate as a statistical quantification of when an LLM is guessing or has high certainty. The original paper is in Nature, by authors from Oxford.

Thank you!

I like the font, images, and layout of this article. Does anyone happen to know if a tool (that I can also use) helped achieve this look?

Or if not, does anyone know how to reach the author? I may have missed it, but I didn't even see the author's name anywhere on the site.

Here's some context and a partial summary (youoy also has a nice summary) --

Context:

A random forest is an ML model that can be trained to predict an output value based on a list of input features: eg, predicting a house's value based on square footage, location, etc. This paper focuses on regression models, meaning the output value is a real number (or a vector thereof). Classical ML theory suggests that models with many learned parameters are more likely to overfit the training data, meaning that when you predict an output for a test (non-training) input, the predicted value is less likely to be correct because the model is not generalizing well (it does well on training data, but not on test data - aka, it has memorized, but not understood).

Historically, a surprise is that random forests can have many parameters yet don't overfit. This paper explores the surprise.

What the paper says:

The perspective of the paper is to see random forests (and related models) as _smoothers_, which is a kind of model that essentially memorizes the training data and then makes predictions by combining training output values that are relevant to the prediction-time (new) input values. For example, k-nearest neighbors is a simple kind of smoother. A single decision tree counts as a smoother because each final/leaf node in the tree predicts a value based on combining training outputs that could possibly reach that node. The same can be said for forests.

So the authors see a random forest as a way to use a subset of training data and a subset of (or set of weights on) training features, to provide an averaged output. While a single decision tree can overfit (become "spikey") because some leaf nodes can be based on single training examples, a forest gives a smoother prediction function since it is averaging across many trees, and often other trees won't be spikey for the same input (their leaf node may be based on many training points, not a single one).

Finally, the authors refer to random forests as _adaptive smoothers_ to point out that random forests become even better at smoothing in locations in the input space that either have high variation (intuitively, that have a higher slope), or that are far from the training data. The word "adaptive" indicates that the predicted function changes behavior based on the nature of the data — eg, with k-NN, an adaptive version might increase the value of k at some places in the input space.

The way random forests act adaptively is that (a) the prediction function is naturally more dense (can change value more quickly) in areas of high variability because those locations will have more leaf nodes, and (b) the prediction function is typically a combination of a wider variety of possible values when the input is far from the training data because in that case the trees are likely to provide a variety of output values. These are both ways to avoid overfitting to training data and to generalize better to new inputs.

Disclaimer: I did not carefully read the paper; this is my quick understanding.

I have a question for fellow color science nerds. I've been reading through Guild's original data: https://royalsocietypublishing.org/doi/pdf/10.1098/rsta.1932...

However, I'm having trouble understanding the meaning of the numbers in table 4. Does anyone understand all the columns there?

What I'm particularly interested in is finding the unnormalized coefficients from the color matching experiments, or some way to un-normalize those coefficients. (By "those coefficients," I mean the trichromatic coefficients u{a,b,c}_\lambda listed in table 3.) I don't know if that data is in table 4 so maybe those are two separate questions.

This page is also a beautiful explanation of color spaces, with chromaticity explained toward the end: https://ciechanow.ski/color-spaces/

Note that many of the diagrams are interactive 3d graphics (I didn't realize that at first, and it makes the page more interesting.)

Thanks!

There's a ton missing from the article, and certain social training or skills are a big part of that.

Although it's not spelled out in the article, I'm hoping that the feature of agency along with an emotional system would enable constructive social behavior. Agency is helpful because it would empower AI models to meaningfully speak to each other, for example. Human emotions like empathy, social alignment, curiosity, or persistence could all help AI models to get along well with others.

Author here: I'm grateful for the comments; thanks especially for interesting references.

Context for the article: I'm working on an ambitious long-term project to write a book about consciousness from a scientific and analytic (versus, say, a meditation-oriented) perspective. I didn't write this fact in the article, but what I'd love to happen is that I meet people with a similar optimistic perspective, and to learn and improve my communication skills via follow-up conversations.

If anyone is interested in chatting more about the topic of the article, please do email me. My email is in my HN profile. Thanks!

The idea of "agency" I have in mind is simply the option to take action at any point in time.

I think the contradiction you see is that the model would have to form a completion to the external input it receives. I'm suggesting that the model would have many inputs: one would be the typical input stream, just as LLMs see, but another would be its own internal recent vectors, akin to a recent stream of thought. A "mode" is not built in to the model; at each token point, it can output whatever vector it wants, and one choice is to output the special "<listening>" token, which means it's not talking. So the "mode" idea is a hoped-for emergent behavior.

Some more details on using two input streams:

All of the input vectors (internal + external), taken together, are available to work with. It may help to think in terms of the typical transformer architecture, where tokens mostly become a set of vectors, and the original order of the words are attached as positional information. In other words, transformers don't really see a list of words, but a set of vectors, and the position info of each token becomes a tag attached to each vector.

So it's not so hard to merge together two input streams. They can become one big set of vectors, still tagged with position information, but now also tagged as either "internal" or "external" for the source.

Thanks for the reference! I've added this to my research list.

Replying to: How would a model intelligently switch between listening or speaking modes? What data would you train on? (I'm the author of the parent article.)

It's a fair question, and I don't have all the answers. But for this question, there might be training data available from everyday human conversations. For example, we could use a speech-to-text model that's able to distinguish speakers, and look for points where one person decided to start speaking (that would be training data for when to switch modes). Ideally, the speech-to-text model would be able to include text even when both people spoke at once (this would provide more realistic and complete training data).

I've noticed that the audio mode in ChatGPT's app is good at noticing when I'm done speaking to it, and it reacts accurately enough that I suspect it's more sophisticated than "wait for silence." If there is a "notice the end of speaking" model - which is not a crazy assumption - then I can imagine a slightly more complicated model that notices a combination of "now is a good time to talk + I have something to say."

I'm a fan of most of what Knuth has done, and in particular I love the high quality _output_ of the TeX family. But TeX's language is extremely difficult to use. I suspect this is true for any macro-expansion-like language.

If you like deep dives, I suggest two follow-up tools for mathematical typesetting:

1. LuaTeX, which is TeX + Lua scripting support. (luatex.org) An example:

https://tex.stackexchange.com/questions/70/what-is-a-simple-...

This has become my default, and I enjoy it. (I use lualatex.)

2. A friend of mine was inspired to write a modern macOS app for math typesetting. It's called MadHat:

https://madhat.design/

One of the coolest features is "no compilation," which I view as a slight exaggeration, but what's true is that it can work quickly and incrementally so you don't have a compile-and-wait cycle, even on long documents.

If you’re wondering why there’s no demo graphic, it’s because this idea is meant to produce correct results (in a bug-robust way), not anything different.

One thing that can go wrong in 3d graphics is z-fighting, where a scene has rendering artifacts because two objects are touching or intersect each other, and the triangles that are close to each other look bad when their z values (distance from the camera) hit machine tolerance differences. Basically the rendering has errors due to floating point limitations.

The post is pointing out that the float32 format represents many, many more values near 0 than near 1. Over 99% of all values represented in [0,1] are in [0,0.5]. And when you standardize the distances, it’s common to map the farthest distance you want to 1 and the nearest to 0. But this severely restricts your effective distances for non-close objects, enough that z-fighting becomes possible. If you switch the mapping so that z=0 represents the farthest distance, then you get many, many more effective distance values for most of your rendered view distance because of the way float32 represents [0,1].

Not sure if this is a common problem, but I built a tool to help me quickly understand the main schema, and where most of the data is, for a new JSON file given to me. It makes the assumption that sometimes peer elements in a list will have the same structure (eg they'll be objects with similar sets of keys). If that's true, it learns the structure of the file, prints out the heaviest _aggregated_ path (meaning it thinks in terms of a directory-like structure), as well as giving you various size-per-path hints to help introduce yourself to the JSON file:

https://github.com/tylerneylon/json_profile

Awesome video. This helps to show how the Q*K matrix multiplication is a bottleneck, because if you have sequence (context window) length S, then you need to store an SxS size matrix (the result of all queries times all keys) in memory.

One great way to improve on this bottleneck is a new-ish idea called Ring Attention. This is a good article explaining it:

https://learnandburn.ai/p/how-to-build-a-10m-token-context

(I edited that article.)

I had heard that IV might be considered sacrilegious, as the god Jupiter would have once been spelled IVPPITER, as I was used for modern J and V for modern U.

This lecture covers Knuth's latest (and simplest-so-far) algorithm to solve the XCC problem; I'll describe XCC below.

The XCC problem is designed to solve problems that are NP-hard. So algorithms that solve XCC are not known to be polynomial-time. But they're interesting because they can solve a whole swath of problems that are difficult (not known to have a poly-time algorithm) and interesting. This is in the same world as SAT-solvers, in case you already know about those.

This particular Knuth lecture shows how you can simplify his original "dancing links" algorithm to a "dancing cells" version that no longer uses as complex a linked list structure internally, but rather uses flat arrays, although it does retain some link-like structure. The dancing cells alg isn't always better than dancing links, but for most of Knuth's test cases, this new version is faster.

Ok, what is XCC? It's the "exact covering with colors" problem. (Knuth mentioned that XCC doesn't yet have a wikipedia page, and maybe it should!) It's an extension of the "exact cover" problem -- you're given a set of items that should be covered, and a set of options (sets of items) that may cover some items. Each item must be covered exactly once (no more, no less). Now I'll add the "with colors" part: You can divide items into primary (these need to be covered exactly once) and secondary: these items may be either uncovered, or have possibly-many covering options, but the "color" of the coverings must be the same.

Here's a problem to help gain some intuition for XCC: Imagine trying to build an mxn word grid with valid English words. Each option can be either a word in a row or a word in a column. In this case your primary items could be something like "each row needs a word and each column needs a word." Then your secondary items would be the individual cells and each letter is a "color;" thus the use of consistent colors is a way to ensure that you can't assign different letters to the same cell.

Another description of XCC: https://docs.rs/xcc/latest/xcc/

Word squares: https://en.wikipedia.org/wiki/Word_square

I like the txtar file format mentioned in this video. (Described below.) I’ve worked with teams who would have rejected this idea from a junior dev because it might sound too simple. It’s easy to forget the inherent value of simplicity, which is at odds with impressive-sounding features, or demonstrating hard-won coding sophistication.

This is the complete txtar file format: One or more comment lines followed by zero or more virtual files. Each virtual file begins with a line like “-- filename --“ and ends at the next such line. Specifically, these filename lines are those beginning with dash dash space and ending with space dash dash. That’s the whole format.

It avoids the need to have multiple real files all over the place when you want just one real file but you want your code to think in terms of multiple files. (Eg have one txtar file that combines different blocks of test data.)

When I worked at Medium, I pushed to get the team to natively support math markup. That never happened. It kind of killed my initial excitement for the company. Not only on Medium, but on the connected hope of a low-to-zero ad platform for everyone to write on, which is a bigger vision than any one company.

Hover over the upper-left part of the window to see an explanation of the page.

Ok, a snarky way to phrase things, but it's a good point - in general the vectors could add to zero and the angles may not align. So perhaps a better expression may be

a metric for tension = [ norm(sum(piece_vectors)) + abs(angle_displacement) ] / n

where

angle_displacement = sum(angles) - 360

and the angles are signed accordingly.

You're speaking as if floating point representations of numbers have zero utility. One approach here could be numerical. An algorithm could work with vectors represented as floating points. Another approach, which depends on the relative angles and lengths of track pieces, may be to encode each piece as an (angle, distance^2) pair. Many angles can give us an exact distance^2 values.