698 karma · joined June 13, 2009
ciobaca.ro profs.info.uaic.ro/~stefan.ciobaca
In my spare time, I've developed NoThree - a puzzle game for Android.
https://play.google.com/store/apps/details?id=com.ovaludi.nothree.android
"Real" static analyzers, which are more useful, are based on symbolic execution and abstract interpretation and they will uncover more interesting classes of errors, like double frees, out of bounds array access, etc.
Note that all analyzers will have FPs and FNs, because the underlying problem is uncomputable.
The best open source "real" static analyzer overall for C++ is the Clang static analyzer. There are many commercial analyzers available, and most C++ shops will use one or more of these.
What are the dozen ways?
It looks good, just a tiny bit bulky.
Not sure on how it will do long term.
My OnePlus has been serving me well for more than 3 years now.
The issue is lack of seatbelt pre-tensioning, not the size of car.
I am surprised manufacturers are not required to have pretensioners.
Sure, ChatGPT will successfully manage to find formal proofs that have been done before.
But synthesising proofs from scratch is NP-complete for the simplest proofs (or worse for more interesting cases), and LLMs are simply not clever enough to do it (except in cases where the proof has been seen before).
It could be possible to integrate an SMT solver with a LLM to make this work, but the core difficulty of the FM task will then be solved by the SMT solver.
If you want to really understand an algorithm/a data structure, you have got to read it up and get your hands dirty and implement it yourself. There is no way around this.
This is a bit like taking notes in classes. The notes themselves are (nowadays mostly) almost worthless, with easy access to textbooks and other resources. The fact of taking the notes is what actually counts.
In a way, it feels that the current trend is very much like the Apple laptops at some point, where they god rid of the physical function keys and replaced them with touch sensitive controls. Thankfully, Apple is reverting this change.
I think at some point car manufacturers will realise that it leads to more accidents and they will also reverse course. Perhaps touchscreens will even be forbidden?
Caveat: I was wrong before on touchscreens. I though phones with touchscreens will not work out, but they have. However, it is because we no longer use phones for phoning, but to watch movies, read text, etc.
So I wouldn't hold my breath that the manual gear shift will survive.
But most of the graphs can be explained by the sheer number of papers being published.
Academics have the perverse incentive to publish as many papers as possible, instead of discovering as many interesting things as possible, because items published is way easier to measure than real progress made.
Therefore there is a significant paper inflation problem. People might today write 10 papers with LPUs (least publishable unit) with stuff that would have been a single technical report 30 years back.
This is much worse than it sounds, because it affects productivity significantly in subtle ways: it takes effort to publish those 10 papers, it takes effort to read up and review the 10x papers of others, and it takes time to think about LPUs instead of concentrating on the bigger picture.
Unfortunately, due to the way the research system is set up, it is not likely things will improve.
Once you know your basics, sure, go study a book. But by this point, you already know whether a given book helps you or not...
People's attention is more dispersed (additionally, several platforms are actively fighting for their attention by using all tricks in the book).
Hence the signal-to-noise ratio has dropped. The people who would leave thoughtful comments are busy with other things.
A few communities still stand (hacker news included).
In fact, I am not sure they are equivalent (in general, without taking into account the context), and even if they were, proving this would be S.F. for a compiler today (2020). Even coming up with such an optimisation without hardcoding it does not seem plausible.
Not sure why you are being downvoted.
People who are interested in learning a subject without attending lectures would be better served by a textbook in the field.
While having individual projects is very nice and it works for smaller classes, it does not scale to average students.
I have once used individual projects to grade the ~100-student class and the amount of effort it takes is unbelievable.
For example, just your number "1." point, write a project proposal, is not so easy. It takes hours to write a good proposal and several back-and-forths between instructor and student to agree on a reasonable (not too advanced/not too basic) project.
2. More and more features of programming languages for verifiable software (e.g., Dafny or Coq) get into mainstream languages, resulting in better overall software quality.
3. Computer mathematics (e.g., in Lean) gets traction, with some high-profile mathematics breakthroughs enabled.
4. Package manager-based attacks become more common.
5. Despite higher performance computers, a new level of abstraction in the process-container-vm stack makes up for performance.
6. Similarly, mainstream OSs will still lag and take seconds to, e.g., display the contents of the C drive.
When talking about arithmetic expressions themselves, you would use a meta-language (e.g., English). The arithmetic expressions would then be called the object-language (the language being studied). All of this should be pretty clear after taking a serious course in Logic.
I am not saying the choice of words is not sensible, I'm saying it it factually wrong.
Quoting him, "The equal sign is another mathematical concept that’s often misunderstood. It means, of course, that whatever is on either side of the equal sign is equivalent." This is actually wrong.
The equals sign (=) is a shorthand for stating not that the two sides are equivalent, but that they are the same (i.e., they are equal).
If they were just equivalent, we would use another sign, like ≡ (unicode U+2261).