maxov
Joined 9 years ago
Karma
218
Submissions
50
Member since
Mar 21
Recent submissions
Comment · 1 year ago
Yes, I also found the description a little weird because of the emphasis on linear-time parsing. It is cool theoretically, and it could be understandable from a perspective of "make the compiler fast", but parsing is never the bottleneck in modern compilers. For a systems programming language this seems to be the wrong emphasis.
Comment · 1 year ago
Looking at the actual article (https://www.nature.com/articles/s41467-024-54178-1), their procedure does actually use deep learning in the process of synthesizing candidate chip designs, and the use of deep learning is key to their work. In particular, it looks like the final process is a genetic algorithm that interacts with a deep learning model that predicts the performance of candidate chips. It seems like trying to simulate the chip analytically to predict performance was far too inefficient, and replacing that part with a deep learning model made this entire procedure possible. So in summary, nothing in this article is called AI that has not been called AI before. Most importantly it produces novel designs "globally" without a human in the loop whereas one was required before. I think calling that AI-designed is pretty reasonable.
On a very high level, the role of deep learning here seems similar to AlphaGo (which is also the combination of a less novel generic optimization algorithm, Monte Carlo tree search, with deep learning-provided predictions). I don't think anyone would debate that AlphaGo is fundamentally an AI system. Maybe if we are to be really precise, both of these systems are optimization guided by heuristics provided by deep learning.
Comment · 3 years ago
Absolutely! (also see the article) https://www.colorado.edu/artssciences-advising/resource-libr...
Comment · 3 years ago
What a strange recommendation. I do research in CS theory and machine learning and I try to find arXiv preprints when I can, they are usually more complete than conference versions of papers. If you stick to papers from authors you know or to those from well-known conferences, arXiv is often times the best source.
Comment · 3 years ago
If Google Scholar is sunset that would be a great loss for the academic community. When was that feature removed? I have felt reasonably confident in Google Scholar so far because it is already 18 or so years old.
Comment · 3 years ago
In case you do not know, I find Google Scholar to be pretty useful for finding dates and other information about the paper - e.g. in this case https://scholar.google.com/scholar?hl=en&as_sdt=0%2C14&q=New...
I work with papers in CS/math and have been able to find dates and metadata like DOI pretty quick. There are complications when there are really multiple versions of a paper, like one in a conference that is only an extended abstract and one in a journal, but you would need to figure out which version you want to read in that situation anyway. I agree it's annoying, but coupled with reference manager software like Zotero it's hardly an issue for me.
Comment · 3 years ago
SemanticDB (https://scalameta.org/docs/semanticdb/guide.html) is a protobuf-based file format that does almost exactly this for JVM languages, primarily Scala (I was a contributor a while back). It is used to build an intelligent online code browser, as the backend for a language server, and to do intelligent refactorings.
I think a language-agnostic semantic metadata format is a good idea, but requires a lot of compromise. ctags partially does this, but only to a very coarse level (mostly definitions and references). I think some ctags implementations also define 'extension fields' that could be used to give type information, but I don't know how/if these are used in practice. SemanticDB is extremely fine-grained, but highly specialized to JVM languages and type systems that are designed to work with the JVM. Finding a common set of semantic features that can be used across languages and type systems that is fine-grained enough to be more useful than ctags sounds very difficult to me.
Comment · 4 years ago
I feel like "generate" is kind of a strong word in this case though. At this rate if the machines rise up, they will do so just to parrot all the "machines rise up" plot synopses in their training corpus.
Comment · 4 years ago
I love this! But after trying it a few times I got this result :). So fascinating.
https://thismoviedoesnotexist.org/movie/the-terminator
Brings up the age-old question of how much the learning in these models is just memorization. Though in cases like these it’s hard to tell.
Comment · 5 years ago
Good point! I think this heuristic works well if the edges between tiles in completed picture are uniquely identifiable or close to that. However from the images there seem to be only 4 "colors" of edges in the puzzle (8 if you count two orientations for each character), so I think this will prune the search space to "only" perhaps around 100k-500k. Still really good, this makes the search space 50k-250k times smaller.
Comment · 5 years ago
~20bn sounds about right. 9! * 4^9 / 4 ~ 23.8bn. Divide by 4 due to rotational symmetry.
Absolutely mind-boggling to me that such a small, simple puzzle has such an extreme search space! Great example of P vs NP, time to build a Where’s Waldo matching game cryptosystem.
Comment · 5 years ago
I haven't been a parent so I can't be positive, but I doubt time off for maternity or paternity acts as a "positive" incentive for having children, meaning people who didn't want children before would now want them. That time off is filled pretty well caring for the baby, which is extremely tiring and time-consuming; it doesn't really function as a break. I also don't know how many people would trade a several month absence from work for the at least 18-year (more like lifetime, really) commitment of raising a child; they have children for other reasons.
That said, I could see how having maternity/paternity leave would help people who want to put in the effort of raising children, but cannot/do not want to quit their job or keep working with a baby for the most demanding first few months. There is likely negative pressure on having children from not being able to take paid leave from work, and in aggregate people would probably have more children as a result if they do get paid leave.
Although this is an entirely different topic, such a policy seems like a good idea to combat the lack of births many developed countries are facing, which in the long term will cause an asymmetric demography. This could be a big problem, as countries with births under replacement and little net inward migration need to support an aging population with fewer active workers (see e.g. Japan). I imagine some would argue that we should move toward smaller and more sustainable societies in order to preserve the planet's resources and reduce our total consumption, in which case they would advocate for alternate solutions to deal with societal aging.
Comment · 5 years ago
Another way to think about it is counting the probability of getting k boys out of 2 children.
0 boys - 1/4
1 boy - 1/2
2 boys - 1/4
Comment · 5 years ago
I'll give some brief context first for why it could be useful, then explain what DeepWritable does. AWS Amplify JS has a library called DataStore that takes GraphQL schema and generates ActiveRecord-like model classes (https://github.com/dabit3/amplify-datastore-example/blob/mas...). Then you can create, query, update, and delete these models in your web app client. The generated classes have are immutable and have read-only fields by default. This means none of the model objects will change under you before they've actually been persisted, which is a good guarantee to have IMO.
To make updates, you create a new model object with the same ID and whatever changes you need, and persist it back. DataStore uses an immer-like mechanism where each model object has a copyOf method, to which you pass a function that takes a mutable version of the model and makes whatever mutations. Then the copyOf method returns a copy of the model object that has all the new field values, leaving the original object the same. The DeepWritable type expresses the "mutable version" of the model by making all fields writable, so for example the TypeScript compiler won't yell at you for writing to fields on the mutable version of the model. It also does this recursively for any fields whose type is an object that isn't a primitive.
Comment · 5 years ago
As someone who has spent a lot of time diving deep into Scala (I worked on compiler related semantic tooling for scalameta, worked on a experimental parallelizable Scala compiler, and even have a single commit in this release from almost four years ago LOL), and who more recently has been working with TypeScript, I find this really interesting and agree in some ways.
Scala 2.x already had path-dependent types, which combined with implicits and type inference were technically sufficient to implement versions of of the dependent function types we have now in 3.x. In my opinion, how you did this previously could get really clunky (See e.g. hlist mapping in https://github.com/milessabin/shapeless/blob/8933ddb7af63b8b...). Lots of things that frankly felt like casting magic spells, and there were sometimes fragile and weird bugs especially with how implicits were resolved, see e.g. https://github.com/scala/scala/pull/6139.
The native type-level meta-programming coming in 3.x along with a lot of streamlining of the underlying type system and implicit resolution rules (e.g. https://github.com/lampepfl/dotty/pull/5925) could help a lot. This is just one example of a more advanced feature, but there are lots of things like this that changed in Dotty (maybe the most interesting is the DOT calculus that makes a better backbone for the type system). I don't know what tooling for Scala 3.x looks like, but even Intellij's frankly amazing Scala plugin broke down sometimes for 2.x.
After using TypeScript, I just personally enjoyed the experience better. Technically Typescript's type system is equally as powerful as Scala's, but the primitives for expressing more complicated types just seem much easier compared to the path-dependent stuff you would need to do in Scala. I was amazed to find stuff like this https://github.com/aws-amplify/amplify-js/blob/dedd5641dfcfc... in mainstream wide usage. I'm not even sure how you could write these type of transformations as well in any version of Scala. I suppose maybe records work, or in this specific case there are functional patterns that are preferred.
Caveat, I haven't followed Dotty for a couple years now, so I could be missing a lot. Regardless, I have really enjoyed the tooling around Typescript as well as the design. The real-world usage of more complicated dependent types (and there are good uses IMO) have been more fluent and easier to understand, and less dependent on tricky behavior like for implicits. VS Code's tools are really magical, and I hope with some of the amazing underlying work done in Dotty the Scala developer experience could look more like that.