acer

32385 Reputation

29 Badges

19 years, 339 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

@AndrewG One difference is that you can assign the result from RandomVariable to a name, and then use that name in multiple instances (including one or more calls to Sample). But sometimes you might not wish or need to make that much effort. You might want to create a sample as a one-off operation, in which case a call to Sample(Normal(...)) is a more convenient syntax.

@vv My results could be "fortuitously" predicated upon this behavior,

restart:

is( y<=0 ) assuming Or(y<0,y>0,y=0);

                                                           false

is( y<=0 ) assuming Or(y<0,y=0,y>0);

                                                            true                                     

simplify((y^2)^(1/2)) assuming Or(y<0,y>0,y=0);
                                                           | y |

simplify((y^2)^(1/2)) assuming Or(y<0,y=0,y>0); # !!

                                                             -y

@vv The latter cases, where it gives up at csgn, or refuses to combine a product or two radicals, may be indicate one or more parts of the problem. (It's just a guess, but the former case might relate to something baulking on _Envsignum0...)


restart;

r:=evalc(sqrt(x+I*y)):

temp:=simplify(expand(r^2)) assuming x::real, y::real;

x-((1/2)*I)*(2*(x^2+y^2)^(1/2)+2*x)^(1/2)*csgn(-y+I*x)*(2*(x^2+y^2)^(1/2)-2*x)^(1/2)

simplify(combine(temp)) assuming Or(x<0,x=0,x>0), Or(y>0,y=0,y>0);

x+I*y

simplify(combine(temp)) assuming Or(x<0,x=0,x>0), And(y<>0,y::real);

x+I*y

simplify(combine(temp)) assuming Or(x>0,x=0,x::real), And(y<>0,y::real);

x+I*y

simplify(combine(temp)) assuming Or(x<0,x=0,x::real), And(y<>0,y::real);

x+I*y

simplify(combine(temp)) assuming Or(x>0,x=0,x::real), And(y<>0,y::real);

x+I*y

simplify(combine(temp)) assuming Or(x<0,x=0,x>0), y::real;

-I*csgn(-y+I*x)*abs(y)+x

simplify(combine(temp)) assuming x::real, And(y<>0,y::real);

x+((1/2)*I)*(2*(x^2+y^2)^(1/2)+2*x)^(1/2)*signum(y)*(2*(x^2+y^2)^(1/2)-2*x)^(1/2)

simplify(combine(temp)) assuming x::real, Or(y>0,y=0,y>0);

x-((1/2)*I)*(2*(x^2+y^2)^(1/2)+2*x)^(1/2)*csgn(-y+I*x)*(2*(x^2+y^2)^(1/2)-2*x)^(1/2)

 


Download csgnhmm.mw

Did you try it using Int instead of int? That should avoid the symbolic integration and allow fsolve to use evalf(Int(...)) which is numeric integration.

You might need to use the digits and epsilon options in the call to Int, to ensure that the numeric integral is finely enough resolved for fsolve to satisfy itself about accuracy of the root. Quite often one needs the result from evalf(Int(...)) to be at least one or more decimal digits more accurate than Digits, for this use of fsolve.

acer

@Christopher2222 It is not necessary to load geometry[point] (which rebinds point to geometry:-point) or the full geometry package in order to make sensible use of the geometry:-distance command through use of its shorter form name distance.

Your last clause above does not follow, "...and so without also loading (geometry,points) distance is no use by itself." You don't have to load "geometry,points" (which is a term used above to mean the rebinding of name points, as incurred by the calls to with) in order to use the geometry:-points command.

You could also use the longer form command name geometry[point] to set the points. In the following example geometry[points] is not loaded, and the full geometry package is not loaded, and name points is not bound to the name geometry:-points. But the shorter "abbreviated" form distance is used.

restart;

with(geometry,distance);
                           [distance]

geometry[point](a,2,3):
geometry[point](b,1,1):

distance(a,b);
                              (1/2)
                             5     

 

 

@erik10 This could also be set up to use combine(...,units) rather than simplify (if one doesn't want the effects of simplification on other aspects of the expressions).

 

restart;

with(Units:-Standard, :-`*`):

E:=[5,12,17]*~Unit(J);

m:=[2,4,6]*~Unit(kg);

[5*Units:-Unit('J'), 12*Units:-Unit('J'), 17*Units:-Unit('J')]

[2*Units:-Unit('kg'), 4*Units:-Unit('kg'), 6*Units:-Unit('kg')]

#
# `solve` will return two roots, because of the square.
#
map(simplify@[solve], E -~ ( 1/2*~(m*~(v^~2)) ), v );

[[5^(1/2)*Units:-Unit(('m')/('s')), -5^(1/2)*Units:-Unit(('m')/('s'))], [6^(1/2)*Units:-Unit(('m')/('s')), -6^(1/2)*Units:-Unit(('m')/('s'))], [(1/3)*51^(1/2)*Units:-Unit(('m')/('s')), -(1/3)*51^(1/2)*Units:-Unit(('m')/('s'))]]

#
# For the love of tilde.
#
simplify~( [solve]~(E -~ ( 1/2*~(m*~(v^~2)) ), v ) );

[[5^(1/2)*Units:-Unit(('m')/('s')), -5^(1/2)*Units:-Unit(('m')/('s'))], [6^(1/2)*Units:-Unit(('m')/('s')), -6^(1/2)*Units:-Unit(('m')/('s'))], [(1/3)*51^(1/2)*Units:-Unit(('m')/('s')), -(1/3)*51^(1/2)*Units:-Unit(('m')/('s'))]]

#
# We could also select just the first entry from each result from `solve`.
#
map(`?[]`, map(simplify@[solve], E -~ ( 1/2*~(m*~(v^~2)) ), v), [1] );

[5^(1/2)*Units:-Unit(('m')/('s')), 6^(1/2)*Units:-Unit(('m')/('s')), (1/3)*51^(1/2)*Units:-Unit(('m')/('s'))]

#
# For the love of tilde.
#
map(`?[]`, simplify~( [solve]~(E -~ ( 1/2*~(m*~(v^~2)) ), v ) ), [1] );

[5^(1/2)*Units:-Unit(('m')/('s')), 6^(1/2)*Units:-Unit(('m')/('s')), (1/3)*51^(1/2)*Units:-Unit(('m')/('s'))]

 

 

Download moretilde.mw

And I suppose that last one line could also be done, with even more tilde and less map,

  op~( 1, simplify~( [solve]~(E -~ ( 1/2*~(m*~(v^~2)) ), v ) ) );

Do you intend that to be a function call to R, or R*(x/L)^n ?

acer

@vv In Maple 2016 calling simplify at the top-level makes a call to simplify(...,size) before returning, by default.

Passing the option ':-applysimplifysize'=false to the top-level call to simplify disables this.

simpsize2016.mw

See also the output from showstat(simplify) .

@erik10 

restart;
with(Units:-Standard, :-`*`):
E:=[5,12,17]*~Unit(J);
m:=[2,4,6]*~Unit(kg);
v:=sqrt~(E/~(m/~2));

# explanation...
m/~2;
E/~%;
sqrt~(%);

# confirmation...
E = 1/2*~(m*~(v^~2));

Or are you asking for the much stronger result of programmatically constructing the statement vv:=sqrt~(EE/~(mm/~2)) given an arbitary input expression such as EE = 1/2*mm*vv^2 and knowledge about which names represent indexable structures? It might be done in part using the indexable `~` command. For example the infix syntax bbb *~ vvv can be programmed as `~`[:-`*`](bbb, ` $`, vvv) .

@EGalceran It's not clear to me what is your outstanding "tiny issue".

You should not continue with your original approach. It'll be too clunky to always work managebly.

If you do not first declare the Array ( like say T:=Array(0..nx,0..tmax,datatype=float[8]) ) then you'be be assigning into an implicitly created table rather than an Array.

The plots:-surfdata command expects data in an Array or a Matrix, and not a table. A table is a structure that can be indexable by anything, and is not appropriate for your tasks. A float[8] Array or Matrix is appropriate.

The gridsize=[m,n] option to plots:-surfdata may not be properly documented, and I'll check and submit a bug report. But I can tell you what it does, by inspection. It make surfdata interpolate the input data, up front. That is, it takes the original data (in your case the (nx+1)-by-(tmax+1) Array of values) and interpolates to get a finer Array of m-by-n values. The new finer grid of values will match at the points in common with the coarser grid, but it'll also contain additonal values for points between the original data points, and the implied surface will satisfy certain continuity and differentiability requirements. You can call surfdata with and without that option, in the code I gave, to see the effect.

That mentioned interpolation has nothing at all to do with the mathematical concept of integration. I don't understand why you mention Romberg or use the word integrated. You might be asking about some additional goal, or you might have simply misunderstood the technical term I used.

Your original approach can be made to work if your use the restricttoranges option of the plots:-densityplot command, and ensure that the grid size it uses matches the dimensions of your T table exactly, and ensure that it accesses T values indexed in the same way that they're assigned (in your code, by integer values, but you could alternatively store them as floats).

But it's awkward, mostly on account of using T like both an array and a function call at the same time.

restart:
with(plots):

nx:=20: tmax:=50: T1:=1: T2:=10: L:=1: k:=1: rho:=1:
cp:=1: chi:=k/rho/cp: h:=L/(nx-1): t:=1e-3:

for k from 0 to nx do T(k,0):=T1 od:

for w from 1 to tmax do
  T(0,w):=T1: T(nx,w):=T2:
  for q from 1 to nx-1 do
    T(q,w):=T(q,w-1)+chi*t/h^2*(T(q+1,w-1)+T(q-1,w-1)-2*T(q,w-1));
  od: od:

ft:=proc(x,y) T(trunc(x),trunc(y)); end proc:

densityplot(ft, 0..nx, 0..tmax, grid=[21,51], restricttoranges,
            #colorstyle=HUE,
            style=surface);

Here's an idea for scaling intensity by convergence rate. Lighter means it took longer, but the black regions (exhibited when there is no converegence within maxiter iterations) still means failure to converge. You can play around with it. newtbasin2.mw

@Kitonum The multiple Questions by this member look like coursework, to me. If that is so then I would expect the instructor intends the computations to be done in binary, rather than being computed base-10 with fore and aft conversions. Just a thought.

@Doug Meade I removed the multiple angle-bracket sideways-chevrons (red prompts) from the Execution Groups that defined the procedures. If you recall, the bug in Maple 2015.0 was that the GUI was wrongly interpreting some lines (which preceded a line with a chevron) within the same Exec Group as terminated statements.

The one I uploaded runs ok in Maple 2015.0, while the original did not. Both are fine in Maple 18.x, Maple 2015.2, Maple 2016.x, etc.

By "removed the multiple chevrons" I mean that I cut and pasted every line in the multi-line Exec Groups, by hand, using Shift-Enter to get to new input lines (without additional chevrons/prompts).

There was nothing that needed fixing in the code itself, as your syntax was all correct.

@brian bovril You will get the error message "reserved word `uses` unexpected` if you attempt to run Doug's worksheet in Maple 2015.0 because of this version-specific bug.

That bug is fixed in the point-releases. If you are already using Maple 2015.0 then you should consider upgrading (for free) to Maple 2015.2 which you can obtain here.

Here is Doug's sheet, edited to work in Maple 2015.0. Langford_2015.0.mw (Doug, please let me know if you'd like to copy and repost, or if you'd like me to remove this link to your material.)

First 305 306 307 308 309 310 311 Last Page 307 of 592