13561 Reputation

29 Badges

12 years, 17 days

On google groups. (comp.soft-sys.math.maple and sci.math.symbolic)

On stackoverflow.


MaplePrimes Activity

These are answers submitted by acer

I have some evidence that the result might be approximately -1.413e14  (obtained in about 6 minutes on a fast machine). I have to rush off, but I'll try and upload details, after a few more checks, hopefully this evening.

There have been many reports over the years from Danish students who have encountered worksheet/document corruption problems. I assembed a list a while back, and added it here.

There appears to be at least two sorts of problem:
1) entire loss of content, with saved .mw file becoming all null characters.
2) chopped XML in the .mw file, where the GUI does an imcomplete job of closing all tags reasonably when re-opening. (This can often be ameliorated by editing with a separate program by an expert, to recover more from the trailing chopped portion.)

I have previously submitted the whole set of links as a bug report. I'll also submit this (and another from a week or so ago).

Mapleprimes seems to see such reports soon after the start each school year, as new students get their assignments.

I don't know whether there is one or more causes. Use of Danish characters seems a likely culprit, but clearly that is difficult for the students to avoid. But I have also noticed that many of the "repairable" chopped worksheets contain several very large images, constructed and edited inplace with the drawing canvas functionality of the GUI. I suspect that those large canvas structures may trip up the GUI when saving. It's unclear.

Here is a suggestion for the Danish students. First, turn off auto-save, but save frequently. Save each time to a new and distinct file name, where I mean distinct from all previously saved instances. Each time you save, double-check that the newly saved document is not corrupted, by doing by Close and then re-Open on it. I realize that this would involve a great deal more effort.


                            3/5   1/5
                           5    24

Having said that, Markiyan's suggestion to convert first to radical does very well here. Several commands will produce the short positive radical result for that even without use of the abs command.


                             1/5  3/5
                           24    5


                             1/5  3/5
                           24    5


                             1/5  3/5
                           24    5

This is slightly awakward, and I wouldn't be surprised if there is a much simpler way, but...



`Maple 14.01, X86 64 LINUX, Oct 15 2010, Build ID 535952`

f[0] := sin:

plot( f[0](x), x=-2..2,
      labels=["x",`#mrow(msub(mn("f"),mn("0")),mfenced(mn("x"))`] );


plot( f[0](x), x=-2..2,
      labels=[K(x), K(f[0](x))] );

plot( f[0](x), x=-2..2,
      labels=[K(x), K(f[0](x))],
      labelfont=["Times", bold, 11] );






   Maple 2016.2, X86 64 LINUX, Jan 13 2017, Build ID 1194701

SolveTools:-SemiAlgebraic( {x^2+y^2+z^2 = 3, x+y+z = 3} );

                    [[z = 1, y = 1, x = 1]]

solve( {x^2+y^2+z^2 = 3, x+y+z = 3}, real, parametric, allsolutions );

                    [[z = 1, y = 1, x = 1]]

[edit] As for unloading the RealDomain package, try calling,


Note that the RealDomain package also exports things like `^`, so it matters if you constructed expressions before you unloaded the package. You can also force use of the so-called global commands, even when that package is loaded, using the colon-dash syntax. (It can get hard to read, though.)

I've been meaning to put this into a Maple 2017 cloud-package, after clean-up, re-factoring, and adding a Help page.

But attached below is a Document with your example.

The code which does the "degree-polar" stuff in in the Startup Region of the Document.

(I have to make some more adjustments, I see, since while revising to handle units in this "version" of it I've managed to make it lose some float-contagion. That just means that it keeps turning floats into exact rationals when combining the quantities. That's why I use evalf below. You could also use the right-click content-menu item "Approximate" when you want to turn results into float approximations. Earlier versions were here.)

In Maple 2017's GUI itself the units display more nicely.


interface(displayprecision = 5)




L := 200*`∠`(Unit('mH'), 90)


C := 100*`∠`(Unit('`μF`'), 90)


R := 30*`∠`(Unit(Unit('Omega')), 0)


U := 230.0*Unit('V')


f := 50*Unit('Hz')


XL := evalf(2*Pi*f*L)


XC := simplify(evalf(1/(2*Pi*f*C)))


Z := R+XC+XL





Perhaps one of these two (similar) approaches would work for you.

(Sorry, Mapleprimes doesn't seem to want to inline this attachment).

for i from numelems(arr) to 1 by -1 do
    # do something
end do


for i from numelems(arr) while i>0 by -1 do
    # do something
end do

There are several variations on these ideas. I've tried to do it so that the calls to plot take the argument DV = -5 .. 5 (ie. expression form, rather than operator form with just the range -5 ..5 ).

Note that I use two-argument eval (aka "evalat"), for example to evaluate the set of equations like {x=1.200, y=3.567} to extract the values 1.200 and 3.567. I consider this better than using a few op calls, or rhs of an indexed entry, etc, because it stands up when you change the variables names to things with a different lexicographic ordering, and it's also more clear what it's doing.


                         2        2        2        2      2      2
                ee := 6 d  t - 4 e  t + 2 f  t + 3 d  - 4 e  + 4 f


                               2               2              2
                    (6 t + 3) d  + (-4 t - 4) e  + (2 t + 4) f

Most Library commands are not thread-safe and will not function properly under the Threads package.

That includes `int` and `evalf/int`.

If your individual pieces are not too fast to compute then you could consider using the Grid package instead.

The problem may be related to entering Qgr in 2D Input mode, but I have yet to narrow it down.

The way you have defined your procedures (operators) the value of h is not taken until those procedures are called. So the value of h is not relevant at the moment the procedures are created.

When your loop is finished, the value of h is 51.

You problem is really about how to create a procedure with certain parameter values explicit in the procedure body. You problem isn't really about loop indexes. The name h needn't be a loop index, in order to have your need, is what I mean by that.

One way to get around this (quite intended behavior of procedures) by Maple is to declare h as global within the procedures. Since I consider using global variables to be poor programming I don't recommend this approach.

One popular other way is to use the unapply command from an expression in which the name h has already been replaced by a value. That's often short and convenient to do, but might not always suffice (or could be awkward to do properly) if your expressions aren't something you'd want fully evaluated. For your example the wrapping call to evalf is just such a wrinkle. See below.

Another way is to substitute the current value of (the loop index) h in as a replacement for a dummy name in a procedure (which acts like a template, then). This is more keystrokes, but pretty powerful.

You haven't show us the nature of any entries in and Q[i], or and x1[i] or y1[i] (for any i). So below I'll make something up.

If neither of these two approaches work for you, then upload the full code as a worksheet (big green arrow) and I expect it could be ironed out.



for h to 50 do :
  Z[h][1] := unapply('evalf'(subs(x = x1[h](s), y = y1[h](s), Q[h][1])), s) ;
  Z[h][2] := subs(__h=h, s -> evalf(subs(x = x1[__h](s), y = y1[__h](s), Q[__h][2]))) ;
  Z[h][3] := s -> evalf(subs(x = x1[h](s), y = y1[h](s), Q[h][3])) ;
end do:

Z[2][3](4*(1/50)); # What you had. Expected to not work.

[0.8000000000e-1, -0.8000000000e-1]

[0.8000000000e-1, -0.8000000000e-1]





I should also mention that you can print the bodies of the procedures, to see/check how the two approaches work (while differing in nature from each other). Notice how one of these has replaced all of the Q[i][j] and x and y, etc (which you may or may not want to have happen), while the other has not.


           s -> evalf([s, -s])


    s -> evalf(subs(x = x1[2](s), y = y1[2](s), Q[2][2]))

For the simple example shown, those approaches produce the same result. I could mention that the second will be slightly less efficient to run as each call to the procedures assigned to the Z[i][j] will perform the subs work (and so there would be duplication of effort when the same procedure is called for multiple values of the input s).

Yes, there is something akin to automatic simplification that can take place with the infix form of and yet not with its prefix form. Actually it's more of a premature evaluation under evalb (see below).

[ edit: removed confusing poor comparison with automatic simplification of f()+f() vs `+`(f(),f()). ]

The help page for and mentions evaluation of strict equality under evalb. That also affects `<>` by which I mean unequal. For the infix form of and the evalb evaluation causes instances of infix `=` and `<>` to prematurely become just true or false. (It's not an exact analog to f()+f() since that cannot be prevented from simplifying automatically to 2*f() prior to evaluation of f() through use of single left quotes aka uneval quotes. But as you've seen there are similarities, I think.) This affects mixtures like say,

   u>0 and x<>y

which becomes just u>0 via u>0 and true . For the prefix form the evaluation of the `<>` part doesn't happen right away.

T:=`and`(u>0, x<>y);
                    T := 0 < u and x <> y

  0 < u and x <> y

T; # causing another evaluation
                            0 < u

Notice that the first result in the group above has the infix form as output. The effect here is that eventually (with enough evaluations) the x<>y will become true (because of the and). If it weren't for the wrapping and then the x<>y would not get hit by evalb and thence evaluate to true.

                         R := x <> y

                           x <> y


One way to deal with this kind of thing is to use the prefix operator And instead of and.

Some of your other difficulties seem due to confusion between types and properties. For example is and assume deal with properties. They know of a real property. But there is no type real, so type evaluation (of double-colon, under evalb, under and)  produces the error message to that effect.

Your very last example does look like a weakness in Re.

I've heavily edited my Answer, trying to make my terminology more precise.

Using convert(...,base,2) ,

# Don't do something silly like assigning to the global name :-`2`.

p:=proc(x::realcons, ex::identical(:-exact):=NULL)
  local Ln,Ld,r;
  r:=convert(evalf(x),rational, ex);
  add(Ln[i]*`2`^(i-1), i=1..nops(Ln))
    /add(Ld[i]*`2`^(i-1), i=1..nops(Ld));
end proc:















p(-13.55555555, ':-exact');


















p(%, ':-exact');














1 2 3 4 5 6 7 Last Page 1 of 144