The origin of all of my work comes from one objective: automating
mathematics (yes, even my work in *game design* can
be traced back to this). I (in close collaboration with
Bill Farmer)
want to build a *modern* mathematical
assistant which can assist practitioners with all of their tasks. I mean
'practioner' in an inclusive sense: anyone who performs a formal (or
formalizable) task which is fundamentally mathematical should benefit from
using this assistant; in other words not just mathematicians but eventually
scientists and engineers of all stripes. And by task, I really mean to prove,
explore, manipulate, experiment and visualize, as applied to objects which can
be studied mathematically. A nice
glossy article has been written about
our efforts.

Along the route travelled towards achieving this goal, I (with my many
collaborators) have had to develop new techniques. And many of these
techniques have revealed themselves to be much more widely applicable than to
just the original task they were designed for. So I have actively engaged
in various efforts of *technology transfer*, at least between fellow
academics, eventually to industry.

There are 3 different areas which interest me more than others (in chronological order):

- analysis (aka calculus),
- software construction,
- the humanities/engineering relationship.

These interest come to life in different ways in my research output
and the projects I choose to work on. My early research was mostly
concerned with doing more formal *requirements analysis* for the
next generation of **mechanized mathematics systems**. Then came an
intense phase of research into *novel techniques* of
**software construction methods** (still ongoing!). But once these started
to bear fruit, I started applying them to more than just mathematical
software; I realized that the various techniques could be used for quite
general program families. In particular, the issue of *scalability*
of software in the non-traditional sense of scaling across the capabilities
of devices (principally screen size, but also audio, etc) seemed to be
fit the bill. As it turns out, this was also of interest to some colleagues
on campus, and thus a **multi-displinary project** (in game design) was born.

I have also become rather intrigued by the various facets of
*sustainability*. I leave eco-sustainability issues to my esteemed
colleagues who know much more about this than I ever could. In
Information Technology projects, there is a new kind of nascent
un-sustainability arising: creeping complexity and forever expanding
project scope means that ever larger armies of highly-trained information
technology specialists are needed. The growth in demand is (still!)
far outpacing the supply, and shows no slowing down. What is broken
is the fundamental paradigm of software construction (as seen in
practice): almost everything is essentially hand-built. To put it quite
starkly: most of the IT industry is still working without the
equivalent of the modern factory. The IT industry is extremely
*inefficient* when it comes to properly using its
*intellectual resources*, its highly trained workforce. I am
actively thinking on this problem, and it does seem like the research
community already possesses most of the tools needed to move beyond
bespoke techniques towards something more sustainable.

Having been deeply involved (11 years at Maplesoft) in the construction of a very large system for doing mathematics, it is quite natural to also turn to mathematics as a guiding principle for building such systems.

My interest in mechanized mathematics is quite broad. Currently, my main efforts have gone to reconciling the ideas behind computer algebra systems and theorem proving. A lot of my effort goes into the MathScheme project (jointly with Bill Farmer), aimed at building the next-generation of mechanized mathematics system.

This is the core topic of the Calculemus Network as well as the Calculemus series of conferences. When someone from the computer algebra community asks what I do, I usually respond ``everything to do with CASes except algorithms'' (where algorithms dominate in the yearly conference ISSAC). For the general public, I usually refer to this work as ``teaching university level mathematics to computers''.

Current programming languages mostly have semantics much too far removed from most application domains. For many domains, the job of translating a specification into code is largely automatable, and I believe that it should be. Furthermore, such transformations allow for much richer sets of optimizations than low-level code does.

I have done work in many areas of meta-programming, including code generation from DSLs, automatic code transformation, automatic code analysis, partial evaluation, and even compilation. I have worked with strongly typed languages and dynamically typed languages.

I am currently very interested in generating application code from a high-level DSL. I have done (and published) several very successful experiments in this area, which have all confirmed my intuition that this is the future of application programming in all areas where the domain is ``well understood''.

Current languages, even those for specialized domains, frequently
have quite primitive semantics. In an effort to be very
*general purpose*, the language then forces users to worry about
details which are quite irrelevant to their task. Furthermore using
a general purpose language generally obscures the intent, and thus
the inherent invariants, of higher level languages. I believe that
creating Domain Specific Languages (DSL) with domain-specific semantics
can make a tremendous different for designer productivity. However,
while most programming tasks are now routine engineering, designing
a good language with good semantics is not, and is rather an active
research field.

Somewhat to my own surprise, my interests in the
humanities/engineering interface became more than a passing fancy
when I met Andrew Mactavish and Jeffrey Trzeciak. We discovered
a common interest in the issues of *scale* in various different
guises. When we further explored our respective expertize, we realized
that through certain **games** we could each bring our knowledge,
skills and interest to bear. Thus was born the
*G-ScalE : Gaming Scability Environment* project, in which we
study the effect of (screen) scale on various as aspects of games,
and specifically of games which fundamentally use vast amounts of
*real world* data as parts of its basic design (such as
world war I trench maps, where McMaster University possesses probably
the best collection).
I personally am interested in the techniques necessary to build
games which can seamlessly adapt to different scales -- both for
the techniques themselves as well as for the *sustainability*
aspects mentionned above. Andrew worries about capturing the knowledge
surrounding the issues of perception and enjoyment of games, while
Jeff is our source of vast amounts of data.

As well as starting the *Software Engineering and Game Design*
program several years ago, I have been involved in teaching a course
specifically on game design for the last 4 years. This has been a
great source of ideas for G-ScalE.

May 22, 2013. This is version 0.3 of this page.

Home