Since you are reading this, you may already be aware of the new Mathematics Digital Library (MathDL) and the JOMA Applets initiative. If not, see Tina Straley's article in this issue for a description of the former and part 2 of Tom Roby's article for the latter. Eventually JOMA may have separate "area" pages for developers, faculty, and students. For the time being, only the first of these is available.
About the author: Alex Bogomolny writes the Cut the Knot column for MAA Online and is the developer of the popular Interactive Mathematics Miscellany and Puzzles site.
The library has been conceived as a place to deposit (among other things) small items of instructional value, "mathlets", created with one of the modern means of online communication: Java, JavaScript, Flash, etc. Several factors place this initiative apart from other digital libraries. Most important is its exclusivity. Only those items that pass a rigorous screening process will be included (published) by JOMA. Moreover, the project plans to solicit mathlet submissions in topics identified by the editorial board. The screening process and solicitations will at first be confined to specific subject areas, starting with Calculus, to eventually cover completely the undergraduate and pre-college curriculum. The scope of a subject area will be expressed as a Table of Contents, more like a book than a library. Herein lies the greatest challenge. May from this effort emerge what the legendary Paul Erdös might have called The Mathlet Book!
What does it take? Quite simply this: bringing together a lot of experience, good taste, and the desire to share your teaching insights. JOMA intends to distinguish between areas for faculty and developers. This should not imply that these two categories of people have an empty intersection. I believe that the best results might be achieved when the faculty, as a source of insights, gets directly involved in the development process. I, as many others, taught myself Java -- one of the modern wonders that makes the (no less wonderful in itself) Web come alive. It's not that difficult at all.
This column and a parallel forum are intended for those developers who (coming from the teaching background) seek programming advice, and those with the software development background, who seek to develop an item of value to the teaching and learning communities.
The development effort should not be restricted to a specific programming language or programming environment. On the other hand, I believe that to be good, a book must be coherent in style and expressive means. And as we have to start somewhere, Java is as good a choice as any other.
From the time it became public some 4 years ago, Java underwent several transformations. The most remarkable was the leap from version 1.0 to version 1.1, and the latest was Java 2, which came after version 1.1.8. Standard libraries, or packages in Java parlance, have been also evolving. One noticeable change that may be relevant to the library of small items was in the expansion of the Abstract Window Toolkit (awt) to the JFC/Swing collection of classes. In general, I think, the more advanced the version of Java that is admitted for publication in JOMA is, the more hassle-free the maintenance will be for specific components. The decision then to require the latest versions in published applets should be that easy, but it's not. The reason is that applets are not stand-alone programs. Applets run from inside Web browsers which may or may not accommodate a more advanced Java version. Most browsers nowadays support Java 1.1.8 and the awt classes. Plug-ins are required for applets that use the Swing library, a process that I judge cumbersome (but this may not reflect JOMA policy). Accordingly, I shall offer examples based on Java 1.1 model and the awt package.
Since you are reading this, you may already be aware of the new Mathematics Digital Library (MathDL) and the JOMA Applets initiative. If not, see Tina Straley's article in this issue for a description of the former and part 2 of Tom Roby's article for the latter. Eventually JOMA may have separate "area" pages for developers, faculty, and students. For the time being, only the first of these is available.
About the author: Alex Bogomolny writes the Cut the Knot column for MAA Online and is the developer of the popular Interactive Mathematics Miscellany and Puzzles site.
The library has been conceived as a place to deposit (among other things) small items of instructional value, "mathlets", created with one of the modern means of online communication: Java, JavaScript, Flash, etc. Several factors place this initiative apart from other digital libraries. Most important is its exclusivity. Only those items that pass a rigorous screening process will be included (published) by JOMA. Moreover, the project plans to solicit mathlet submissions in topics identified by the editorial board. The screening process and solicitations will at first be confined to specific subject areas, starting with Calculus, to eventually cover completely the undergraduate and pre-college curriculum. The scope of a subject area will be expressed as a Table of Contents, more like a book than a library. Herein lies the greatest challenge. May from this effort emerge what the legendary Paul Erdös might have called The Mathlet Book!
What does it take? Quite simply this: bringing together a lot of experience, good taste, and the desire to share your teaching insights. JOMA intends to distinguish between areas for faculty and developers. This should not imply that these two categories of people have an empty intersection. I believe that the best results might be achieved when the faculty, as a source of insights, gets directly involved in the development process. I, as many others, taught myself Java -- one of the modern wonders that makes the (no less wonderful in itself) Web come alive. It's not that difficult at all.
This column and a parallel forum are intended for those developers who (coming from the teaching background) seek programming advice, and those with the software development background, who seek to develop an item of value to the teaching and learning communities.
The development effort should not be restricted to a specific programming language or programming environment. On the other hand, I believe that to be good, a book must be coherent in style and expressive means. And as we have to start somewhere, Java is as good a choice as any other.
From the time it became public some 4 years ago, Java underwent several transformations. The most remarkable was the leap from version 1.0 to version 1.1, and the latest was Java 2, which came after version 1.1.8. Standard libraries, or packages in Java parlance, have been also evolving. One noticeable change that may be relevant to the library of small items was in the expansion of the Abstract Window Toolkit (awt) to the JFC/Swing collection of classes. In general, I think, the more advanced the version of Java that is admitted for publication in JOMA is, the more hassle-free the maintenance will be for specific components. The decision then to require the latest versions in published applets should be that easy, but it's not. The reason is that applets are not stand-alone programs. Applets run from inside Web browsers which may or may not accommodate a more advanced Java version. Most browsers nowadays support Java 1.1.8 and the awt classes. Plug-ins are required for applets that use the Swing library, a process that I judge cumbersome (but this may not reflect JOMA policy). Accordingly, I shall offer examples based on Java 1.1 model and the awt package.
The applet following this paragraph depicts a graph of a function, a parabola at first, over a fixed interval. The graph can be dragged up and down by any of its points. For the resulting function, controls below the drawing area allow one to simultaneously display its derivative and its integral as a function of the upper limit. The function is in fact a natural cubic spline initially interpolating through 11 points evenly distributed on a parabola. Each of the points may be dragged up and down. To see the draggable points check the "Show points" box. If one tries to drag the graph away from one of the existing draggable points, a new draggable point will be created and added to the collection. Finally, if you drag the cursor while the "Show tangent" box is checked, a short tangent line either of the graph of the function or that of the integral will follow the mouse.
It is easy to see the correlation between intervals of monotonicity of the function and intervals on which its derivative preserves the sign. A perceptive student may make a few additional observations:
So, perhaps the applet does have instructional value. However, not only has it not passed the screening process, the reason for its existence is to serve as a demonstration for several Java classes that I offer for public scrutiny (see the next section).
is a Java interface which is a sort of abstract class whose methods have no bodies and whose attributes are necessarily final. Interfaces are the Java answer to the classical question of multiple inheritance. Formally speaking, a Java class cannot be derived from 2 or more other classes. When class A is derived from class B, it must be declared in the following manner:
It would be a mistake to extend a class from two or more classes. When class A derives from an interface B, the declaration is different:
and there is no limit on how many various interfaces a class may implement. For example, extends an awt class while implementing two Java 1.1 interfaces: and . is the simplest class I could think of that implements the interface. It's a draggable point which is shown (if desirable) by a small circle. extends . It differs from in three respects. First, it may only be dragged up and down. Second, it stores information (in the form of two attributes: and ) about an additional coordinate system. Screen coordinates are a natural choice when a point must be dragged around. For numerical computations, "real world" coordinates are more convenient. s are used to convert between the two systems. Third, is more lax than in its response to a dragging initiative. responds to a mouse pressed event when the cursor is a small distance away. responds to a mouse press when the cursor is at a prescribed distance away both vertically and horizontally. Distances in the two directions are not necessarily the same. The idea here was to insure responsiveness to the cursor movements while avoiding unnecessary accidental proliferation of interpolation points.
I found the combination of and extremely convenient. Each object "knows" by means of its method when dragging is about to start. All draggable objects are reported to a object through its method. One (as in the example) or more objects are created per screen estate areas (usually, es in awt) to manage objects. methods are invoked on three occasions:
I plan to create more applets that use the above classes. Meanwhile, comments, friendly critique, and suggestions are welcome. From the programming perspective, the nicest applet only deserves a place in The Applet Book if it's been designed according to simple principles and coded following simple guidelines. I know nothing more intuitive and natural than the object-oriented paradigm. As a hook for a possible discussion on OOD (OO design) and OOP (OO Programming), one of the classes, , has a built-in flaw, a violation of basic OO principles. Can you find it?