RE: [Axiom-mail] Another beginner's question: Lagrange interpolation

[Bill Page]

On April 13, 2007 10:07 AM Martin Rubey wrote:
> 
> "Alasdair McAndrew" writes:
> 
> > I wish I could get more of a handle on Axiom more quickly, 
> > but its behaviour still seems tantalizingly just out of
> > reach.

I felt like that for about the first year or so ... :-)

> 
> would be interesting if you could be more precise here...
> I find that the interpreter is quite clever about finding
> "appropriate" types. But of course, often it needs help.
> And certainly, a (conservative) redesign of the hierarchy
> would be in order, but this also depends on the future of
> Aldor..
>

> ...
> > However, for me at least, the problem of getting the
> > types/domains and so on correct for the use of some things
> > (like LagrangeInterpolation) seems unnecessarily difficult.
> 
> LagrangeInterpolation is really very poorly done, especially 
> with respect to the usage of domains.
>

I am not entirely sure I agree with Martin that this code is
"very poorly done". Perhaps that is true, from the point of view
of the Axiom interpreter because it requires that the user
provide some additional information - the type for the underlying
field. But given that, the interpreter is pretty smart about
deciding on the types. It is actually much easier than my
previous reply might have suggested:

(1) -> )expose PolynomialInterpolationAlgorithms
   PolynomialInterpolationAlgorithms is now explicitly exposed
   in frame initial

(2) -> LagrangeInterpolation([1,2,3],[4,5,-6])@SUP(FRAC INT)

            2
   (3)  - 6?  + 19? - 9
              Type: SparseUnivariatePolynomial Fraction Integer

The critical part the interpreter was missing was just the choice
of field. But without a good knowledge of the Axiom type system
this solution would probably be rather hard for a beginner to
anticipate.

> ... 
> > And of course I want to have a go at some programming... 
> > I've just written (the first version of) a z-transforms
> > package for Maxima, and it seems to me that such a thing
> > should be relatively straightforward in Axiom, using its
> > rules mechanism.  Then there'd be a method for solving 
> > difference equations!
>

I would like to give you an unsolicited caution regarding the
use of pattern matching rules in Axiom. Although the application
of rules work fairly well within the Axiom 'Expression' domain
really this sort of symbolic manipulation of expressions is
rather foreign and unnatural in Axiom.

People who program in Python have invented a name of the
style of programming that is "natural" in that language, i.e.
"pythonic" (sic). In Axiom we can identify an analogous style
that we might call "Axiomic" or maybe "Axiomatic". :-) The
point being that most things in Axiom are done in an object-
oriented, algebraic manner -- and not by the simple manipulation
of expressions. As a long time user of Maple, Maxima and other
"symbol-oriented" systems, I think the hardest part about
learning to use Axiom for me was to understand this change in
paradigm. Most beginning users of Axiom think of types as just
"getting in the way", but in the end that is really where the
strength of Axiom actually lies.

One thing that the object-orientation buys you (and maybe
costs you) is the importance of understanding the existing
Axiom library (which currently contains nearly 1,300 different
abstract mathematical and data types. To get the greatest
advantage and do the least amount of programming it is
essential that you think about how what you intend to write
"fits" into the existing mathematical hierarchy. This means
more time spent up front analysing and generalizing your
algorithm but ultimately less time actually programming.

In your case perhaps you need to think about how the z-transform
relates to other integral transforms that already exist in Axiom.
For example:

(5) -> )wh package transform
-------------------------------- Packages -------------------

Packages with names matching patterns:
     transform

 INVLAPLA InverseLaplaceTransform      LAPLACE  LaplaceTransform

(5) -> )sh LAPLACE
 LaplaceTransform(R: Join(EuclideanDomain,OrderedSet,CharacteristicZero,
 RetractableTo Integer,LinearlyExplicitRingOver Integer),
 F: Join(TranscendentalFunctionCategory,PrimitiveFunctionCategory,
 AlgebraicallyClosedFunctionSpace R))
 is a package constructor
 Abbreviation for LaplaceTransform is LAPLACE
 This constructor is exposed in this frame.
 Issue )edit c:/Program
Files/axiom/mnt/windows/../../src/algebra/LAPLACE.spad
 to see algebra source code for LAPLACE

------------------------------- Operations --------------------
 laplace : (F,Symbol,Symbol) -> F

(5) -> laplace(x+1,x,y)

        y + 1
   (5)  -----
           2
          y
                                       Type: Expression Integer

------

Of course understanding what goes into the definition of the
LaplaceTransform package:

  EuclideanDomain
  OrderedSet
  CharacteristicZero,
  RetractableTo Integer
  LinearlyExplicitRingOver Integer
  TranscendentalFunctionCategory
  PrimitiveFunctionCategory
  AlgebraicallyClosedFunctionSpace

might require a significant effort. But it seems to me that in
order to write an Axiomatic z-transform package, one should be
concerned about the discrete analogues for the above domains.
This will likely have something in common with combinatorial
mathematics that is already in Axiom, e.g.

(7) -> )sh CombinatorialFunction
 CombinatorialFunction(R: Join(OrderedSet,IntegralDomain),
 F: FunctionSpace R)
 is a package constructor
 Abbreviation for CombinatorialFunction is COMBF
 This constructor is not exposed in this frame.
 Issue )edit c:/Program Files/axiom/mnt/windows/../../src/algebra/COMBF.spad
 to see algebra source code for COMBF

------------------------------- Operations --------------------------------
 ?**? : (F,F) -> F                     belong? : BasicOperator -> Boolean
 binomial : (F,F) -> F                 factorial : F -> F
 factorials : F -> F                   factorials : (F,Symbol) -> F
 iibinom : List F -> F                 iidprod : List F -> F
 iidsum : List F -> F                  iifact : F -> F
 iiperm : List F -> F                  iipow : List F -> F
 ipow : List F -> F                    permutation : (F,F) -> F
 product : (F,Symbol) -> F             summation : (F,Symbol) -> F
 operator : BasicOperator -> BasicOperator
 product : (F,SegmentBinding F) -> F
 summation : (F,SegmentBinding F) -> F

But I hope that this does not discourage you from attempting
re-implement your Maxim z-transform code in Axiom. I really
only intend these comments as a kind of advanced warning of
where you might end up. It is entirely possible that you may
find the approach of using pattern matching rules to manipulate
Expressions adequate for your initial purposes.

> Concerning difference equations, note that SumIt by the late 
> Manuel Bronstein is now free software (I have the sources
> already). If you are familiar with these things, (google for
> the documentation), it would be great to make that available
> in axiom (some porting is needed).

I agree with Martin that making SumIt available in Axiom would be
a big step towards making it possible to write your z-transform
function in a more Axiomatic way.

> ... 
> In the long run, that is, if you are going to explore Axiom 
> seriously, it is certainly necessary to start programming in
> SPAD or Aldor.
> 
> In any case, I hope you stay with us,
> 

Me too.

Regards,
Bill Page.