I think you're reaching. Justifying the answer you want rather than the answer that is.
No, graphs do not need come from text. I've frequently hand generated graphs as my means of recording experimental output. This is a common method when high precision is not needed (because your uncertainty level is the size of your markers). But that's true for graphs in general anyways.
Importantly, graphs are better at conveying the relationship between data, rather than information about a single point. (something something - Poincaré ;)
Besides, plots aren't the only types of graphs. Try network graphs.
Besides, graphs aren't the only visual communication of data.
I'll give you an even more obvious one: CAD. Sure, you can do that in text... but it takes much more room to do and magnitudes more time to interpret. So much so that everyone is going to retranslate it into a picture. Hell, I'll draw on paper before even pulling up the software and that's not uncommon.
> CAD. Sure, you can do that in text... but it takes much more room to do and magnitudes more time to interpret.
Fascinating example for me. I do CAD... using text! My only experience with it is programmatic in openscad. We check the visualization, but only on output of the final product. For me it's dramatically easier to work with. That may be a personal defect but it's also consistent. Underneath the rendering is always data, which is text, markup, but strings of fundamental data.
And in science it's not a stretch at all that numbers come first. I'll argue you're reaching. Today no one is drawing their numbers from experiments directly on a graph. They record them digitally. In textual form typically, and then render them visually to obtain generic understanding. But also there, in the end, your conclusions (per tradition) need to be point estimates with error bounds expressible in concise textual terms. You may obtain them from looking at images but the hard truth is numerical, digital, textual.
I have tried OpenSCAD, but found it extremely limited and awkward. I much prefer parametric CAD like Fusion 360, OnShape (which I'm currently using) or FreeCAD (which has a really bad UX). And my day job is as a C++/Rust developer, so you would think that I would have good chances to prefer a textual representation.
Part of this might be OpenSCAD specifically. It is CSG based, which is really not ideal, making it hard to add things like chamfers and fillets to your model. Most OpenSCAD models I come across for 3D printing have a crude look probably because this is so hard.
But part of it is just that text for most people just isn't the right representation in this case. (If you look at the relative usage of parametric CAD to textual CAD on sites for 3D models you will see that I'm right. Also, look at what approach commercial packages offer.)
I do CAD... using text! My only experience with it is programmatic in openscad
That does not mean that the CAD drawing itself is text. It is an artifact, produced from text. Using your argument you could just as easily argue that all computer code is text, and I don't think that's a useful redefinition of the word "text".
Can you tell me more about the pipeline? Are you really starting from scratch by programming? You don't do any sketching first? I'm really having a hard time imagining doing anything reasonably complicated with this method. I'll admit that there are some advantages like guaranteeing bounds but there's so much that seems actually harder to do that way.
> They record them digitally
Like I said, it is contextually dependent. If you're recording with digital equipment to a computer, then yeah, it's just easier to record that way and dump into a plot. But if you don't have that then no. And again, even recording by hand it is still dependent.
But some data is naturally image data (pictures?). Some data is naturally in other modalities (chemical reactions? Smell? Texture? Taste?). Yes, with digital recording equipment you can argue that this is all text but at that point I'd argue you're being facetious as everything is text by that definition.
> You may obtain them from looking at images but the hard truth is numerical, digital, textual.
Here I think you have a fundamental misunderstanding and are likely limiting yourself based on your experience.
First off, not every measuring device is digital. So just that alone makes it down right false. And pretending all measurements are digital is just deceptive or naive.
Second, and I cannot stress this enough: *every single measurement is a proxy* to the thing you intend to measure.
You can't even measure a damn meter directly. You can measure distance through reference length that is an approximation of a standard distance (aka a ruler). You can measure distance through reference to an approximation of time and through the use of some known velocity, such as the speed of light through a given medium (approximating time, approximating c in the medium, approximating the medium). And so on.
What you cannot do is measure a meter directly.
And most of the things we're trying to measure, model, and approximate in modern science are far more abstract than a standard unit!
The idea that the ground truth is textual is ridiculous. That would only be true on the condition that the universe itself is running on a digital computer. Despite the universe being able to do computation, I see little reason to believe it is digital.
No, you do not need to, and will not generally be able to, describe everything that a graph conveys in text. Graphs can give you an intuitive understanding of the data that text would not be able to, simply by virtue of using other parts of the brain and requiring less short term memory. If a graph can be replaced with 5 pages of text, that doesn't mean that you get the same information from both - you're likely much more able to keep one image in your short term memory than 5 pages of text.
But a graph, which provides a view at a certain level of resolution, can often be described in a few consise statements. That's why we make them, to get a view we can condense.
No, if we can condense something in a few short statements, we don't generally bother making a graph. We exactly make graphs when something is not easily explained in words, but instead requires visualization.
Of course, not all graphs are equally information dense, and some are only used for decorative purposes more than actually conveying information. But in the general case, and especially when used well, graphs convey much more information at a glance than a short text description could.
I feel like it's more that we have statements that are "pointers" to the graph. "According to Figure 1, we see that temperature rises do to pressure." So we can summarise with words, but the intuition and proof comes from the visual medium.
Many years ago, in college, I used to volunteer for Recording For The Blind, reading various math texts aloud. I had to verbally describe every illustration in the textbook, including graphs, using a few concise statements. Not perfect, but possible.
You can describe any graph to some low level of detail, sure. But does it actually help anyone? Do people with complete blindness, for example, gain anything from hearing a description of the graph of f(x) = x as "a straight line at a 45° angle crossing the graph at 0", compared to what seeing people gain from viewing that graph?
But they are multiple different "views" into data, and I would posit that a textual view of data is no different than a graphical view, no? If you import data from a parquet file, you go straight from numbers to graphs, so I disagree that it comes from text. Both graphs and text come from information. Circles on surveys, Arduino temperature readings, counter clickers when doing surveys. Those are not just text.
To have a competitive code writer with ngrams you need more than to "scale up the ngrams" you need to have a corpus that includes all possible codes that someone would want to write. And at that point you'd be better off with a lossless full text index like an r-index. But, the lack of any generalizability in this approach, coupled with its markovian features, will make this kind of model extremely brittle. Although, it would be efficient. You just need to somehow compute all possible language before hand. tldr; language models really are reasoning and generalizing over the domain they're trained on.
The authors study a bunch of wild low rank fine tunes and discover that they share a common... low rank! ... substructure which is itself base model dependent. Humans are (genetically) the same. You need only a handful of PCs to represent the cast majority of variation. But that's because of our shared ancestry. And maybe the same thing is going on here.
> The entire reason for skin color variations is a genetic optimization for UV absorption at specific latitudes vs sunburn risks.
This seems obvious but was not confirmed by genetic evidence. The rate of adaptation turns out to be much higher than can be explained by skin cancer.
The real cause appears to be fertility. UV radiation breaks down folate (vitamin B9) in the bloodstream, and folate is critical for DNA synthesis and repair. Folate deficiency causes serious problems in pregnancy, neural tube defects like spina bifida, and may impair sperm production. So darker skin in high-UV equatorial regions likely evolved partly to protect reproductive capacity.
In the other direction, lower melanin production helps with vitamin D synthesis in lower sunlight environments. Vitamin D requires UV-B radiation to be synthesized in the skin, and melanin inhibits this. Vitamin D is also linked to fertility. It's involved in sex hormone production and has been associated with successful implantation and pregnancy outcomes.
If you're curious, check out Nina Jablonski and George Chaplin's work. Their hypothesis is that skin color evolution as fundamentally about reproductive fitness: dark enough to protect folate, light enough to synthesize vitamin D. Both nutrients affect fertility, fetal development, and offspring survival. They have an immediate primary impact on fertility and success, while skin cancer even in the most extreme environment/phenotype mismatch, has an onset after reproductive age.
Markov chains have exponential falloff in correlations between tokens over time. That's dramatically different than real text which contains extremely long range correlations. They simply can't model long range correlations. As such, they can't be guided. They can memorize, but not generalize.
As someone who developed chatbots with HMM's and the Transformers algorithms, this is a great and succinct answer. The paper, Attention Is All You Need, solved this drawback.
Difference is obviously there but nothing prevents you from undirected conditioning of long range dependencies. There’s no need to chain anything.
The problem from a math standpoint is that it’s an intractable exercise. The moment you start relaxing the joint opt problem you’ll end up at a similar place.
Just had a fantastic experience applying agentic coding to CAD. I needed to add some threads to a few blanks in a 3d print. I used computational geometry to give the agent a way to "feel" around the model. I had it convolve a sphere of the radius of the connector across the entire model. It was able to use this technique to find the precise positions of the existing ports and then add threads to them. It took a few tries to get right, but if I had the technique in mind before it would be very quick. The lesson for me is that the models need to have a way to feel. In the end, the implementation of the 3d model had to be written in code, where it's auditable. Perhaps if the agent were able to see images directly and perfectly, I never would have made this discovery.
Generative CAD has incredible potential. I've had some decent results with OpenSCAD, but it's clear that current models don't have much "common sense" when it comes to how shapes connect.
If code-based CAD tools were more common, and we had a bigger corpus to pull from, these tools would probably be pretty usable. Without this, however, it seems like we'll need to train against simulations of the physical world.
“The wonder of it—the horror of it, Sura said—was that unlike the useless wrecks of Canberra’s past, these programs still worked! And via a million million circuitous threads of inheritance, many of the oldest programs still ran in the bowels of the Qeng Ho system. Take the Traders’ method of timekeeping. The frame corrections were incredibly complex—and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely…the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind’s first computer operating systems.”
