Today I used Claude to diagnose a blocking bug in a Steam game I really wanted to play. It took it 18 mins, but it unpacked the Godot package, figured out the bug, proposed a fix, and gave me an in game workaround.

I didn't have to do anything! Claude figured out the structure of the .pck file by using `strings`, then wrote some Python code with some magic Godot-specific code to unpack the specific chunks it needed.

An alternative that I experimented with and found to be very usable is one solar panel, a small camping battery ("portable power station"), and an Instant Pot. The total cost is not super high. The Instant Pot is power efficient and can cook a lot of food at once. Since it's battery powered you can start any time the battery is charged.

I asked this question in a college-level class with clickers. For the initial question I told them, "This is a trick question, your first answer might not be right". Still less than 10% of students got the right answer.

One thing I like about pyodide is that it supports lots of packages like numpy. How would you support packages like this with a WASI approach?

In my case I spent two decades casually reading about economics. But then one day I ordered an economics textbook to work through the problems, and found out that I basically knew nothing and couldn't do any of the problems. A few months of slowly working through the textbook gave me a much deeper level of understanding. I could do the problems now.

In the article, talking about smoothstep approximation of sinc: "I'd argue the smoothstep version looks better" Why would this be? I would have thought the theoretically correct sinc version would look nicer.

Another fun tool is CrowdGrader (https://www.crowdgrader.org/). It's a nice way to distribute reviewing/grading throughout the class to make it more scalable. When I was teaching I really liked it, it meant I could assign more interesting creative assignments at a faster pace. It's a different type of "automation".

[1]: https://en.wikipedia.org/wiki/Algorithms_for_calculating_var...

https://en.wikipedia.org/wiki/On-line_Guitar_Archive

-Do a literature survey and read LOTS of papers. If you are not coming from the standard academic route you are probably vastly underestimating how much existing work has been published. To publish your research you need to place it in the right context, with citations, and really understand what is novel about your ideas. Read lots of papers, take notes, keep track of the bibliographic details. Follow up on citations to find more papers.

-Write up your understanding of the relevant field as a survey of existing literature with citations. This will clarify your thinking and help you become familiar with standard terminology. This will also be part of your finished paper.

-Write up your idea using terminology and notation consistent with your existing survey. Discuss what is novel and different about your idea.

-Analyze your idea from the point of view of other paradigms. Answer possible critiques that would come from other ways of thinking about the same problem. If you've discovered "standard" ways of evaluating your type of idea, do the evaluation to see how you compare.

-Get feedback. Get opinions from as many other people as you can that are as good as you can find. In the draft paper, thank everyone that gives you any feedback. If people give you substantial ideas that improve the work, ask if they want to be co-authors and work with you a bit more.

-Once you feel there is a real research contribution in your paper draft, and people you have shown it to think it is good, start working on getting it published. Put it up on preprint sites and send it to conferences or journals that are relevant. By this point you should know the right venues based on your survey work.

Comments URL: https://news.ycombinator.com/item?id=14817215

Points: 2

# Comments: 0

I would rephrase this as, "If you care about floating point performance and have not investigated the compiler flags related to floating point performance, consider this a bug in your project."

For me, "Larrabee" died during it's first public demo in IDF 2009 [1]. At the time I was working on CUDA libraries at NVIDIA. I remember everyone watching the stream to see how much of a threat it would be. When we saw the actual graphics, everyone started laughing. "Welcome to the 1990s!" At that point it was obvious that Larrabee would not be a graphics threat to NVIDIA, it just had too far to go. It was not a discrete GPU killer.

[1]: https://www.youtube.com/watch?v=G-FKBMct21g