acer

32353 Reputation

29 Badges

19 years, 331 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by 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.)

@Kitonum It might be interesting to see whether the Bits package makes at least some aspects of these kinds of computation easier (to author, or understand), or not.

@AdamBarker I suspect that there is a scaling of the iteration count that can visually convey that information, yes. It was the code comment "## Optional, scale the saturation by the time to converge" where I did something for that which works visually only for a smaller maximal iteration limit.

It likely can be done with a suitable call to `ln`, say. I'll play with it and let you know if it looks nicer. I'm not sure within which channels (H,S, or V) it's be more useful. I should try and make the color-selector faster too, where it assigns a color based on which root it's converging towards.

How do you expect that to work when you define ex1 and ex2 as operators but pass use them like expressions (in x,t,z) when calling implicitplot3d?

What's that extra `e` doing inside ex2?

acer

You aren't going to be able to distinguish amongst roots with the same absolute value, using that Newton command. So if you're trying to color by the value of the roots then that command won't always get you there.

But it should be possible using the IterativeMaps:-Escape command, by using the real and imaginart pats of converged value for two separate layers in the result.

What platform and OS are you using? 32bit, 64bit, OSX, Windows, Linux? Any other OS details? Does the Compiler work for you, otherwise?

I can't see the images of code you posted in your question. Perhaps upload a worksheet (green arrow) along with OS details.

acer

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