That's brilliant. Now I need its compressing counterpart.
794 karma · joined March 13, 2020
It is in fact still used in certain contexts. For deciding when to slaughter the Iberian pig after feeding it exclusively with acorns in the open, it must weight 9 to 10 @s (an @ is 11.5kg, so 103.5 to 115kg)
Like "from 7AM to 11AM, one bus every 8 minutes". Then you have the bus app if you want to optimize further (and if you're me, miss it because of being too tight)
- Imagine bus A is followed by bus B, it's 5PM and people are leaving work simultaneously
- Bus A spends a lot of time on each stop picking passengers up
- When bus B arrives, fewer people are waiting and it tends to take less time
- Eventually, bus B catches up to bus A so A must skip stops to maintain proper spacing
As for why this doesn't annoy people: if both buses are already close together, any ETA changes from spacing adjustments are minimal, and bus A will show no destination on the front display, so no false expectations are created.
I'd say poor reading skills are even more of a problem
In our experience, things beyond very constrained function calling opens the door to explainability problems. We moved away from "based on the embeddings of this P&L, you should do X" towards "I called a function to generate your P&L, which is in this table; based on this you could think of applying these actions".
It's a loss in terms of semantics (the embeddings could pack more granular P&L observations over time) but much better in terms of explainability. I see other finance AIs such as SAP Joule also going in the same direction.
I'd say the point to be made is that debugging a library is way simpler than debugging a framework like React (even though they insist on calling it a library) because your code is no longer the entrypoint but some intermediate step in the logic.