Robotic planning of liquid handling. There are many potential alternative ways to achieve the same result, each resulting in its own computation graph.
I imagine any kind of trajectory planning for many agents faces similar challenges (e.g. robots in a factory).
But these computation graphs are similar every time. You would/should write these as a small graph with conditionals on large tensors, not as a fast changing graph of scalars. The latter will always be slower when you have an accelerator like a GPU.
> But these computation graphs are similar every time.
For now I'm testing one-after-another because failure of previous (overflow, too-small-transfer, etc) gives a hint about which part can be changed in the graph.
I've been thinking about vectorizing over multiple guesses at once, but don't see a fast reliable way to merge several graphs (also that induces significant burden on other parts of the project - autograd is just one component).
I guess our conceptions of CLIs are different. I wasn't thinking of developing complex textual formats that need to be parsed as input to a CLI program, I was thinking more like simple flags like `--do-operation=value` as opposed to a button in a GUI doing the same thing. If you have a function you want to call named foo() it should be pretty easy to just look for a `--foo` flag and run it. The problem becomes trickier if you have to parse some inputs from text. However, most CLIs I've seen for third party services use mostly simple flags, each of which corresponds to some simple operation. They may take an arg or two (e.g. `cli-client --foo 34 --title "Hello"`). If there is a more or less one-to-one mapping between functions and CLI flags, then it should be pretty easy to test. Testing a full-on parser for complex CLI commands is definitely harder, though.
If it is that simple, you can just devote this to package like typer. That's what I point to - don't write it.
I see people somehow read GUI along the lines, while I never even considered that as an option. Added a note and please read completely before commenting
Mostly because user interface is meant to expose the common tasks to the user vs API which is supposed to give a low level control. curl is a good example, as a tool is fairly accessible, but as the library it gives control on all the aspects of connection, requiring much more knowledge/skill from the programmer. Not every user has this kind of knowledge, but still may want to use curl to do quick HTTP requests.
User != Programmer
Also, "bash calls" are cool - shell is a great tool to compose many diverse tools written in different programming languages. If all the tools were just configurable via writing code in their implementation language:
1) you would have to know all the programming languages
2) you would have to somehow input the code, parameters are just shorter than code
It is easy only if you write CLI utility (or somewhat very light-weight).
Imagine you write ASR system (from CLI input to output - week(s) of training, requires several servers). Mind telling me more about using diff/stdin/stdout in this case?
I imagine any kind of trajectory planning for many agents faces similar challenges (e.g. robots in a factory).