Download rv_pdf_prod_ex.mw

The above four choices of assumptions handle all real t, for PDF(x*r, t). It's straightforward to combine the pieces into a piecewise.

I mentioned in your previous Question thread that I wonder whether it really is necessary to change all your module exports/locals, etc, just to get it to work in Grid.

When I want to avoid typing out the long-form names of module members I take one of the following two approaches. Neither of these ever involves utilizing use, which I dislike and find problematic.

1) Utilize uses instead, per procedure. Yes, I might have lots of procedures, but I only need to write the uses line once at each beginning, and I still find it far easier than using a long form each time I want to call a member.

Download mod_uses.mw

2) Utilize a $define directive (only once per file), in a source text file that I read. The code to use would look like,

    read "nm_mod.mpl";  # or omit this altogether if I had stored it in a .mla archive
    A:-main_entry();

and the test file contains, say,

$define TOX some_very_long_name:-toX

A := module()

  export main_entry:=proc()
     B:-foo();
  end proc;

  local some_very_long_name:= module() #NOTICE, now local
        export toX:=proc(n::integer)::integer;
              n+1;
        end proc;
  end module;

  local B:= module()
     export foo:=proc()
         TOX(1);
     end proc;
  end module;

end module:

$undef TOX

You only need to call rand(...) once, and then you can utilize its returned procedure many times. (There are other ways, but if you're intent on using rand...)

Also, your approach to compute the cumulative sum repeatedly adds all the way from the start, for each i=1..N, which is relatively inefficient. It repeats each previous step's work, and so has a higher than necessary order of computational complexity.

restart;
randomize():
R := rand(1..6):
N := 10^2:
y := [ seq(R(), i = 1..N) ]:
Y :=  map(yy->ifelse(yy<=3,-1,1), y):
C := Statistics:-CumulativeSum(Y):
plot([$N],C);

There are more efficient ways to accomplish this. But this should get you started.

You can compare timings for just the cumulative sum computation. (I haven't made lots of other possible speedups; just focusing on that difference.)

restart;
randomize():
R := rand(1..6):
N := 10^4:
y := [ seq(R(), i = 1..N) ]:
Y :=  map(yy->ifelse(yy<=3,-1,1), y):

CodeTools:-Usage([ seq(add(Y[ .. i]), i = 1..N) ]):
memory used=1.23GiB, alloc change=45.16MiB, cpu time=4.64s, real time=4.64s, gc time=278.23ms

CodeTools:-Usage(Statistics:-CumulativeSum(Y)):
memory used=246.43KiB, alloc change=0 bytes, cpu time=1000.00us, real time=1000.00us, gc time=0ns

LinearAlgebra:-Norm(Vector[column](%)-Vector[column](%%));
                               0.

The performance gaps widens as N increases.

If you are supposed to write your own routine for computing the cumulative sum then please let us know. At the ith step you just need to add the previous step's (i-1)th sum to the ith y entry.

Your code calls eval like this,

   eval(M, [:-alpha=alpha, :-gamma = gamma, :-mu = mu, :-lambda=lambda, :-B[1]=B__1, :-B[2]=B__2],:-beta[0]=beta__0)

but the closing right bracket is in the wrong place, ie. before beta[0]=beta__0. So you're invalidly calling eval with three arguments. That's what the error message tells you, too. It should be,

   eval(M, [:-alpha=alpha, :-gamma = gamma, :-mu = mu, :-lambda=lambda, :-B[1]=B__1, :-B[2]=B__2,:-beta[0]=beta__0])

Also, you're code tries to substitute for global :-gamma, which you've declared local at the top-level.

Also, some parts of your expression might take either very large/very small values, when done computed at hardware precision. You can force use of "software" floats instead of hardware double-precision. And you might also want to experiment with how much (if any) increased working precision might benefit the accuracy.

You might also need to adjust your hard-coded view, in the plot3d call in procedure G.

plot1_ac.mw

ps. One of the useful ideas behind having such a G procedure is that you can just call it with numeric arguments and get a single plot. That's easier to debug and figure out than is a whole Explore call. Focus on getting a/any good result from G. Then, when that works (at all!) try Explore.

Please check for mistakes. I may have misunderstood, and I wrote it quickly.

The basic idea is that if you can get at the allowed functions (of the Xi names) then you could freeze those function calls. The resulting (frozen) placeholder names might then be added to the set of Xi names and done altogether with the methodology for handling your first bullet point cases.

If you have some particular allowed "functions" in mind then you could adjust the typefunc
specification below, changing from name to something else (eg. identical(...), or other...)

Download typefunc_ex.mw

Download grid_set_module_local.mw

Yes, it is a bug.  If x is real then at least one of the pair is satisfied.

A developer might classify it as a "weakness".

I couldn't get it with a single is call and unrestricted real x (or equivalent) and the point is that ideally that would be possible.

Download is_trig_01.mw

You might guess that I have a hunch that an underlying problem is with combining such pairs, rather than just internal problems with trig handling...

A helping prod, that happens to work:

is(x*y*z = 0) assuming Or(x=0,z=0);

             true

I suppose that `solve` could be leveraged to get that Or() construction programmatically. Multiple results from solve can be taken as Or, and individual results within that can be taken as And (or just themselves if a singleton sequence).

I like nm's Answer.

In your Document, the expression assigned to Ghat contains a name-quoted minus symbol instead of just the infix minus.

That makes it a name, not the expected arithmetic operator. And the spaces around that name make the whole thing get interpreted (2D Input) as implicit multiplication.

It parses your form as,
   2*sqrt(2)*GAMMA(5/2)*`-`*(7*sqrt(2))/6*GAMMA(7/2)/(r^(5/2)*r^(7/2))

If I replace it with just the usual infix minus sign then it goes as expected.

Download asyapprox_ac.mw

Here I've used Maple 2022.2, since that's the version in which your attachment was last saved.

It can be simplified with just,

   simplify(B1,exp)

however below also I give a few minor variants on the final form (and checks on all results).

Download simplify_3_ac.mw

Are you trying to say that previously unopened .mw files on your machine have changed, as saved files?

Or are you trying to say that when you now Open any .mw file (Document) that was previously untouched (as a file on your OS) that the GUI opens it wrongly, and alters the input lines as displayed.

If the latter, then are you also saying the uninstalling/reinstalling doesn't help? Are you sure that when uninstalling your personal GUI Preferences file is removed? It would usually be somewhere like this on MS-Windows:
    C:\Users\%USERNAME%\AppData\Roaming\Maple\2023\Maple.ini
If that's still present (on uninstallinging) then you might consider removing it prior to reinstallation.

(It seems weird, if a wholly clean install were now to show different behaviour when opening files that haven't been changed since before the problem started.)

Here are some fixes that allow the problematic sections 17.6, 17.9, and 17.10 to run in a newer version such as Maple 2018 or Maple 2024.

ch17_acc_2018.mw

The problems come in the following varieties:
i) Failure of plots:-spacecurve with operator-form calling sequence. Remedy is simple: since the operators return unevaluated when passed a name, replace the operator names (in the first argument triple) with those same names applied to `t`, and use t=range instead of just range. Or just use plots:-odeplot (which is usually better, btw), in its usual way. (I will submit a bug report; it broke in Maple 2016.)
ii) Use of bare name y alongside aliases to indexed names y[i] in section 17.9.
iii) Dubious recursive definition in loop in section 17.9,
    for i from 0 to e_order do   
        eta[i] := t -> eta[i](t)
    end do:
The whole alias/macro/defn business of that section is obfuscated.
iii) Repeated (chained) aliases in section 17.6, which is hokey.
iv) Access to casesplit results by location in the returned sequence, in section 17.10, which was fragile programming. Changed it to access by property of nontriviality does better, including in Maple 2024 whose casesplit result differs in form/nature from that of Maple 2018.
v) I also added a few normal/simplification/sort calls, to get some of the (mathematically) ok results to look&feel even more like in the "target" .mws file's output.

There is an example about this on the Help page for assuming. (It's the example about a procedure f).

The essence is that the usual assuming facility does not place assumptions on variables inside the procedure body, up front (which is how it works).

That page documents the following as an alternative, which leverages a revised mechanism that does what you are after:

Download assuming_ac.mw

Another way to handle your example is to first assign your procedure call to an expression, in which case the usual assuming mechanism "sees" the relevant variable name.

Download assuming_acc.mw

Notice the difference, according to whether we assume m__1 is greater than or less than 0, or just real.

Download simplify_side_radical.mw

Here are a couple of ways to get such an effect.

Download expr_inert_mult.mw