nhaliday + graphics   29

One week of bugs
If I had to guess, I'd say I probably work around hundreds of bugs in an average week, and thousands in a bad week. It's not unusual for me to run into a hundred new bugs in a single week. But I often get skepticism when I mention that I run into multiple new (to me) bugs per day, and that this is inevitable if we don't change how we write tests. Well, here's a log of one week of bugs, limited to bugs that were new to me that week. After a brief description of the bugs, I'll talk about what we can do to improve the situation. The obvious answer to spend more effort on testing, but everyone already knows we should do that and no one does it. That doesn't mean it's hopeless, though.

...

Here's where I'm supposed to write an appeal to take testing more seriously and put real effort into it. But we all know that's not going to work. It would take 90k LOC of tests to get Julia to be as well tested as a poorly tested prototype (falsely assuming linear complexity in size). That's two person-years of work, not even including time to debug and fix bugs (which probably brings it closer to four of five years). Who's going to do that? No one. Writing tests is like writing documentation. Everyone already knows you should do it. Telling people they should do it adds zero information1.

Given that people aren't going to put any effort into testing, what's the best way to do it?

Property-based testing. Generative testing. Random testing. Concolic Testing (which was done long before the term was coined). Static analysis. Fuzzing. Statistical bug finding. There are lots of options. Some of them are actually the same thing because the terminology we use is inconsistent and buggy. I'm going to arbitrarily pick one to talk about, but they're all worth looking into.

...

There are a lot of great resources out there, but if you're just getting started, I found this description of types of fuzzers to be one of those most helpful (and simplest) things I've read.

John Regehr has a udacity course on software testing. I haven't worked through it yet (Pablo Torres just pointed to it), but given the quality of Dr. Regehr's writing, I expect the course to be good.

For more on my perspective on testing, there's this.

https://hypothesis.works/articles/the-purpose-of-hypothesis/
From the perspective of a user, the purpose of Hypothesis is to make it easier for you to write better tests.

From my perspective as the primary author, that is of course also a purpose of Hypothesis. I write a lot of code, it needs testing, and the idea of trying to do that without Hypothesis has become nearly unthinkable.

But, on a large scale, the true purpose of Hypothesis is to drag the world kicking and screaming into a new and terrifying age of high quality software.

Software is everywhere. We have built a civilization on it, and it’s only getting more prevalent as more services move online and embedded and “internet of things” devices become cheaper and more common.

Software is also terrible. It’s buggy, it’s insecure, and it’s rarely well thought out.

This combination is clearly a recipe for disaster.

The state of software testing is even worse. It’s uncontroversial at this point that you should be testing your code, but it’s a rare codebase whose authors could honestly claim that they feel its testing is sufficient.

Much of the problem here is that it’s too hard to write good tests. Tests take up a vast quantity of development time, but they mostly just laboriously encode exactly the same assumptions and fallacies that the authors had when they wrote the code, so they miss exactly the same bugs that you missed when they wrote the code.

Preventing the Collapse of Civilization [video]: https://news.ycombinator.com/item?id=19945452
- Jonathan Blow

NB: DevGAMM is a game industry conference

- loss of technological knowledge (Antikythera mechanism, aqueducts, etc.)
- hardware driving most gains, not software
- software's actually less robust, often poorly designed and overengineered these days
- *list of bugs he's encountered recently*:
https://youtu.be/pW-SOdj4Kkk?t=1387
- knowledge of trivia becomes more than general, deep knowledge
- does at least acknowledge value of DRY, reusing code, abstraction saving dev time
techtariat  dan-luu  tech  software  error  list  debugging  linux  github  robust  checking  oss  troll  lol  aphorism  webapp  email  google  facebook  games  julia  pls  compilers  communication  mooc  browser  rust  programming  engineering  random  jargon  formal-methods  expert-experience  prof  c(pp)  course  correctness  hn  commentary  video  presentation  carmack  pragmatic  contrarianism  pessimism  sv  unix  rhetoric  critique  worrydream  hardware  performance  trends  multiplicative  roots  impact  comparison  history  iron-age  the-classics  mediterranean  conquest-empire  gibbon  technology  the-world-is-just-atoms  flux-stasis  increase-decrease  graphics  hmm  idk  systems  os  abstraction  intricacy  worse-is-better/the-right-thing  build-packaging  microsoft  osx  apple  reflection  assembly  things  knowledge  detail-architecture  thick-thin  trivia  info-dynamics  caching  frameworks  generalization  systematic-ad-hoc  universalism-particularism  analytical-holistic  structure  tainter  libraries  tradeoffs  prepping  threat-modeling  network-structure  writing  risk  local-glob 
may 2019 by nhaliday
Gimbal lock - Wikipedia
Gimbal lock is the loss of one degree of freedom in a three-dimensional, three-gimbal mechanism that occurs when the axes of two of the three gimbals are driven into a parallel configuration, "locking" the system into rotation in a degenerate two-dimensional space.

The word lock is misleading: no gimbal is restrained. All three gimbals can still rotate freely about their respective axes of suspension. Nevertheless, because of the parallel orientation of two of the gimbals' axes there is no gimbal available to accommodate rotation along one axis.

https://blender.stackexchange.com/questions/469/could-someone-please-explain-gimbal-lock
https://computergraphics.stackexchange.com/questions/4436/how-to-achieve-gimbal-lock-with-euler-angles
Now this is where most people stop thinking about the issue and move on with their life. They just conclude that Euler angles are somehow broken. This is also where a lot of misunderstandings happen so it's worth investigating the matter slightly further than what causes gimbal lock.

It is important to understand that this is only problematic if you interpolate in Euler angles**! In a real physical gimbal this is given - you have no other choice. In computer graphics you have many other choices, from normalized matrix, axis angle or quaternion interpolation. Gimbal lock has a much more dramatic implication to designing control systems than it has to 3d graphics. Which is why a mechanical engineer for example will have a very different take on gimbal locking.

You don't have to give up using Euler angles to get rid of gimbal locking, just stop interpolating values in Euler angles. Of course, this means that you can now no longer drive a rotation by doing direct manipulation of one of the channels. But as long as you key the 3 angles simultaneously you have no problems and you can internally convert your interpolation target to something that has less problems.

Using Euler angles is just simply more intuitive to think in most cases. And indeed Euler never claimed it was good for interpolating but just that it can model all possible space orientations. So Euler angles are just fine for setting orientations like they were meant to do. Also incidentally Euler angles have the benefit of being able to model multi turn rotations which will not happen sanely for the other representations.
nibble  dirty-hands  physics  mechanics  robotics  degrees-of-freedom  measurement  gotchas  volo-avolo  duplication  wiki  reference  multi  q-n-a  stackex  graphics  spatial  direction  dimensionality  sky 
september 2017 by nhaliday
Spaceship Generator | Hacker News
some interesting discussion of the value of procedural generation in the comments
commentary  hn  graphics  games  programming  libraries  repo  oss  project  SIGGRAPH  random  generative 
june 2016 by nhaliday

bundles : engframetechie

related tags

abstraction  accuracy  acm  advanced  analytical-holistic  announcement  aphorism  apple  applications  art  assembly  beauty  blog  browser  build-packaging  c(pp)  caching  caltech  carmack  checking  civilization  commentary  communication  comparison  compilers  complex-systems  composition-decomposition  computer-memory  computer-vision  concurrency  conquest-empire  contrarianism  correctness  coupling-cohesion  course  cracker-prog  critique  crypto  cs  dan-luu  data-science  dbs  debugging  deep-learning  degrees-of-freedom  design  desktop  detail-architecture  differential  dimensionality  diogenes  direction  dirty-hands  documentation  duplication  ecosystem  elegance  email  engineering  error  expert-experience  explanation  exposition  facebook  flux-stasis  formal-methods  frameworks  frontend  frontier  games  generalization  generative  geometry  gibbon  github  google  gotchas  graphics  guide  hacker  hardware  history  hmm  hn  idk  IEEE  impact  increase-decrease  info-dynamics  init  interdisciplinary  interface  intricacy  iron-age  jargon  javascript  julia  knowledge  latency-throughput  lecture-notes  letters  libraries  linear-models  links  linux  list  local-global  lol  machine-learning  math  measurement  mechanics  mediterranean  memory-management  metal-to-virtual  microsoft  minimum-viable  model-class  mooc  multi  multiplicative  network-structure  networking  news  nibble  nitty-gritty  numerics  objektbuch  org:edu  org:junk  org:mag  org:popup  os  oss  osx  parsimony  pdf  people  performance  pessimism  physics  plan9  pls  pragmatic  prepping  presentation  prof  profile  programming  project  protocol-metadata  q-n-a  random  recommendations  reference  reflection  repo  rhetoric  risk  robotics  robust  roots  rust  sci-comp  SIGGRAPH  simulation  sky  software  spatial  stackex  stanford  stats  stories  stream  structure  subculture  summary  sv  system-design  systematic-ad-hoc  systems  tainter  tech  technology  techtariat  the-classics  the-world-is-just-atoms  thick-thin  things  threat-modeling  tools  top-n  topology  trade  tradeoffs  trends  trivia  troll  tutorial  unit  universalism-particularism  unix  video  virtu  virtualization  volo-avolo  vr  webapp  wiki  worrydream  worse-is-better/the-right-thing  writing  yak-shaving  🖥 

Copy this bookmark:



description:


tags: