>
+ Parametric Surfaces
+
+Graphing a surface defined by x=f(u,v), y=g(u,v), z=h(u,v). This page
+describes plotting of surfaces defined by the parametric equations of two
+variables, x=f(u,v), y=g(u,v), and z=h(u,v), for which the ranges of u and
+v are explicitly defined. The basic draw command for this function utilizes
+either the uncompiled function or compiled function format and uses the
+surface command to specify the three
+functions for the x, y, and z components of the surface. The general
+format for uncompiled functions is:
++ draw(surface(f(u,v),g(u,v),h(u,v)), u=a..b, v=c..d)
+
+where a..b and c..d are segments defining the intervals [a,b] and [c,d]
+over which the parameters u and v span. In this case the functions are
+not compiled until the draw command is executed. Here is an example of a
+surface plotted using the parabolic cylindrical coordinate system option:
+
+In the case of compiled functions, the functions are named and compiled
+independentlyh. This is useful if you intend to use the functions often,
+or if the functions are long and complex. The following lines show functions
+whose parameters are of the type SmallFloat. The functions are compiled and
+stored by Axiom when entered.
+
+Once the function is compiled the draw command only needs the names of
+the functions to execute. Here is a compiled functions example plotted
+using the toroidal coordinate system option:
+
+Note that the parameter ranges do not take the variable names as in the case
+of uncompiled functions. The variables are entered in the order in which
+they are defined in the function specification. In this case the first
+range specifies the u-variable and the second range specifies the v-variable.
+<>
+@
+
+\subsection{graph3dtubeplots.xhtml}
+<>=
+<>
+
+
+
+<>
+ Parametric Tube Plots
+
+This page describes the plotting in three dimensional space of a tube
+around a parametric space curve defined by the parametric equations
+x=f(t), y=g(t), z=h(t), where f, g, and h are functions of the parameter t
+which ranges over a specified interval. The basic draw command for this
+function utilizes either the uncompiled functions or compiled functions
+format and uses the curve command to specify
+the three functions for the x, y, and z components of the curve. This uses
+the same format as that for space curves except that it requires a
+specification for the radius of the tube. If the radius of the tube is 0,
+then the result is the space curve itself. The general format for
+uncompiled functions is:
++ draw(curve(f(t),g(t),h(t)),t=a..b,tubeRadius==r)
+
+where a..b is the segment defining the interval [a,b] over which the
+parameter t ranges, and the tubeRadius is indicated by the variable r.
+In this case the functions are not compiled until the draw command is
+executed. Here is an example:
+
+In the case of compiled functions, the functions are named and compiled
+independently. This is useful if you intend to use the functions often,
+or if the functions are long and complex. The following lines show
+functions whose parameters are of the type SmallFloat. The functions are
+compiled and stored by Axiom when entered.
+
+Once the function is compiled the draw command only needs the names of
+the functions to execute. Here is a compiled functions example of a trefoil
+knot:
+
+Note that the parameter range does not take the variable name as in the
+case of uncompiled functions. It is understood that the indicated range
+applies to the parameter of the functions, which in this case is t.
+Typically, the radius of the tube should be set between 0 and 1. A radius
+of less than 0 results in it's positive counterpart and a radius of greater
+than one cause self-intersection.
+<>
+@
+
+\subsection{graph3dtwovariables.xhtml}
+<>=
+<>
+
+
+
+<>
+ Functions of Two Variables
+
+This page describes the plotting of surfaces defined by an equation of
+two variables, z=f(x,y), for which the ranges of x and y are explicitly
+defined. The basic draw command for this function utilizes either the
+uncompiled function or compiled function format. The general format for an
+uncompiled function is:
++ draw(f(x,y), x=a..b, y=c..d)
+
+where a..b and c..d are segments defining the intervals [a,b] and [c,d]
+over which the variables x and y span. In this case, the function is not
+compiled until the draw command is executed. Here is an example:
+
+In the case of a compiled function, the function is named and compiled
+independently. This is useful if you intend to use a function often, or
+if the function is long and complex. The following line shows a function
+whose parameters are of the type SmallFloat. The function is compiled and
+stored by Axiom when it is entered.
+
+Once the function is compiled the draw command only needs the name of the
+function to execute. Here is a compiled function example:
+
+Note that the parameter ranges do not take the variable names as in the
+case of uncompiled functions. The variables are entered in the order in
+which they are defined in the function specificationl. In this case the
+first range specifies the x-variable and the second range specifies the
+y-variable.
<>
@
@@ -35189,10 +36625,171 @@ infinity; the step size is any positive integer.
\subsection{linconversion.xhtml}
<>=
<>
+
<>
- linconversion not implemented
+ Conversion
+
+Conversion is the process of changing an object of one type into an
+object of another type. The syntax for conversion is object::newType.
+
+By default, 3 has the type
+PositiveInteger
+
+We can change thisinto an object of type
+Fraction Integer by using "::".
+
+A coercion is a special kind of conversion that Axiom is allowed to do
+automatically when you enter an expression. Coercions are usually
+somewhat safer than more general conversions. The Axiom library contains
+operations called
+coerce and
+convert. Only the
+coerce operations can be used by the
+interpreter to change an object into an object of another type unless
+you explicitly use a "::".
+
+By now you will be quite familiar with what types and modes look like.
+It is useful to think of a type or mode as a pattern for what you want
+the result to be. Let's start with a square matrix of polynomials with
+complex rational number coefficients.
+
+We first want to interchange the Complex
+and Fraction layers. We do the conversion
+by doing the interchange in the type expression.
+
+Interchange the Polynomial and the
+Fraction levels.
+
+Interchange the Polynomial and the
+Complex levels.
+
+All the entries have changed types, although in comparing the last two
+results only the entry in the lower left corner looks different. We did
+all the intermediate steps to show you what Axiom can do.
+
+In fact, we could have combined all these into one conversion.
+
+
+There are times when Axiom is not able to do the conversion in one step.
+You may need to break up the transformation into several conversions in
+order to get an object of the desired type.
+
+We cannot move either the Fraction or
+Complex above (or to the left of,
+depending on how you look at it)
+SquareMatrix because each of these
+levels requires that its argument type have commutative multiplication,
+whereas SquareMatrix does not.
+(Fraction requires that its argument
+belong to the category
+IntegralDomain and
+Complex requires that its argument belongs to
+CommutativeRing. See the
+Jenks section 2.1 for a brief
+discussion of categories. The Integer level
+did not move anywhere because it does not allow any arguments. We also did
+not move the SquareMatrix part
+anywhere, but we could have. Recall that m looks like this:
+
+If we want a polynomial with matrxi coefficients rather than a matrix with
+polynomial entries, we can just do the conversion.
+
+We have not yet used modes for any conversions. Modes are a great
+shorthand for indicating the type of the object you want. Instead of
+using the long type expression in the last example we could have
+simply said this:
+
+We can also indicate more structure if we want the entries of the matrices
+to be fractions.
+
<>
@