arogozhnikov | 2 years ago | on: Fastest autograd in the West
arogozhnikov's comments
arogozhnikov | 2 years ago | on: Fastest autograd in the West
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).
arogozhnikov | 3 years ago | on: Ask HN: Are GitHub pages failing to deploy?
same for me
arogozhnikov | 5 years ago | on: Don't write command-line interfaces (and how to write if you have to)
sums it up pretty well
arogozhnikov | 5 years ago | on: Don't write command-line interfaces (and how to write if you have to)
> API != User Interface. API = Programming Interface.
That's where we should start, but the other way around. Why do you keep trying to replace programming interfaces with bash calls?
Any example when calling cli compared to proposed alternative makes any difference to your spouse?
arogozhnikov | 5 years ago | on: Don't write command-line interfaces (and how to write if you have to)
> then it should be pretty easy to test.
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
arogozhnikov | 5 years ago | on: Don't write command-line interfaces (and how to write if you have to)
ok, I understand now my question got misinterpreted, I'll rewrite that.
CLI parsing (mapping to real calls) may have bugs. How do you test this?
Both options suggested eliminate this possibility completely.
> one of their core advantages is ease of automation and testing.
Any example when suggested options are any worse in this sense?
arogozhnikov | 5 years ago | on: Don't write command-line interfaces (and how to write if you have to)
+1 for reading post
arogozhnikov | 5 years ago | on: Don't write command-line interfaces (and how to write if you have to)
> Agree the CLI "shell" around the system should not have separate logic
that was the main point.
> should report back logic faults from within the library
And I suggest validating parameters passed to functions.
So what's this you disagree with?
arogozhnikov | 5 years ago | on: Don't write command-line interfaces (and how to write if you have to)
It looks new - but is it any more complicated if after all that's what your call maps to?
arogozhnikov | 5 years ago | on: Don't write command-line interfaces (and how to write if you have to)
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?
Well, forget ASR, take any ML system.
arogozhnikov | 9 years ago | on: Gradient Boosting Explained in 3D
+1ed the issue. I was sure that's a problem on Safari side.
page 1
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).