Memory biases in left vs. right implied motion

People remember moving objects as having moved farther along in their path of motion than is actually the case; this is known as representational momentum (RM). Some authors have argued that RM is an internalization of environmental properties such as physical momentum and gravity. Five experiments demonstrated that a similar memory bias could not have been learned from the environment. For right-handed Ss, objects apparently moving to the right engendered a larger memory bias in the direction of motion than did those moving to the left. This effect, clearly not derived from real-world lateral asymmetries, was relatively insensitive to changes in apparent velocity and the type of object used, and it may be confined to objects in the left half of visual space. The left–right effect may be an intrinsic property of the visual operating system, which may in turn have affected certain cultural conventions of left and right in art and other domains.

On a Problem of Burnside

Burnside posed the question as to whether or not there exist groups having an external automorphism that behaves in a certain, specific way like an inner automorphism: we shall define such automorphisms to be nearly-inner. NI-groups are fairly rare. With the aid of the computer algebra system Magma - in particular with the aid of its small group database - we set out to test this hypothesis.

Hoisting C Structures Into Clay In Device Drivers

This project addresses the unreliability of operating system code, in particular in device drivers. Device driver software is the interface between the operating system and the device's hardware. Device drivers are written in low level code, making them difficult to understand. Almost all device drivers are written in the programming language C which allows for direct manipulation of memory. Due to the complexity of manual movement of data, most mistakes in operating systems occur in device driver code. The programming language Clay can be used to check device driver code at compile-time. Clay does most of its error checking statically to minimize the overhead of run-time checks in order to stay competitive with C's performance time. The Clay compiler can detect a lot more types of errors than the C compiler like buffer overflows, kernel stack overflows, NULL pointer uses, freed memory uses, and aliasing errors. Clay code that successfully compiles is guaranteed to run without failing on errors that Clay can detect. Even though C is unsafe, currently most device drivers are written in it. Not only are device drivers the part of the operating system most likely to fail, they also are the largest part of the operating system. As rewriting every existing device driver in Clay by hand would be impractical, this thesis is part of a project to automate translation of existing drivers from C to Clay. Although C and Clay both allow low level manipulation of data and fill the same niche for developing low level code, they have different syntax, type systems, and paradigms. This paper explores how C can be translated into Clay. It identifies what part of C device drivers cannot be translated into Clay and what information drivers in Clay will require that C cannot provide. It also explains how these translations will occur by explaining how each C structure is represented in the compiler and how these structures are changed to represent a Clay structure.

Automated Portal Placement for Arthroscopic Hip Surgery

Placing portal incisions during arthroscopic hip surgery presents challenges for surgeons in terms of anatomic accessibility and patient safety. Based on key anatomic landmarks and portal placement information from recent literature, suggested portal incisions were determined. Guidance in the placement of the three most common portal incision locations (anterior, anterolateral, and posterolateral) for arthroscopic surgery; in addition to visual feedback on tool trajectory to the hip joint is provided in real time by a computer aided system for hip arthroscopy. By simplifying the portal placement process, one of the most challenging aspects of arthroscopic hip surgery, an increased use of this minimally invasive technique could be possible. In addition to portal information, improvements to an existing computer aided system for arthroscopic hip surgery, including a new hip model and redesigned mechanical tracking linkage, were completed.