I personally like this article, its concepts, its charts and its graphs...
Observation: There probably is a market for documenting all of a business's processes and workflows (which business owner wouldn't want some really cool charts of all of their business processes?), and that should be able to done quickly and cheaply with Text-to-Image LLM's (NanoBanana, ?, ???). Well, if there's value on the one side, and the ability to deliver under cost and under budget on the other, then that's a value-to-cost asymmetry and subsequently a candidate for a scalable service business...
Yes. As someone else points out: the techniques for this exist (and have existed for decades). It was never worth it to fully pursuit it, especially for more messy human-heavy processes.
Now with AI you can get way more detailed (AI can interview humans, and you can do it in a format that doesn't feel like an interview - e.g by 'simply' having AI be a fly on the wall). AI can make sense of messy inputs and then you can present that to people who know the process, who can easily point out flaws. The flows/maps will not be perfect, but you can always get more detailed once you bump into the limitations of imperfection.
And absolutely do business leaders want maps like this. They often have no idea what exactly is happening in their org. Or they have a gut feel that there are massive inefficiencies, but they cannot get the insights into where they are because there are too many moving parts that do not effectively talk to each other (silos, politics, etc).
If we think about it, any WiFi adapter (in its most basic core functionality) is just the ability to send/receive radio at a specific frequency, and a modulation (send) and corresponding demodulation (receive) scheme on top of that.
If the modulation/demodulation can be handled by a DSP, FPGA or fast-enough CPU, then all that's really required to create a WiFi device is that and the radio component, and then of course, there are devices like "Cantennas" that could give increased range, although loss of omnidirectionality is the trade-off there...
Anyway, I never thought about the fact that different encoding methods are used relative to distance prior to reading this article (i.e., I learned something!) -- but it makes perfect sense now that I think about it!
It would be tremendously interesting, I think, to learn all of the Chemistry involved in carpet manufacturing, both historical and current-day, both for carpets which are manufactured domestically and those manufactured abroad (different regulatory frameworks = probable different and/or subtly different chemical processes)...
Now, that sounds really boring and potentially a waste of time, right?
Well, yes, and no, and yes!
Well it's complicated!
I would speculate (being horrendously undereducated on the subject!) that there probably exist a set of chemical processes which could create Carpets without any harmful environmental waste or residual chemicals which subsequently require disposal.
What these would be or could be, I as-of-yet do not know...
It's a subject that needs research... a lot of research... lots and lots of research!
But, while it might sound like a really boring, uninteresting, "there's nothing to see here" kind of goal, keep in mind this quote from the article:
>"Mohawk logged more than $3.4 billion in net sales. Shaw Industries reported $4.2 billion."
Yup, the global carpet market is worth... (wait for it!)... "Billion$"!
So -- an interesting problem for present and future Scientists/Chemists! Crack it (in whole or in part!) and your solution or partial solution could be worth Billion$!
I mean, I'd put that up against a Clay Millennium Prize for solving a complex Math problem, I'd put that against a Nobel Prize or Fields Medal or Dirac Medal or Feynman Prize!
Yup, solve The Carpet Chemistry Problem(tm) (let's give it a name!) -- and your share of Billion$ (as Carl Sagan would say!) could be yours! :-)
(I now will humbly submit this post for the obligatory yes-I-know-they-are-coming downvotes! :-) )
Now, two of those are header (.h) files, because in C the programmer typically splits units of code into headers (aka declarations), and body (aka implementation), unlike say, Pascal, where headers and implementations typically share the same file.
That is, there are really just two pieces of functionality here.
One is the file getting (uget.h, uget.c), and the other is the SSL interface to OpenSSL (ssl.h, ssl.c):
#ifdef ENABLE_SSL
#include <openssl/x509v3.h>
#include <openssl/ssl.h>
#include <openssl/err.h>
[etc.]
Now those files (and the OpenSSL dependency) are only required only because the modern web predominantly uses the encrypted SSL protocol (i.e., https) -- compare to the earlier web which predominantly used unencrypted http, where all of that extra code is basically unnecessary (but of course, you lose encryption -- that's the trade-off).
As a commercial, production-ready tool, the author is quite right that you should probably use 'wget' or 'curl' instead, but as a teaching tool (or tool to be included on a minimal educational operating system), one where simplicity, understandability and minimal lines of code are virtuous, I believe that 'uget' is quite good, heck, I'd go as far as to say 'quite excellent' at achieving the smallest codebase and the greatest understandability for the purpose!
While other HN readers may disagree with me (and are free to do so!), I have to commend the author for a great minimal utility, and job well done!
>"Stage two was RLHF training on general chat prompts using a reward model to improve helpfulness. This worked. AlpacaEval scores jumped around 18.9 points on average compared to the fine-tuned checkpoints.
Then something broke. The RLHF stage, while improving chat quality, caused math benchmark scores to drop. GSM8K and DeepMind-Math both regressed."
Observation: Math (which when fully decomposed, results in Logic) is at the core of how computers (traditional/older, non-LLM, programming languages work. If an LLM gets Math training wrong at any stage for any reason, then, in my opinion, that should be viewed as something that needs to be fixed at a lower level, not a higher one; not a later training level...
I think it would be interesting exercise to train an LLM that only deals in simple Math, simple English, and only the ability to compute simple equations (+,-,x,/)... like, what's the absolute minimum in terms of text and layers necessary to train a model like that?
I think some interesting understandings could be potentially be had by experimentation like that...
I myself would love a pure (simplest, smallest possible)
Text-to-Math only LLM (TTMLLM, TTMSLM?)
, along with all of the necessary corpuses (which would ideally be as small as possible) and instructions necessary to train such an LLM...
Yes, that's about the shape of it, thanks! By controlling variables of the env (ie removing, fixing confounding factors), you can approach a more scientific process to development and testing, and make more rapid progress toward stability :)
>"Virtually all processors today have data parallel instructions (sometimes called SIMD) that can check several values at once.
[...]
The binary search checks one value at a time. However, recent processors can load and check more than one value at once. They have excellent memory-level parllelism. This suggest that instead of a binary search, we might want to try a quaternary search..."
First of all, brilliant observations! (Overall, a great article too!)
Yes, today's processors indeed have a parallelism which was unconceived of at the time the original Mathematicians, then-to-be Computer Scientists, conceived of Binary Search...
Now I myself wonder if these ideas might be extended to GPU's, that is, if the massively parallel execution capability of GPU's could be extended to search for data like Binary Search does, and what such an appropriately parallelized algorithm/data structure would look like... keep in mind, if we consider an updateable data structure, then that means that parts of it may need to be appropriately locked at the same time that multiple searches and updates are occurring simultaneously... so what data structure/algorithm would be the most efficient for a massively parallel scenario like that?
Now map that onto software. A junior developer needs three to five years to become a competent mid-level engineer. Five to eight years to become senior. Ten or more to become a principal or architect. That timeline can’t be compressed by throwing money at it. It can’t be compressed by AI either."
Observation: There probably is a market for documenting all of a business's processes and workflows (which business owner wouldn't want some really cool charts of all of their business processes?), and that should be able to done quickly and cheaply with Text-to-Image LLM's (NanoBanana, ?, ???). Well, if there's value on the one side, and the ability to deliver under cost and under budget on the other, then that's a value-to-cost asymmetry and subsequently a candidate for a scalable service business...
Related:
https://en.wikipedia.org/wiki/Business_process_re-engineerin...
reply