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 idea is to put more pressure on writers of letters of recommendation. There is obviously already some rather weak "reputational incentive" to not give letters of recommendation to fraudsters. But it could be made a more formal policy. Letters could be required to include a statement about the candidate adhering to various formalized "good behavior" policies. Then when fraud happens there could be actual consequences for the letter writer. This would be like the culture in software development where you don't blame people for writing bad code, you blame reviewers for letting in bad code. (Idea comes from Angela Collier, in relation to other forms of antisocial behavior).
I'm using the new generation of small models to do semantic search for music lyrics. The first step is giving the model the text and asking, "What is this text about?" Without fine-tuning and only minimal prompt engineering these models can understand most languages, pull out the most relevant phrases, and list major themes and speculative ideas of what the lyrics mean. I'm super impressed with the results. Reading the answers feels like grading ambitious undergraduate student essays (both the good and the bad).
This is a good one. It is all too easy to spend years casually "interested" in a topic without developing a true foundation of the important ideas in the field.
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.
This is awesome! This reminds me of MinBLEP audio synthesis of discontinuous functions (https://www.cs.cmu.edu/~eli/papers/icmc01-hardsync.pdf). Instead of doing things at high sampling rate and explicitly filtering, generate the band-limited version directly.
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.
Agree, automated testing is good as far as it goes but really shouldn't be the whole story with grading.
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".
I would recommend all the works by Robert Nozick, listed at #14 on the list for "Anarchy, State and Utopia". While that might be his most influential book, I found his other books more fun to read.
-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.
> If you’re relying on c99 complex or std::complex and fast complex operations, and you don’t have -fcx-limited-range or -ffast-math turned on, you should probably consider this a bug in your project.
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."
This is fun to read, I'm always amazed as the disconnect between public presentations and the engineering reality of what's really going on.
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.
What's wrong with sequence A096774 (numbers with 9*10^n+7 prime)? Why is sequence A000027 (numbers starting at 1 increasing by 1 each time) better? Because it comes earlier in the encyclopedia of sequences?
This example makes it really clear what's going on. Could someone translate it to do reverse automatic differentiation? That's the one I never quite understand.
This might be true on really weird platforms, but with IEEE-754 floating point this isn't true. Integers within a big range are exactly representable without any rounding error. Doing floor((float(13) + float(13))/2.0) should be exactly 13. It is entirely possible that the weird platform was supposed to be using IEEE-754 arithmetic but had a buggy math library (depressingly common).
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.