elanning
elanning on Hacker News
> I think Astra was trained on neural weights data as an attempt by OpenAI to get to recursive self improvement.
This might be the case, a few weeks ago, I wanted to compare a small neural network trained with AdamW vs a handcrafted set of weights on a random task. Astra was able to handcraft a set of weights that perfectly fit the small neural network to the task. AdamW was unable to tune the weights to get the same result.
I believe we've known humans can handcraft weights much more efficiently than standard gradient descent methods, we just don't have enough memory or time to scale ourselves, so it makes sense to train a neural network to do it on our behalf. I am excited to see how far we can push this method.
Mentioned chat: https://chatgpt.com/share/6ae8f024-34ec-83e8-9572-1300f52c80...
I wrote a minimal implementation of this feedback loop here:
https://github.com/Ichigo-Labs/p90-cli
But if you’re looking for something robust and production ready, I think installing Claude Code with the npm package manager is your best bet. It’s one line to install it and then you plugin your login creds.
It looks great, nice work. I’m impressed at the quick development too.
I know the feeling. I like to picture it as a kitchen, and those “bat-whatever” gadgets are like those silly infomercial cooking tools that are only good for one specific thing. Meanwhile the good abstractions are like a nice knife, that can be used in so many different contexts.
Big mistake on my part; I should clarify I fine-tuned both PaddleOCR and TrOCR on large amounts of data specific to my domain. I cannot speak on the best out of the box “ready to go” solutions (besides cloud ones, which were quite good with the right pre and post processing).
I’ve done a lot of OCR work and tesseract is nearly a decade out of date at this point. It is not a serious technology for anything requiring good accuracy or minor complexity. From what I’ve seen, GPT-4V completely smokes tesseract, but then again, most modern OCR systems do. If you want fast and pretty powerful OCR, check out paddle. If you want slower but higher accuracy, check out transformer based models such as TrOCR.
Also plugging my related project:
https://github.com/Ichigo-Labs/cgrep
From the comments in this thread, it seems a lot of people have built or needed an easy way to quickly create static analysis checks, without a bunch of hassle. I think extended regex is a great way to do this.
Rest in peace to one of the greats.
You might want to consider reading The Design of Design if you liked The Mythical Man-Month.
Wow this could be incredibly useful for a lot of applications. I’m excited to see the new wave of tools this could spawn.
This looks like a nice piece of work. I hope the author continues on it, or other fun hobby projects.
This looks like a nice piece of work. This area and adjacent tooling areas are ripe for improvement.
I review Posthog PRs occasionally. In addition to this, they’re also open source. Seems like a cool place.
This is typically a good way to organize React projects, in my experience. A few top-level components which hold state with a useReducer and have a few functions to make backend calls, as needed. You could consider the reducer the model and the top-level component the controller. All components that sit below the top-level are pure view components. Props in, view out. They at most hold a minor amount of UI state. They don’t make API calls or update state themselves, that must be done with a callback to the top-level component.
This makes testing simple as you can test the reducer without rendering any UI. The pure view components are also easy to test. Then a few end to end tests to tie everything together.
https://www.reactguide.dev/#mc-v-trees Has more info on how to scale the pattern for larger apps.
This reminds of a principle I use. Always use the weakest type for the problem at hand. I don’t use a struct/record where a simple dictionary or tuple would do. I don’t use a class when it could be a plain record. I don’t use an interface when it could simply be a lambda.
When the time comes, I promote the types as necessary.
Great idea. I think UI/UX designers would love a tool like this. Especially if they could import React components made by the development department.
I wrote a VS code extension and pre-commit hook for this kind of thing:
https://github.com/elanning/checkr
It's a nice inbetween solution for quick stuff not worth writing a full static analysis plugin for.
Greetings Greg, really great work. Thanks for sharing this.
Now my greedy request: if you could take all this technology and make a blogging platform for developers, I would be greatly appreciative! And happy to pay a monthly fee!
I really need a coding blog platform where I can write interactive blogs for my readers.
This is a good example of why understanding the principles of statistics can come in handy.
Awesome hackathon project. The font scroll is great 90s website nostalgia.
I believe Norvig later clarified that the negative correlation was untrue or statistical noise.
I recently wrote a little Regex domain specific language that's translated into regular JavaScript regex. I was inspired by CCGrep:
https://arxiv.org/abs/2003.05615 because its syntax looked so clean and yet powerful.
Examples of it look like `$# ($a == $1) { return $$$; }`
$# - match any keyword, eg `do`, `while`, etc.
$a - match any variable.
$1 - match any literal.
$$$ - match any block (greedy).
It's also whitespace invariant, so `if($a==$1)` is equivalent to `if ($a == $1)`.
All that to say, I wonder if we're missing out on a variety of "domain specific regexes" for various fields.
As I understand it, overfitting is low bias, but high variance. It's perfectly fitting 5 linear data points with a complex polynomial, when the underlying function was a line. Thus the polynomial doesn't generalize well to more data points not in the training set. Your model seems to be fitting points in the training set and the evaluation set just fine. Of course if different batman's were in the evaluation set, it would suddenly be doing terrible, but you can pretty much do that to every machine learning model. It wouldn't fit a lot of underlying assumptions of statistics and machine learning, eg i.i.d and evaluation sets/training sets being from the same distribution. Your definition of overfitting thus seems more like transfer learning, in some sense.
Sounds like you have both the experience and talent necessary. I'm guessing it's only a matter of time until your next success.
I enjoyed this prose. Most of what I read is curt and devoid of personality.
Yes, many have found good success with putting a minor bit of UI state into the "mostly pure" view components. It works well until some other part of the app needs to uncheck the checkbox due to some new business requirement. This is why I usually provide a nice default "useCheckbox" hook in the same file as the pure Checkbox component.
Good question. Pure view components are incredibly easy to test and reason about. State management usually gets put into hooks that the controller component uses, which are also easier to test. You can have a nice set of unit tests for the hooks and the view components, and then a few "e2e" or integration type tests for the whole thing. Separating code into groups like this can also make it easier to find things. It also lends itself to nice reusable components.
The single best piece of React knowledge I've found is an old idea from functional programming and MVC. Separation of components into 2 groups. Pure "view" components that contain no state and are oriented around display. And "controller" components that put everything together. The controller components make http requests, manage state, and manage which sub view is currently active. So far it has worked out well. Dan Abramov had a similar idea with presentational vs container components but missed a lot of the nuance that functional programming had brought, and thus, value.