acer

32308 Reputation

29 Badges

19 years, 310 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

@nm Multi-line comments have been available in 1D Input since Maple 13 (released, 2009).

It's not available in 2D Input.

ps. tangent: some people set their Maple prompt to (**) so that they can copy&paste to&from other plaintext locations without having to erase the prompt.

@Mathrookie94 You could remove the statement that assigned to Digits, and then restart using either the restart icon on the menubar or the restart command.

It's often useful to begin worksheets with the restart command (before your with calls). That way when you use the !!! icon on the menubar you get a fresh computation, ie. without interference from previous assignments to names.

As I wrote before the original worked for me without changing Digits, so there was already evidence that working precision was not the issue.

I wonder whether it might have something to do with "saved rtable" data, stored due to output.

It might be interesting to know whether it still occurs if you,
1) use the menubar to remove all output.
2) save
3) re-open, then execute

Another (less likely, IMO) possibility might be something related to the new kind of display of rtables (eg.Matrix), with the sliding pan funcitonality.

All this is supposing that it doesn't happen for other worksheets you make yourself, and that your installation is OK.

@Carl Love I tried fooling with interface(displayprecision), as well as Numeric Formatting, and also the GUI's Options->Precision. Wasn't able so far to get the reported effect, but who knows those mechanisms can be weird.

@Mathrookie94 

It might be worth checking whether your Gym:-QQplot procedure differs from mine.

What does this look like?

   showstat(Gym:-QQplot);

@Khair Muhammad Saraz In these atatchments you can simply change the N value (posint > 1) and re-execute.

Here are both surfaces, default style=patchcontour by surfdata for the N=7 approximate surface.

DQMSixth_2_accc.mw

And here are both surfaces, with style=surface for the exact surface. (Higher order interpolation to a finer grid is possible for the surface constructed from the approximate data, but perhaps not in the spirit of what you want.)

DQMSixth_2_ac_lininter.mw

It might be fun to wrap all the approximation computation in a procedure, compute & store for several N values, and display as an animation with the exact surface as background.

You are not being clear about how you want the "one 2d plot" to appear.

Construction of the 2D curves has already been show to you in a few attachments. You really ought to be able to put those into a single plot, along with the exact curves. This is your coursework/project, after all.

@Mathrookie94 It works as you expected, for me, without any change to Digits.

Do you have some custom initialization file? I don't know how to test which "version" of Gym I have.

worksheet_-_linear_reg_and_residuals_for_normal_distribution_ac2024.mw

@Mathrookie94 Try something like,

   Digits:=20:

at the start.

(I can't test easily, because you haven't provided the data.)

@Khair Muhammad Saraz You can now just change the N value, without other changes needed.

Check for mistakes.

DQMSixth_2_acc.mw

We cannot test the same example without the same data.

I already have a version of the Gym package (an add-on), but I don't know what you mean by, "...read the mean-value, mu". How did you get at the computed mu value?

What happens if you increase Digits, the working precision? Eg, Digits:=20 ?

@vv very nice. That's a graceful way to get the factored form.

sol := dsolve({diff(f(x), x) = a*f(x)^(2/3)+b*f(x), f(1) = c})

new := simplify(eval(sol, [a = 0.768e-1, b = -0.102e-1, c = 59]))

f(x) = -48.08619870*(exp(0.34e-2-0.34e-2*x)-2.070558790)^3

@Khair Muhammad Saraz Something like the following?

I just uncommented the line with a call to surfdata, from my earlier worksheet, and made a few adjustments to color, etc.

dq_code_1_acc2.mw

@Khair Muhammad Saraz Please put your close followups for this here, not in wholly separate new Question threads.

If nobody responds then perhaps you need to be much more clear about exactly what you want the plot(s) to represent.

Perhaps you just want the N final spacecurves and exact solutions, alongside each other in 3D? Or do you want those approximate spacecurves animated (by iteration number)?

Something else?

If it's so very important to you then why don't you take a few minutes to describe what you want explicitly, in detail? You still have not described what exactly you want.

@Khair Muhammad Saraz Is there a reason that you cannot provide us with the code that generates your data?

You might be able to put the numeric data into a Matrix, and then call plots:-surfdata on that. That might depend on whether the data is uniformly spaced in both independent variables. Even if not uniformly spaced you might also be able to do it similarly with a 3D Array (MESH style).

The most useful way to help would be if we had the full code.

@sursumCorda Recall how I was waffling on about evaluation rules? Well, there are a few more interesting bits. The assuming mechanism does have delayed evaluation of its first argument, by ways of its first parameter being declared ::uneval. It uses the delayed evaluation as an opportunity to place its assumptions (which it gets rid of at the end, by resubstituting with original names).

The assuming mechanism is still more complicated, though. Part of that is to avoid placing assumptions on keyword parameters, and so forth. But it also contains hard-coded knowledge of certain commands. The following example illustrates it's avoidance of placing assumptions on the name in the argument name=range, ie. the variable of integration. It'll place them on names in the range, though. I suppose one might phrase that avoiding getting in int's way of making its own assumptions on the variable of integration.

restart;

bar := proc(X) map(about,_passed); 1; end proc:

 

F(bar(x), x=0..1) assuming positive:

Originally x, renamed x~:
  is assumed to be: RealRange(Open(0),infinity)
 

int(bar(x), x=0..1) assuming positive:

x:
  nothing known about this object
 

F(bar(x), x=0..x) assuming positive:

Originally x, renamed x~:
  is assumed to be: RealRange(Open(0),infinity)
 

int(bar(x), x=0..x) assuming positive:

x:
  nothing known about this object
 

F(bar(x,X), x=0..X) assuming positive:

Originally x, renamed x~:
  is assumed to be: RealRange(Open(0),infinity)

Originally X, renamed X~:
  is assumed to be: RealRange(Open(0),infinity)
 

int(bar(x,X), x=0..X) assuming positive:

x:
  nothing known about this object

Originally X, renamed X~:
  is assumed to be: RealRange(Open(0),infinity)
 

Download assuming_mech_h.mw

So, now back your followup example. I'll just use an unassigned name f rather than unnecessary obfuscation via RETURN, error, etc. We see here that assuming will not place the assumption on the name appearing on the LHS of the name=range argument in the int call, even if it does appear in the RHS or that argument. This finesse is special to assuming's treatment of a function call to int, but not of some other function call.

restart;

S(f(about(x),coulditbe(x = 1)), x = 0 .. x) assuming 0 < x, x < 1;

Originally x, renamed x~:
  is assumed to be: RealRange(Open(0),Open(1))
 

S(f(false), x = 0 .. x)

restart;
int(f(about(x),coulditbe(x = 1)), x = 0 .. x) assuming 0 < x, x < 1;

x:
  nothing known about this object
 

f(true)*x

Download int_assuming_p.mw

You also mentioned nested integrals, but gave no examples. I'll mention that there is a big difference in how int can function between,
    int(int(int( f(x,y,z), x=a..b), y=c..d), z=e..f)
and,
    int( f(x,y,z), [x=a..b, y=c..d, z=e..f] )

In the former, nested case the inner int call is evaluated with no knowledge of the outer integration's variable's range. Since int follows standard evaluation rules the inner one is computed before the outer ones act. But for the latter, collapsed case int has the opportunity to place assumptions on the outer integrations' variables, prior to computing the inner integral. It's similar for inert Int.

See exports CollapseNested and ExpandMultiple of the IntegrationTools package, for programmatic conversion between these two forms, for Int or int.

First 38 39 40 41 42 43 44 Last Page 40 of 591