parrt

9 ms·

61.
by parrt 9y ago
I was also surprised when I saw that there was no standard notation for Jacobian matrices. We use the numerator notation in the article, but point out that there are papers that use the denominator notation. I think I remember from engin
62.
by parrt 9y ago
Hiya. That's funny because it's exactly what caused us to write this article. Jeremy and I were working on an automatic differentiation tool and couldn't find any description of the appropriate matrix calculus that explained
63.
by parrt 9y ago
We originally had that generic ML target in mind but figured a DL bent would make it a wee bit more interesting.
64.
by parrt 9y ago
I agree that the font should be bigger. I need to learn more CSS in order to switch between font sizes per platform. The font of the text is easy but all of the images were generated from latex using a specific font size. I need to scale t
65.
by parrt 9y ago
Terence here. Jeremy's role was critical in terms of direction and content for the article. Who better than he to describe the math needs for deep learning. :)
66.
by parrt 9y ago
The unwritten corollary of course is that "almost nobody writes commercial compilers." :) Almost all of us do, however, write parsers for data, config files, languages etc... all the time. I'd personally used ANTLR of cours
67.
by parrt 9y ago
One possible angle for improvement of this technology: use a deep learning net to conjure up a different feature vector than the one I handcrafted from language/grammar expertise. I believe this was your idea. :) Glad to have you on b
68.
by parrt 9y ago
First step to using CodeBuff would be getting an ANTLR grammar for C++ or at least a fuzzy version. It's still a prototype but should do pretty well.
69.
by parrt 9y ago
Yep, that's it. Somebody has ported from Java to C# as well. Next step is really to convert to use a Random Forest classifier. I'm stuck elsewhere at the moment.
70.
by parrt 10y ago
Heh, that's cool. I tried to do a random phrase generator at one point but it's hard!
71.
by parrt 10y ago
> why use a concrete syntax tree at all? Do you mean instead of an AST? I find the syntax tree better for non-compiler applications like translators.
72.
by parrt 10y ago
Thanks for the ptr. :) I just wish I had time to rewrite that book in ANTLR 4 (it's in ANTLR 3).
73.
by parrt 10y ago
Howdy! It is definitely the case that most production languages use handbuilt parsers. In talking with these compiler developers, they are obsessed with control (speed, error reporting, ...) and want very specific data structures built duri
74.
by parrt 10y ago
An interesting idea. Not sure anyone is working on that.
75.
by parrt 10y ago
Interesting, though it is a framework very similar to previous work using Box combinations. Here, we don't require any work from a language expert. We simply sniff your project, and then make new files look like those. Handling a new
76.
by parrt 10y ago
A small followup to Jurgen's post. Python's indentation is meaningful so any change to it would mean we changed the program. In that sense, python is not a good target for this tool. Also, as a simple implementation expedient for
77.
by parrt 10y ago
The hard part of building a code formatter by hand is coding all the formatting rules, not the parsing. All formatters are based upon parsers so that is a constant across them. Creating a grammar from exemplars is still an unsolved problem.
78.
by parrt 10y ago
Yep. no definition of "good style". The tool simply makes new files look like the rest of your project.
79.
Show HN: CodeBuff – smart code formatter(github.com)
62 points by parrt 10y ago|21 comments
80.
by parrt 12y ago
I should add Adaptive LL(* ), ALL(* ), of ANTLR 4 to the mix here. It handles any grammar you give it and generates a correct parser except for one small caveat: no indirect left-recursion. It's the culimation of 25 years of focused