dharr

Dr. David Harrington

3481 Reputation

17 Badges

18 years, 93 days
University of Victoria
Professor or university staff
Victoria, British Columbia, Canada

Social Networks and Content at Maplesoft.com

Maple Application Center
I am a professor of chemistry at the University of Victoria, BC, Canada, where my research areas are electrochemistry and surface science. I have been a user of Maple since about 1990.

MaplePrimes Activity


These are replies submitted by dharr

I teach a short introduction to Maple course for graduate students in chemistry, and had to think carefully about this. I decided that since the point of the course is to teach them how to do math and simple programming with Maple rather than optimize the way the document looks, the simple logic of the worksheet mode was more suitable than document mode. 1-D or 2-D was a harder choice, and I let them submit in either. Some like 2-D and some 1-D. Those who choose 2-D seem to stick with it, even though it trips them up on occasion.

On the other hand, I demonstrate it all in 1-D. They will be looking at 1-D when displaying procedures, and if they end up doing any significant programming they will likely use it. I suggest that even if using 2-D they may wish to enter multiplication as * to avoid the errors of missing spaces, and to learn the 1-D notation at the same time.

I don't recommend extended typesetting, since seeing output with BesselJ will remind them how to enter that Bessel function. Like document mode, it is a feature for more advanced users, that they can teach themselves.

@Christopher2222 So if you are going to use the geometry package a lot, you can load all the commands using

with(geometry);

@adrian5213 Not sure what you mean by a "binary number" (a string of 0's and 1's? a sequence? a list?). If you are OK with a list of 0's and 1's then the following works.

n:=[1,0,1,0,1,1,0,0,1];
ListTools:-Reverse(n): #reverse order since Bits package works in lsb first order
Bits:-Join(%): #convert to internal (integer) format
[Bits:-GetBits(-%,-1..0,bits=8)]: #take the negative and convert back to a list
subsop(1=0,%); #force the first bit to zero

produces

[0, 0, 1, 0, 0, 1, 1, 1]

I assumed the input had first bit 1, but you would probably want to check.

This of course gets Maple to do the work. If you want to do it "by hand", then you could just construct the usual algorithm with list entries.

I also use eval(..., param) a lot. In many cases it is not too inconvenient to use

param:={a=-2,b=7};
eval('plot'(a*sin(x),x=0..b),param);

In Maple 18 or 2015.2 (I don't have 2016), when I convert to make DirectSearch.help the help doesn't seem to load from a location in the libname path (such as "C:/MapleLibs"), but if I move the DirectSearch.mla and DirectSearch.help files to the current directory, the help is available after the with(DirectSearch) statement. So perhaps the content is there?

@Dave L For the record, I did not post any files. Without the post that you have now deleted, it looks as though I did.

@Earl I loaded the DirectSearch  version 2 files DirectSearch.mla and DirectSearch.hdb (from the application centre) to "C:/MapleLibs".  I get the same warning as Markian Hirnyk and a small non-functioning DirectSearch.help **see edit** (but not the error message) when I use HelpTools:-Database:-ConvertAll(); in Maple 2015.2. But I can see the help contents as worksheets when I use

c:=HelpTools:-Database:-ExtractContentsFromHDB("C:/MapleLibs", "C:/MapleLibs/DirectSearch.hdb"):

So I'm guessing that if you follow the manual instructions in ?HelpTools,Migrate (assuming it is still there in 2016), you can probably migrate in a more laborious fashion.
 

Edit: Actually the .help file was functional if it and the .mla file were moved to the current directory.

@Majmaj If you really want Maple to do exact arithmetic, you want to just avoid floating point numbers (with a ".") and Digits altogether, and use rationals. So you could convert to rationals, do all your calculations and then convert back. The answers above effectively do that, but it seems simpler to use convert( ,rational,exact) and then evalf to the appropriate number of digits at the end. In the case of multiplication we can get the appropriate number of digits from the log of the denominator of the rationals, but as the others have pointed out, the general case is far from simple.

a:=convert(0.123456789,rational,exact);

123456789/1000000000

(1)

b:=a^2;

15241578750190521/1000000000000000000

(2)

evalf[18](b);

0.152415787501905210e-1

(3)

evalf[ilog10(denom(b))](b);

0.152415787501905210e-1

(4)

tofloat:=x->evalf[ilog10(denom(x))](x);

proc (x) options operator, arrow; evalf[ilog10(denom(x))](x) end proc

(5)

tofloat(b);

0.152415787501905210e-1

(6)

 


 

 

 

@Carl Love Good point. I always used to use just indets with a single argument, which would not consider Pi an indeterminate, then changed to indets( ,name) so I missed things like exp(a*d). (My recollection may be faulty, but I think very early Maple versions wouldn't have considered exp(a*d) an indeterminant.) If one has to give a very specific type specification, one wonders about the usefulness of indets, which is probably mainly used just for what the OP wanted.

Regards,
David.

@acer Interesting that the original answer with signum(t)^6 covers the t=0 case but the AllSolutions option does not.

@tomleslie I had in mind here that some integrals with infinite integrands are nonetheless finite, e.g., int(ln(x),x=0..1) = -1.

Regards,

David.

Well if you want phiB on the x axis and qB on the y axis then use

plot([phiB1,qB,qB=0..20]);

You still specify the range for qB, not phiB1, because you have phiB1 in terms of qB. If you want to know what value of qB corresponds to a value of phiB1, then you can look at the plot or use fsolve. Your intention for phi is still unclear.

@PatD 

I typically solve this problem by never assigning numerical values to variables, but using eval on a set of numerical parameters, as in the following:

Model 1

params:={a=1,b=2,c=1,d=3};
q:=a*b+c;
r:=b+d;
eval(q,params);
eval(r,params);

{a = 1, b = 2, c = 1, d = 3}

 

a*b+c

 

b+d

 

3

 

5

(1)

Model 2

params:={a=1,b=3,c=2,d=1};
q:=a*b^2+c;
r:=b+2*d;
eval(q,params);
eval(r,params);

{a = 1, b = 3, c = 2, d = 1}

 

a*b^2+c

 

b+2*d

 

11

 

5

(2)

I often put all the parameter sets at the top of the worksheet (but with different names: params1, params2 etc), so I can redo with different parameters by just changing the sets and then running the worksheet.

@Carl Love Possibly. I was going by his sketch.

@Carl Love The dynamic vector method of building lists is fastest,followed by the remember table method, but the other methods given do not give ordered lists. "entries" requires the 'indexorder' option to be ordered, but that slows it down, and there is a similar problem with the extracted remember table method.


restart:
#List building using regular table - result is not ordered
P:= proc(n)
local T,k;
for k to n do T[k]:= k end do;
[entries(T, 'nolist')]
end proc:
CodeTools:-Usage(P(2^22)):
P(5);


memory used=196.15MiB, alloc change=476.01MiB, cpu time=3.98s, real time=3.67s, gc time=624.00ms
[1, 2, 3, 5, 4]


restart:
#List building using regular table - use of indexoder option to order slows things down
P:= proc(n)
local T,k;
for k to n do T[k]:= k end do;
[entries(T, 'nolist','indexorder')]
end proc:
CodeTools:-Usage(P(2^22)):
P(5);


memory used=308.15MiB, alloc change=0.53GiB, cpu time=10.75s, real time=10.47s, gc time=670.80ms
[1, 2, 3, 4, 5]


restart:
#List building using regular table - convert to list slows things down more
P:= proc(n)
local T,k;
for k to n do T[k]:= k end do;
convert(T,list)
end proc:
CodeTools:-Usage(P(2^22)):
P(5);


memory used=388.16MiB, alloc change=0.67GiB, cpu time=17.46s, real time=12.08s, gc time=7.64s
[1, 2, 3, 4, 5]


restart:
#List building using remember table
P:= proc(n)
local R,k;
for k to n do R(k):= k end do;
[seq(R(k),k=1..n)];
end proc:
CodeTools:-Usage(P(2^22)):
P(5);


memory used=243.97MiB, alloc change=508.01MiB, cpu time=6.19s, real time=5.82s, gc time=826.81ms
[1, 2, 3, 4, 5]


restart:
#List building using extracted remember table - not ordered
P:= proc(n)
local R,k;
for k to n do R(k):= k end do;
[seq(k,k=op(4,eval(R)))];
end proc:
CodeTools:-Usage(P(2^22)):
P(5);


memory used=211.96MiB, alloc change=492.02MiB, cpu time=4.48s, real time=4.07s, gc time=873.61ms
[1, 2, 3, 5, 4]


restart:
#List building using dynamic vector
P:= proc(n)
local R:=Vector(),k;
for k to n do R(k):= k end do;
[seq(k, k= R)]
end proc:
CodeTools:-Usage(P(2^22)):
P(5);


memory used=174.03MiB, alloc change=82.03MiB, cpu time=3.34s, real time=3.21s, gc time=421.20ms
[1, 2, 3, 4, 5]

 Download List_Building.mw

First 26 27 28 29 30 31 32 Page 28 of 32