maxov · HackerTrans

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.

maxov

昨年議論

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.

maxov

3 年前議論

Absolutely! (also see the article) https://www.colorado.edu/artssciences-advising/resource-libr...

maxov

3 年前議論

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.

maxov

3 年前議論

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.

maxov

3 年前議論

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.

maxov

3 年前議論

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.

maxov

4 年前議論

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.

maxov

4 年前議論

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.

maxov

5 年前議論

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.

maxov

5 年前議論

~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.

maxov

5 年前議論

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.

maxov

5 年前議論

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

There's a half chance of getting exactly one boy, and one way to calculate this is by noticing there are two different ways to get one boy if we take order in account. You are right that the orderings don't matter in this case, so we could also e.g. model this with a binomial distribution. Once you know there are >= 1 boys, the chance you have two is 0.25/(0.25+0.5) = 1/3.

maxov

5 年前議論

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.

maxov

5 年前議論

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.

maxov

5 年前議論

I might be misinterpreting, but are you saying the two are mutually exclusive? Google Docs does need custom layout and rendering which may be tough/finicky to implement with the existing css layout, as well as consistency.

maxov

5 年前議論

The synchronicity of this showing up on the HN front page at the same time as Google moving Docs to canvas-based rendering (https://news.ycombinator.com/item?id=27129858) is kind of funny.

More seriously, this looks really cool, and I do actually wonder if it could ease some of the problems Google is looking to solve by using canvas-based rendering, although I'm not super familiar with the challenges of rich-text editing. It would be much more preferable for me (and I think for most developers and users) if web apps still used the DOM to render text boxes, and you could hook into the rendering and layout engine for more complex operations. The layout and painting hooks offered by Houdini seem very useful for this.

The one issue is I'm not sure how text selection works here - the order of elements in selection is already kind of obtuse for more complicated layouts, and this adds even more configurations. I don't know if the APIs offer some sort of ability to control the order of selection or if that's somehow a feature of the box model.

maxov

5 年前議論

Yeah, I have heard of it, and thanks for mentioning it to those who may not have. Like others have said, these have very few of the same guarantees people might be looking for in institutional accounts, especially that it's not FDIC insured or other legal obligations. They are also subject to risks like bugs in smart contracts or even larger ones like in the settlement/blockchain layer. And how disputes may be settled in these systems legally has not been tested and is still under question. They are also not a good fit for standard checking account features that e.g. Wealthfront Cash has. Sadly, the amount of users actually using cryptocurrency for real-world transactions is still really small. [1]

I think all this stuff around yield farming, liquidity pooling, etc. is super cool, but I think the standard advice applies: "don't put in more than you are willing to lose". Given all the unknown factors and risks I would not use it for my emergency fund or savings, and right now I would think about it more like a rather risky, potentially high-return investment. Even if these products are marketed as "protected accounts", they all say that loss of principal is possible.

[1]: See https://medium.com/swlh/how-many-people-actually-use-bitcoin.... The 2018 Chainalysis report estimated 13.5 million Bitcoin users with 2.3 million using it to make regular payments. Who knows how many of these payments correspond to "real-world" goods and services, but I'd guess it's not much. Compare this to Paypal with 300 million active users.

maxov

5 年前議論

Gotcha. I didn't consider just putting a small amount of direct deposit into HMB, that's pretty clean! Might try it myself :) I doubt they expect most users to do something like this though, which may explain why they're able to offer a rate that high.

maxov

5 年前議論

This may be unfounded, but I am pretty skeptical of any bank or service that offers such high APY for a savings account. The effective federal funds rate is now about 0.6%, and Wealthfront is really clear in their communications on how the interest on their cash account is directly tied to that rate. More generally, although I am not an expert, I am not sure how any bank will be able to maintain interest rates that high without somehow making money off you, or coaxing you into doing something that is actually profitable for them, when you don't see it. Especially because if they actually want to call their account a checking account, they are subject to the same legal imitations (amount in reserve, ability to make loans) as other banks.

Looking at One Finance and HMBradley, these 3% APY accounts seem to only be added to as a percentage of your direct deposit paycheck. For HMBradley, that rate only seems to kick in if you save 20% or more of your paycheck each month. I am not a financial advisor, but this seems way more than anyone should be keeping in cash. Main reason being you should only keep it for liquidity and emergencies and nothing else, because otherwise you're basically losing money to inflation.

The median American household makes $60k and has a net worth of $120k. The standard financial advice is to have an emergency fund to cover about 6 months of expenses, which we can say conservatively (adding in any other cash people keep) would be maybe $30k. To stay at that level with about 1/4 net worth in cash, you should save 25% in cash after expenses. The most common budgeting rule is 50% (needs)/30% (wants)/20 %(savings), meaning that to stay "even" you'd actually want to save at most 4% of your paycheck in cash (this way, 25% of your net worth growth will be in cash). This is not even enough for the lowest HMBradley tier of 0.50% APY.

I think all the assumptions I made are pretty conservative, namely that expenses grow linearly with income. I'm going to guess that if you're higher income (eg 2x median) your expenses will not be (they will maybe be up to 50% higher), so you should save even less to keep your emergency fund. Therefore 25% of net worth in cash seems to be a pretty good rule of thumb, if even too high for higher net worth households. You don't bump into that unless your total spending is 20% of your paycheck each month (the number of people like that must be really small). So one way or another, you're losing pretty significantly keeping that much in cash.

コメント