Carl Love

Carl Love

21223 Reputation

24 Badges

8 years, 249 days
Natick, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

@nm You wrote:

  • Error, (in my_module_name:-dsolve) assertion failed in assignment to ode_obj, expected ode_type, got _m1657072644000 

Okay, this is some progress, because this error message indicates (because of the strange name _m1657....) that an object module rather than just a symbol was being passed between procedures. The problem is now that it doesn't recognize that object as being type ode_type. Both immediately before and immediately after you receive this error, at the top (global) level, give the command TypeTools:-Exists(ode_type).

  • Right now, everything is working fine, once I remove the ::ode_type from the local variable definition and keep the assert there also.

That's an unsatisfactory solution, as you likely realize. But the more-important thing is is that returned object of the correct type, even though perhaps that type can't be properly named?

I look forward to your MWE that truly encapsulates the issue. This problem is something that I've struggled with myself: An interconnected family of modules, some of which define types in their ModuleLoad, others with module locals declared to be of those types, running under assertlevel=2. There is some deep-seated bug in this situation, even when none of the modules are objects. 

@Gabriel samaila There is nothing in the code posted in my Answer above that won't work in Maple 16. If your original code works, then that code will work. Could you post a new executed worksheet showing it not working?

@Kitonum If you use plot3d for a curve, as you just showed, it does the computations as if it were doing a surface, producing a 49x49x3 MESH that is constant along one dimension. The black that you see is the grid lines of that mesh "mushed" together under the default style= surface. Thus, if you changed that to style= wireframe, it would respect your color setting.

Thus, I fully stand by my statement "plot3d is only for plotting surfaces", because the data structure produced is for practical computational purposes a surface, even if a topologist would formally call it a curve.

@Kitonum I wonder why I needed to add some transparency to the surface and you did not. I'm using Maple 2021.

@nm Yes, I was writing my Answer at the same time as you were writing your Edit.

You wrote:

  1. The other proc called is returning back an object of ode_type....
  2. things work for other types, like integer, string, etc....

Neither of those statements are true. Perhaps you should post an example that leads you to believe that 2 is true.

A declaration of the form local A::typeA; does not create an entity A such that type(A, typeA) is true. Rather it checks (under assertlevel=2) that that is true for every := assignment made to (and it may check some other forms of assignment also). is just type symbol until you make an assignment to it. In the case at hand, you've never made an assignment to ODE.

You'll need to be more precise about what you mean by "touch", because a circle can be found for any 3 noncollinear points. Touching could mean a shared tangent line, a shared radius of curvature, or perhaps something else.

In addition to avoiding the warnings, Joe's advice will vastly improve the readability of your code.

@J F Ogilvie Yes, I think that the one-argument add was added in Maple 18.

Do you want vertical fractions (i.e., with a horizontal fraction bar), which use more vertical space and less horizontal space, or horizontal fractions (i.e., with a slant fraction bar)? In either case, the parentheses are superfluous, so do you want them anyway? To save space, do you want the 3 as close as possible to the Pi?

Is this for a 2D plot (thus, the tick labels are in fixed positions), or a 3D plot (where the tick labels may reorient when the plot is rotated)?

As far as I'm aware, most of the typesetting tricks that work for other mathematical text within a plot (other than tricks involving the textplot command!) will also work for tick labels.

@one man However, there are numerous other typesetting and inert-object-creation techniques, especially for mathematical text appearing in plots, that are far more sophisticated than that. Many of these are either poorly documented or not formally documented at all; however, in these undocumented cases, the features used are usually standard to the "markup" family of computer languages: HTML, XML, MathML, etc.

What you propose is indeed useful in many cases, but I think not in this case because it increases the horizontal space used. And it is one of the simplest of all solutions and commonly used, so it's worth putting on the table. I posted this Reply not to denigrate your Answer, but simply to make sure that the OP was made aware that there are numerous other options.

@maxbanados Answering that competely would involve me looking into the internals of define. Other the other hand, it's very easy to produce a symmetric version of any function, and I just posted an Answer to that effect in your previous thread.

@maxbanados Perhaps this example will illustrate sufficiently for you what is meant by "subs does not evaluate":

subs(x= 0, sin(x));
                             sin(0)

eval(sin(x), x= 0);
                               0

 

@maxbanados By "that whole family of commands", I mean applyruledefinedefinemorematchpatmatch, and typematch. Maple's type subsystem has a very rich and highly logical syntax easily capable of expressing types of arbitrary complexity, with subtypes nested arbitrarily deep (even recursively). The commands listed above use a variation of a miniscule subset of that syntax. That variation is incredibly frustrating and illogical (and even sometimes self-contradictory) to me. The command compiletable also uses that variation; however, I didn't include it in "that family" because it has important functionality that'd be elsewise difficult to duplicate. Also, it appears to me (although I've only checked superficially) that there's been no significant update to these commands in over 20 years. I'd guess that whoever developed these moved on from Maple.

The premier command for extracting subexpressions based on their type is now (and always has been) indets.

Regarding integrals with external coefficients: If you can tell me how you want to handle these special cases, I can advise further:

  1. 2*Int(...)*Int(...)
  2. 2*x*Int(f(x), x) #indefinite
  3. 2*x*Int(f(x), x= a..b) #definite
  4. 2*Int(...) / Int(...)

Regarding deconstruction: Maple's type system is great, one of the really powerful parts of the language. However, often we can assume that an expression is syntactically correct (so, some other syntax checker has already done the type work). Then the deconstruction can use the simpler commands oplhsrhs, etc. Here's an example:

IntDecon:= proc(J::specfunc(Int))
local v:= op(2,J);   
    Record(
        "operator"::name= op(0,J),
        "integrand"::algebraic= op(1,J),
        "intvars"::list(name)= 
            `if`(v::list(name= range), lhs~(v), [v]),
        "lowerbounds"::list(algebraic)= 
            `if`(v::name, [], (lhs@rhs)~(`if`(v::list, v, [v]))),
        "upperbounds"::list(algebraic)=
            `if`(v::name, [], (rhs@@2)~(`if`(v::list, v, [v]))),
        "options"::list({name, name= anything})= [op](3.., J)
    )
end proc
:
I1:= Int(x*y, [x= -1..1, y= -2..2], numeric):
I1d:= IntDecon(I1);
I1d := Record(operator::name = Int, integrand::algebraic = x y, 
  intvars::(list(name)) = [x, y], 
  lowerbounds::(list(algebraic)) = [-1, -2], 
  upperbounds::(list(algebraic)) = [1, 2], 
  `options`::(list({name, name = anything})) = [numeric])

I1d:-intvars;
                             [x, y]

 

Regarding evalb and Categorize: No, I think that Categorize is a great command. And recall that the problem in your Question has nothing to do with typematch either! Please post that example.

@maxbanados The expressions X and X1 are not "identical". They may be mathematically equivalent (hopefully that's true), but the fact that they're not identical can be easily seen by comparing the first terms of the integrands. So, this is not a problem of typematch. I'd like to figure out why X and X1 aren't identical. So far, I know that it has something to do with the two different forms of inputting a double integral: Int(Int(..., x= ...), y= ...) and Int(..., [x= ..., y= ...]).

I would strongly discourage you from using typematchpatmatch, and that whole family of commands. I have absolutely no use for them. The fact that they rely on the order of the terms (as shown by this example) is part of why they're worthless. 

Also, you cannot rely on the prettyprinted display of an expression to reveal its internal structure. The command lprint is better for that. Compare lprint(X) and lprint(X1).

@Ivi You most definitely have not found the solution! Your 2 Replies prior to the most recent are mathematical nonsense. They express something which is trivial, and mathematically true, but which has nothing to do with solving your original problem. The right-sided derivative at t=0 is 5/2. If you'd like Maple to say that, we can work on that. There are only two reasonable answers to this Question, depending on how you define "derivative": undefined or 5/2.

undefined is a mathematically valid answer to many problems; it is not an error message.

 

3 4 5 6 7 8 9 Last Page 5 of 592