You should install Aladjev's Library for Maple. See these threads:

partial derivatives

Aladjev library for Maple

Yes, such  domain structure does not exist in Maple. But I find that Maple's approach of module based packages has the potential of being a far cousin, in that they can create and handle package specific objects, types for them, and export operations with peculiar rules on such objects.

However, the current assortment of packages, types, properties, etc, is (for good or bad) very far from the "monolithic" structure of Axiom's domains and categories.

Some excerpts from the Axiom documentation:

Every Axiom object has a type. The type determines what operations you can perform on an object and how the object can be used.

Types in Axiom are dynamic objects: they are created at run-time in response to user commands.

types carry all of the meaning of expressions.

The Axiom interpreter reads user input then builds whatever types it needs to perform the indicated computations.

Axiom organizes objects using the notion of domain of computation, or simply domain.

Each domain denotes a class of objects. The class of objects it denotes is usually given by the name of the domain. Every basic Axiom object belongs to a unique domain.

The domain of an object is also called its type.

Indeed, Axiom operation is type/domain centric. For years I am slowly trying to understand how useful things can be done under this approach, with very limited success up to now.

My impresion is that both languages will remain alongside. And I believe that the dichotomy is not just newcomers vs advanced users, but involves different user cultures.

My talks with engineers (and posts here) show that among them there is a demand for computing-documenting software, extending a tradition of documenting slide-rule calculation times. Years ago MathCad filled that niche, and most likely there is a demand for a "superMathCad". I think that the priority of Maplesoft management is that market, even if the idea were crazy, and that explains the current status quo.

I wonder whether including non-terminating type checking programs is an advantage or not. I would have expected type checking always finishing (and in a short time) as a good feature.

So, back to the begining. Is it possible, or does it make sense, comparing the strength of the type system of Axiom and Maple? (Presumably, it should imply asking things like is Axiom type system Turing complete?)

Let me first try summarize what I have understood, and what I have not.

Static types are those checked before runtime, meaning at DAG creation time?
These are the surface types. Such checks are those made by the kernel and
presumably also by the parser (and something else?).

As these checks are minimal, Maple is weak in the strong type scale, placing
it at the left of the degree of typing picture mentioned above (and between
Tcl/Perl and VB).

And everything else are dynamic types. So, Maple is "almost" dynamically typed.
And dynamic type error checking is strong.

But this picture is for "traditional" Maple. Nowadays, and increasingly, Maple
is a multilanguage system, including code in C, Java, etc. And each language
may have a different static type strength and error check time.

So, it sounds to me like that there is room for different scenarios. For
instance, if traditional Maple creates an object but does run it, hence does
not check it, and passes it for execution to a C library say, where the checks
are done instead.







 

It seems to me that parse time checks are somewhat different in level between the 1D and 2D parsers. E.g. in 1D, when input is a nonsense list as [*], the error message is the same as that of parsing the element inside:

[*];
Error, `*` unexpected

*;
Error, `*` unexpected

while in 2D input, a kind of explicit reference to the list occurs:

[*];
Error, invalid bracketed expression

*;
Error, unable to parse

Besides that output is produced anyway.

I am looking at the 2d math displayed in the thread that had crashed (mentioned above). It seems to me that the quality of the typesetting is rather mediocre: no space between the "n" in ln and the bracket, or the top of the "2" and the horizontal bar of the square root sign, etc.

When opening that Maplenet worksheet I get, for  while, Java loading pictures (an indicator circling the coffee cup) instead of the graphs, and then nothing.

Bryon stated above that the big changes are the next step and will come in the near future.

At this point it seems like there is a comunicational/semantic problem here. For me the meaning is quite clear and it is what I have explained you above. I do not see which is your difficulty.

At this point it seems like there is a comunicational/semantic problem here. For me the meaning is quite clear and it is what I have explained you above. I do not see which is your difficulty.

No, B, g, etc are constants, meaning that they are not function ot t. These equations have sense. Typically, they arise when looking for solutions of systems of ordinary differential equations, by the ansatz that the dependent variables are constants times powers of dependent variable, here the time t, or sums of such terms. Inserting such ansatz into the ODEs produces equations like the posted ones. And, if you get non trivial solutions for the constants, you have found the solutions for the ODEs. This is useful for nonlinear ODEs.

In fact, years ago, I have written a pair of papers on this subject:

GENERALIZED POWER EXPANSIONS IN COSMOLOGY
Alejandro S. Jakubi
Computer Physics Communications 115 (1998) 284.

THE BRANCHING PROBLEM IN GENERALIZED POWER SOLUTIONS TO DIFFERENTIAL EQUATIONS
Alejandro S. Jakubi
Mathematics and Computers in Simulation 67 (2004) 45-54.
 

No, B, g, etc are constants, meaning that they are not function ot t. These equations have sense. Typically, they arise when looking for solutions of systems of ordinary differential equations, by the ansatz that the dependent variables are constants times powers of dependent variable, here the time t, or sums of such terms. Inserting such ansatz into the ODEs produces equations like the posted ones. And, if you get non trivial solutions for the constants, you have found the solutions for the ODEs. This is useful for nonlinear ODEs.

In fact, years ago, I have written a pair of papers on this subject:

GENERALIZED POWER EXPANSIONS IN COSMOLOGY
Alejandro S. Jakubi
Computer Physics Communications 115 (1998) 284.

THE BRANCHING PROBLEM IN GENERALIZED POWER SOLUTIONS TO DIFFERENTIAL EQUATIONS
Alejandro S. Jakubi
Mathematics and Computers in Simulation 67 (2004) 45-54.
 

No, in the OP's system, everything except t are constants. So in your example, a and B should be constants, and B=-a/t is not a constant. So, it is not a solution.