blog.joeyrobert.org

Conway’s Game of Life is a dead simple cellular simulation. It contains an infinite grid composed of cells, which live or die based on a few rules:

  1. Any live cell with fewer than two live neighbours dies, as if caused by underpopulation.
  2. Any live cell with more than three live neighbours dies, as if by overcrowding.
  3. Any live cell with two or three live neighbours lives on to the next generation.
  4. Any dead cell with exactly three live neighbours becomes a live cell

So I created a little open source implementation in JavaScript called ConwayJS. The demo’s available on that page, and the source code is up on GitHub. It’s heavily reliant on jQuery for DOM manipulation.

JavaScript and DOM speed are hot topics right now. Most major browsers have been playing catch-up ever since the release of Google Chrome and it’s high performance JavaScript virtual machine V8. V8 is able to just-in-time compile JavaScript to native machine code, which has huge performance benefits over an interpreter or bytecode virtual machine used by other browsers. TraceMonkey, which also uses native code compilation was released in Mozilla 3.5. Some other JS engines:

  • Tamarin: JavaScript engine used in Flash 9.0+ which also uses JIT compilation.
  • Carakan: Opera’s up-and-coming engine featuring JIT. Reportedly 2.5 times faster than the current Opera byte-code based engine Futhark.
  • JavaScriptCore: WebKit’s JavaScript implementation used in Safari et al.

ConwayJS is a good use case for DOM heavy JavaScript applications, so I took ad hoc benchmarks using it’s build in frame counter. Methology: I took three test samples for each browser when the frame rates appeared to stabilize, and computed the average — nothing fancy. Some info on the test system:

  • AMD Athlon 64 X2 Dual-Core TK-55 at 1.8 GHz
  • 2048 MB DDR 2 Memory at 159.6 MHz.
  • Windows 7 Professional

Browser versions

  • Chrome 3.0.195.27
  • Firefox 3.5.5
  • Internet Explorer 8
  • Safari 4.0.3
  • Opera 10.01

Now onto the results, which are plotted on the graph below:

Notes

  • Safari’s DOM didn’t appear to be able to keep up with the JavaScript engine, so while the theoretical frame rate was approximately 69 Hz, it was skipping enough such that only 1/5 frames rendered.
  • The JavaScript function setInterval() is used to loop through each cycle. It’s set to timeout 1 millisecond after each run, making the maximum possible frequency 1000 Hz. The 1 ms granularity was used for this benchmark. 10 ms is used normally.

Conclusion

It appears that most browsers still have some catching up to do. Google Chrome was the winner in this benchmark by far, with nearly double the frame rate as Safari. I’m very surprised to see Firefox below Opera, considering Opera’s JavaScript engine in 10.01 is bytecode based versus Firefox’s TraceMonkey with native code compilation. IE barely even compares to most other browsers. It will be exciting to see what improvements will come with the release of Google Chrome 4.0 and Opera’s new JavaScript engine.

Guitar Pro ScreenshotI’ve been using Guitar Pro pretty regularly for the past 3 years to compose some of my music. It was originally designed to be a guitar tab editor, but it’s pianists and violinists would find themselves right at home as well. It’s pretty convenient, but I often find myself complaining about some little thing that Visual Studio has that Guitar Pro could really benefit from. This is coming from a programmers perspective, but these would make very good features in an “Advanced” menu.

  • Commenting: Commenting is by far my most sought after feature in Guitar Pro, though admittedly commenting a music track would add a lot more complexity. Normally when I want to save a riff for later, I put it at the far end of the track, meaning by the time I’m finished with the song, I’ll have 5 or 6 snippets that don’t really belong anywhere but “comments”.
  • Batch Modify and/or Find and Replace: I can’t count how many times I’ve wanted to a do a pattern match or a find and replace on my guitar tracks. As it stands, there’s a lot of manual (see: repetitive) that labour involved in laying down a track. It’s a matter of adding nice (even vim like) commands that would really speed up that process.
  • Export to MP3 Rendering: Guitar Pro features a rendering library for guitar, bass and drums called “Realistic Sound Engine” or RSE as an alternative to MIDI playback. The quality is usually pretty nice (though there a few volume inconsistencies with the MIDI player that drive me insane), however that’s no “real” way to export sounds rendered in it. I put “real” in quotes because there does exist a Export to WAV option that would do essentially what I want, however it just tries to record the output of your sound card. This can be problematic since some sound cards don’t support recording their output. What I’m looking for is real FL Studio style rendering that has no sound card in between it and the resulting MP3.

Guitar Pro does get a lot of things right though. It does have a few nice keyboard shortcuts, such as C to copy the current note to the end of the measure, Insert to add a rest before the current note with the same value as the note, CTRL-Insert to add a measure before the current measure, P for palm mute and I for ‘let ring’. It also supports pasting multiple times with a variety of options (insert, paste over and add to the end of the score). Guitar Pro also uses numbers for the drum parts which are easily memorized. The built-in scales and chords are also nice when I’m having musician’s block.

There are a few alternatives out there: Power Tab, which is free, and TablEdit. Hopefully the pressure of competition and the release of Guitar Pro 6 will add some of these features! They can all learn a lesson from IDE’s to improve musician productivity.

Last Thursday I received an email from my undergraduate advisor, C. R. Jayasundera, concerning my (now dead) website, joeyrobert.org, advising me to call him ASAP. joeyrobert.org was basically a small scale version of MIT’s OpenCourseWare, where I posted all of the course material from what I was taking. It was intended to give lower years (at UW) and those interested in physics some chewing material for courses they might be interested in, and it was nowhere near as comprehensive as anything on OCW. It was NOT a go-to website for would-be cheaters. I certainly wouldn’t want link potential employers to a website like that.

I understand the dubious legality of posting copyrighted material which I was doing. However, on campus and online there exist several student society funded exam banks, whose purpose is to save old exams (which they may or may not have the copyright for) for future students. What is the difference between that and archiving my course material online?

He went on to say that posting that sort of material, such as labs I’ve written and course assignments, was tantamount to plagiarism and that I should take it down before the issue went up to the dean. This sort of offsets me a little because I’m expecting that perhaps a professor complained about his or her copyright (though I had received the approval from some professors). This brings up the question: Well, gosh darnit, who owns the copyrights to my lab reports? That should not be a gray area. The university provided the resources for the lab, however, I performed the experiment, and I wrote every word in the document.

UW is actually pretty clear on this (and this is often stated explicitly as a benefit for those who might want to do research at UW):

Ownership. Except as stipulated below, it is University policy that ownership of rights in IP created in the course of teaching and research activities belong to the creator(s).

The exceptions are:

  • The University normally retains ownership of IP rights in works created as ‘assigned tasks’ in the course of administrative activities (see Appendix A).
  • Owners of IP rights in scholarly works created in the course of teaching and research activities grant the University a non-exclusive, free, irrevocable license to copy and/or use such works in other teaching and research activities, but excluding licensing and distribution to persons or organizations outside the University community. Any such licensing and/or distribution activity would be authorized only by an additional license from the owner(s).
  • In sponsored or contract research activities, ownership of IP rights may be determined in whole or in part by the regulations of the sponsor or the terms of the contract. Participants in these research activities must be made aware of any such stipulations of the contract by the Principal Investigator, that is, the leader of the research project.

The ‘assigned tasks’ section doesn’t apply to my work as a student, as per the appendix (emphasis mostly mine):

Assigned Tasks. For the purposes of determining ownership of IP rights, “assigned tasks” are understood to mean job-related duties such as the preparation of memoranda, letters, administrative reports, minutes of meetings, mid-term and final examinations, assignments, laboratory manuals and administrative computer programs written to support the University’s on-going operations. Assigned tasks would not normally include scholarly works as defined below.

Scholarly Work: A work eligible for intellectual property protection under Canadian and/or international law which is created in the course of teaching, learning or research at the University. A list of scholarly works would include, but not necessarily be limited to: student works submitted for academic evaluation, research reports, papers prepared for publication, books, computer programs, detailed assignments, works of art, experimental data, and other academic data bases.

So what is it UW?

Reference: UW Policy 73 — Intellectual Property Rights