Earlier quoted context omitted.
I wonder if some day there will be a video codec that is essentially a standard distribution of a very precise and extremely fast text-to-video model (like SmartTurboDiffusion-2027 or something). Because surely there are limits to text, but even the example you gave does not seem to me to be beyond the reach of a text description, given a certain level of precision and capability in the model. And we now have faster…
Maybe? To the extent that that could work, I would imagine that I, personally, would be happy reading the textual description instead of watching the video, and for me, we'd now be even closer to text wins 100% of the time. In other words, it's not that you _can't_ give excellent descriptions that would obviate the need for video, it's just that people _don't_, even, or perhaps even especially, when they think they d…
Always bet on text (2014)
181–187 of 187 posts
Re: Always bet on text (2014)
#182Earlier quoted context omitted.
This doesn’t track for me. How can text have lower bandwidth but higher meaning-per-bit? How does that jibe with entropy resistance (in an information theoretic sense)? Text seems worse to me. First of all, binary encodings are a superset of text encodings. But less abstractly, binary enables content-transparent compression and error correction. Like other commenters have pointed out, the downside of binary is needin…
Human-readability is the ultimate error correction for the most expensive link in the system: the human-in-the-loop. The information-theoretic justification is that binary's efficiency assumes a perfectly known codec, but the entropy of time destroys codecs (bit rot/obsolescence). Text sacrifices transmission efficiency for semantic recovery - it remains decodable even when the specific tooling is lost, making it the…
This may be true if you mean text written on a physical medium (especially if it's engraved in stone or clay), but it's not true at all if you mean text stored in a computer medium. Text is just binary with a dedicated codec. Good luck interpreting Chinese plain text files after humanity has forgotten about Unicode and UTF-8.
While text-based representations may be easier to decipher than random binary data even without knowing the encoding (as in an archeological setting), it's hardly going to be the easiest. Bitmaps, for example, have a much more limited set of symbols than Unicode, so I'd bet it would be much easier to display a long lost .bmp file than a random .txt file even a few hundred years from now. Same goes for raw audio, too. Now, JPEG and MP3 might be much more difficult, because the encoding is doing much more work.
Re: Always bet on text (2014)
#183Re: Always bet on text (2014)
#184A computer program would process this graph to schedule the courses so there are no conflicts or few conflicts. In other words, it would try to satisfy as many students as possible. This is in contrast with the term "graph" that one saw in high school or junior high school; that represents a function. An example would be the line chart where the height of a child is on the y-axis with their age on their x-axis and a point representing each time their height was taken and with lines connecting one height data point to another.
All data structures can be represented as graphs. For example, a hypergraph can be represented as a graph where each hyperedge corresponds to a node and connected to the nodes to which the hyperedge. Objects in a mechanical engineering CAD system or graphics display system are often kept as the winged-edge configuration. That is, we know for each edge, the adjacent faces and for each faces, the edges. Thus, the face is a "hyperedge" with the edges in the diagram being the nodes. [3] [3] https://en.wikipedia.org/wiki/Winged_edge Stanford Technical Report STAN CS 320 Bruce G. Baumgart, "Winged Edge Polyhedron Representation" http://i.stanford.edu/pub/cstr/reports/cs/tr/72/320/CS-TR-72... Charles Eastman and Kevin Walter Geometric Modeling Using the Euler Operators , Carnegie Mellon University DRC 15-279, May 1979
Of course, any graph can be serialized. Often, that would be done in JSON or XML. ChatGPT tells me that the time to serialize a graph is O(V+E) for adjacency lists and O(V^2) for adjacency matrices. That is, any data structure represented as a collection of pointers can be converted into text in time linear to the amount of information in the data structure. Adjacency matrices are used when we want to quickly see whether one entity is connected to another; but it is at the cost of space and time to serialize.
Assume one is tracking which students are taking (or are interested in taking) which course. In the computer, the programmer can put this into a rectangular array of size CS where C is the number of courses and S is the number of students. When dumped into text naively into text, this would take space and time writing to disk proportional to CS. On the other hand, assume that this is a sparse array; on average, each student is only interested in taking 10 courses. We can represent this as a list of average size 10 for each student, or time 10S. (Or more precisely, 10S+C.) We call in computer science, the relation between students and courses as a many-many relationship.
See also: [4] https://stackoverflow.com/questions/51783/how-to-serialize-a...
That is the power of sparsity, it reduces the time from a product to a linear function. (The classic graph is a many-many relation of something to itself. That is, which island is connected to another island by a bridge, which course is connected to another one by a student interested in both, or which city is connected to another city by a direct flight.) The average number of connections for each entity to another entity is the sparsity, m. Thus, the time to write the data for a sparse representation is represented by mN where N is the number of entities (or nodes).
By a little verbal sleight of hand, we say that the many-many relationship of students courses is a graph where some nodes are labled "student" and others are represented "course."
Throughout the above discussions, I ignore the constant which is the time to write one connection to the file; in this discussion, I ignore it in most of the discussion for simplicity. Similarly, with space, there is a proportionality constant--how many bits or bytes does it take to record one student-course connection or one bridge in the island-graph example.
As an aside not relevant to my discussion but relevant to the entire discussion, I just saw a news article on storing JSON on binary. https://devclass.com/2024/01/16/sqlites-new-support-for-bina...
Re: Always bet on text (2014)
#185Earlier quoted context omitted.
Maybe? To the extent that that could work, I would imagine that I, personally, would be happy reading the textual description instead of watching the video, and for me, we'd now be even closer to text wins 100% of the time. In other words, it's not that you _can't_ give excellent descriptions that would obviate the need for video, it's just that people _don't_, even, or perhaps even especially, when they think they d…
I think it's quite obvious that any textual description that had any hope of being converted to video in this way would be entirely useless for a human mind. It wouldn't say something like "the fastener is on the under side of the chair about 3/5s of the way", it would say somerhing like "there is a square-shaped object in view 5cm from the top of the view and 120cm from the right; the object is 2cm x 2.2cm, color 0x…
You may be right, although, of course, current LLMs often do the right thing with "about 3/5ths of the way."
OTOH, as someone who has done CAD and schematic drawings by programming, I am not 100% convinced about the inevitability of unreadability.
In any case, though, the bar is not really whether any human can interpret the text, but whether the average human will interpret the text or video faster, and here, to your point, yes, the video probably still wins handily.
The closest analogy I can think of is animated math gifs like these:
https://en.wikipedia.org/wiki/User:LucasVB/Gallery
Which can be a huge aid in learning.
But this leads to another conundrum. Where do animated GIFs end and video begin? Because I could see a simple line-drawing style animated GIF being sufficient for most purposes.
Re: Always bet on text (2014)
#186Earlier quoted context omitted.
Base64 and JSON takes a lot of CPU to decode; this is where Protobuf shines (for example). Bandwidth is one thing, but the most expensive resources are RAM and CPU, and it makes sense to optimize for them by using "binary" protocols. For example, when you gzip a Base64-encoded picture, you end up 1. encoding it in base64 (takes a *lot* of CPU) and then, compressing it (again! jpeg is already compressed). I think what…
Maybe for some kind of multiplayer game which has massive bandwidth and CPU usage requirements and has to be supported by paper-thin advertising profit margins... When tiny performance improvements can mean the difference between profitable and unprofitable, then it might make sense to optimize but this... But for the vast majority of software, the cost of serializing JSON is negligible and not worth thinking about.…
Re: Always bet on text (2014)
#187Earlier quoted context omitted.
any reasonable definition of "text" should include musical notation Then many a dictionary must be unreasonable [0]: text 1. A discourse or composition on which a note or commentary is written; the original words of an author, in distinction from a paraphrase, annotation, or commentary. 6. That part of a document (printed or electronic) comprising the words [..] 7. Any communication composed of words n 1. the words o…
Anything that can be turned into a string programmatically is by definition text.
4920 646f 6e27 7420 7468 696e 6b20 796f
7520 6861 7665 2074 686f 7567 6874 2074
6872 6f75 6768 2074 6865 2069 6d70 6c69
6361 7469 6f6e 7320 6f66 2074 6861 7420
7374 6174 656d 656e 742e 2042 7574 2074
6f20 6875 6d6f 7220 796f 752c 2063 616e
2079 6f75 2073 686f 7720 6d65 2077 6865
7265 2074 6578 7420 6973 2064 6566 696e
6564 2074 6861 7420 7761 7920 616e 6420
6578 706c 6169 6e20 7768 7920 6974 2773
2062 6574 7465 7220 7468 616e 2074 6865
2064 6963 7469 6f6e 6172 7920 6465 6669
6e69 7469 6f6e 3f