> Some things I look forward to in the future: <snip>
I am in the process of putting together a response to your email and I
should have it ready within a couple of days.
> Some things I look forward to in the future:
> I want to better understand when to use Geogebra versus the other
> plotting capabilities and other plug-ins.
Currently, some of these plugins can be thought of as competing with
each other to see which ones are best for given purposes. For
example, 2D plotting can be done in JFreeChart but it can also be done
in GeoGebra. The ThreeDXploreMathJ plugin does a nice job of 3D
rendering, but JMOL (http://jmol.sourceforge.net/ , which I have not
made a plugin for yet) may be better.
We are also in the process of trying to figure out a standard way to
have MathPiper communicate with plugins in general and having a mix of
similar and dissimilar plugins in MathPiper helps with this.
> I have played around with Geogebra on its own before, but I want to
> better understand how to use MathPiper to programmatically build
> Geogebra constructions.
Communication between MathPiper and GeoGebra is done through
When the GeoGebra plugin is opened, an instance of
geogebra.plugin.GgbAPI is created (which is a GeoGebra class that
variable 'geogebra'. The undocumented experimental MathPiper
functions which are in the following path in the repository use this
'geogebra' variable to communicate with GeoGebra:
Here is the current implementation for the experimental GeoGebraPoint
function which shows the GeoGebra API being used:
10 # GeoGebraPoint(name_IsString, x_IsNumber, y_IsNumber) <--
command := PatchString("<?Write(ToAtom(name));?>=(<?Write(x);?>,<?Write(y);?>)");
What needs to happen next is for an artistic way to be created for
MathPiper and GeoGebra to interact. We have wanted to do this for a
while now, but over the past couple of years our main priority has
been to debug MathPiper and to enhance it so that it supports the
needs of GeoGebraCAS. (GeoGebraCAS is part of GeoGebra 4.0 and
MathPiper is one of the CASs which drive GeoGebraCAS). There is still
quite a bit of work that needs to be done before MathPiper is robust
enough to support the needs of GeoGebraCAS. However, once this goal
has been met, creating useful ways for MathPiper and GeoGebra to
interact is on our list of things to do.
> I see hidden in the menus some folds for alternative languages like
> Clojure and Fortress; I want to know how to use MathPiper in
> conjunction with these other languages.
I added minimal support for executing Clojure and Fortress code in
MathPiperIDE worksheets because I wanted to experiment with them and I
wanted to see how well the worksheet interface worked with different
languages. At this point in time, there is no support for having
Clojure or Fortress interact with the MathPiper CAS. By the way, I
added experimental support for Clojure to MathPiperIDE because I
wanted to evaluate Clojure as a potential alternative to MathPiper's
custom Lisp interpreter.
Neither the Clojure plugin nor the Fortress plugin are included by
default in the current distribution of MathPiperIDE, but they could be
easily added when building MathPiperIDE using ant. However, I have
not used either of these plugins for a while and they may be broken
now due to changes in Clojure or Fortress.
If you are still interested in experimenting with one or both of these
plugins, let me know which one you would like to play with first and I
will see if I can get it working.
One plug-in suggestion: Frink. Frink is an awesome system for doing
math with physical units (e.g., measurement conversion).
I'll play around with the Geogebra API you've described. The way that
Geogebra embeds MathPiper and vice versa is interesting and somewhat
bizarre. Will people end up using Geogebra in MathPiper? MathPiper
in Geogebra? Will the distinction blur to the point where it doesn't
matter which is the "host system"?
I'm a Clojure user, so in the long run, I'm interested in the
possibility of using Clojure as the programming language within
MathPiper. But I'd much rather not distract you from the focus of
continuing to improve/debug/document what's already in MathPiper. I
was really surprised at how fully featured the built-in language was.
Is it modeled after some off-the-shelf scripting language, or did you
create it specifically for MathPiper? It looks like it's built as a
layer on top of Lisp, is that correct?
> One plug-in suggestion: Frink. Frink is an awesome system for doing
> math with physical units (e.g., measurement conversion).
Frink is amazing and I think it would be a useful plugin.
I have also been thinking about ways to extend MathPiper to enable it
to do math with physical units. MathPiper currently has a limited
ability to work with units, but it is crude:
In> Simplify(2 * in * (2.54 * cm) / (1 * in))
I have been thinking about using Maxima's ezunits package as a
starting point for a MathPiper physical units system:
> Will people end up using Geogebra in MathPiper? MathPiper
> in Geogebra? Will the distinction blur to the point where it doesn't
> matter which is the "host system"?
An important factor that relates to these questions is that GeoGebra
was specifically designed for use by teachers who are not CAS users
and who do not have an interest in learning a CAS. Even GeoGebraCAS
is designed to give these teachers fundamental CAS capabilities
without exposing them to the complexity of a complete CAS. So
GeoGebra will probably always be kept mostly separate from MathPiper
for this reason.
But for experienced CAS users, a combined MathPiper/GeoGebra system
has the potential to be a very powerful tool. However, most of the
work on a combined system like this will probably be done in the
MathPiper project and it will probably not use the name GeoGebra in
order to avoid confusing the GeoGebra project's user base.
> I was really surprised at how fully featured the built-in language was.
> Is it modeled after some off-the-shelf scripting language, or did you
> create it specifically for MathPiper?
As Sherm indicated, MathPiper is a fork of the Java version of Yacas
(http://yacas.sourceforge.net). I think the Yacas developers were
inspired by a number of languages when they developed Yacas.
By the way, the Yacas website contains a significant amount of
advanced Yacas documentation and much of it also applies to MathPiper.
Our plan it so include most of the material in this advanced
documentation in the more advanced MathPiper documentation we will
eventually be creating.
>It looks like it's built as a layer on top of Lisp, is that correct?
Yes, MathPiper runs on a custom Lisp interpreter which is implemented in Java.