itsme

569 Reputation

13 Badges

12 years, 178 days

MaplePrimes Activity


These are replies submitted by itsme

@acer 

Hi Acer:

this bug aside, do you have any idea why redefining the "Explore" command by showing its code with "showstat" and then re-declaring with a different name is not working for me? it seems to have worked before with other simpler commands that I've tried this with (say Grid:-Map, or even the old Explore in maple 15 - using your suggestion in fact - see this post http://www.mapleprimes.com/questions/125305-Explore-Command  )

thanks

 

@acer 

I am using maple 2015.

Here is a trivial example that shows what I mean:

Explore(plots:-display(Matrix((i,j)->plot(sin(a*x), x=0..5),4,4), labels=["x", "this is y"]), parameters=[a=1..2], placement=left, size=[1200, 1000]);

Attaching two screenshots, the first shows what things look like by default, and the second, when I switch (via right hand menus) the alignment of the table column where the plots are to "Left"

thanks.

 

 

good find - please submit a bug report here:

http://www.mapleprimes.com/scr/new

i thought this post would be hitting mid 50s in responses by now, with everyone wanting to share their init.mpl equivalents... no?!  

where did i go wrong?!  ...  haha ;)

@Carl Love

My guess is that the method you describe is probably more flexible than what's provided in the Finance package, but for some problems the Finance package is really quite nice to use.

The documentation is also very good, so you should easily find many examples of how to use the stochastic solver there. A good start might be:

http://www.maplesoft.com/support/help/Maple/view.aspx?path=Finance/ItoProcess

I wanted to attach a simple worksheet that I compiled in the past and that contains some examples, but I am not able to upload it - on two different browsers I get "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable." message... I give up...

just a follow up to acer's suggestion.

for me, in some odd situations ctrl+del does not work then the cursor is on/in the iterm i want to delete. What helps usually is to create an execution grou before this item with ctrl+k, move the cursor there, and only then press ctrl+del (a few times).

@Kitonum

thanks for the post... i think acer' suggestions above will work better for me, as they get rid of the "unwanted" part of the axes automagically, but neat idea nevertheless!

@acer

thanks very much for the workarounds- i think some combination of these will work well for me. The above was just a dummy example, I have to prepare ~10 plots all with different ranges/datasets and slightly different options.

 

 

could maybe a maplesoft employee confirm that it's not possible then?

thanks!

@Kitonum 

i don't think a set guarantees order. You might be safer using a list like so:

Sys:=[x+y=1, x+z=2, y+z=3]:



Archimedes should have probably told the king to first at least attempt his own (aghem..  homework... aghem..) problems, and that he'll be happy to help once the king has made some effort and is simply stuck... wink, wink.

@acer

haha.. yes definitely fast enough now! In fact because I was using fsolve i needed to jump through some hoops/make-tradeoffs to make thins as fast/parallel as possible (Grid:-Map can't deal with compiled functions, Thread:-Map can't use fsolve, etc...). I now refactored my code a little and just rolled your iterative approach along with all the other stuff that I can compile... Running everything  with no parallelization is now substantially (1 to 2 orders of magnitude) faster than before, even when before I ran on 4-6 cores via Grid:-Map.

Using Thread:-Map does not seem to help right now with the latest compiled code interestingly enough.. but that's another problem for another day.

by the way, I was curious why in itsme1.mw, you used a Module rather than a regular function?

thanks again!

@Axel Vogt

Hi Axel:

yes, i agree, but even so I still would need to calculate results in a "standard way" for the first say ~1000 values of n to get the 1e-5 accuracy as you point out. Hence still need a fast way to do it.

 

 

 

@acer

aghh... yes! - missed that as well.

Your code seems to work very well for basically all parameters I throw at it (and roughly speaking is and order of magnitude faster than get_theta_n_array3, which is in turn 4 times faster than my original code)

 

thanks!

 

Hi @acer

First of all, thanks very much for taking the time to look into this... I always find your posts very interesting and useful.

Your code when works, seems to be as much as ~70 times faster (!!) on my machine and take as much as 1/50th of the memory of th than the version I posted.

A small problem is that for some n the code does not find the "right" number of solutions. I have ran into an identical issue when I was using fsolve with the same initial guess (as you're essentially doing) for all n. A solution was to either
1) not specify the initial guess and later sort for solutions in range
2) not specify the initial guess but specify an acceptable range of solutions (i.e. theta_n=-Pi/2..Pi/2)
3) use the last solution as the guess for the next one.

All three cases showed similar timing... and seemed to work.

So while this works:
param_n:=1000:param_omega_a:=100e9:param_v:=1e8:param_x_l:=0.3:param_C_a:=20e-14: param_Z0:=50.0:
ans_new:=CodeTools:-Usage(new_get_theta_n_array(param_n,param_omega_a,param_v,param_x_l,param_C_a,param_Z0) ):
ans:=CodeTools:-Usage( get_theta_n_array(param_n,param_omega_a,param_v,param_x_l,param_C_a,param_Z0) ):
plots:-display([plots:-listplot(ans), plots:-listplot(ans_new, color=red, linestyle=dash)], thickness=2);

Changing n to say 10 or 2000 does not:  
param_n:=2000:param_omega_a:=100e9:param_v:=1e8:param_x_l:=0.3:param_C_a:=20e-14: param_Z0:=50.0:
ans_new:=CodeTools:-Usage(new_get_theta_n_array(param_n,param_omega_a,param_v,param_x_l,param_C_a,param_Z0) ):
ans:=CodeTools:-Usage( get_theta_n_array(param_n,param_omega_a,param_v,param_x_l,param_C_a,param_Z0) ):
plots:-display([plots:-listplot(ans), plots:-listplot(ans_new, color=red, linestyle=dash)], thickness=2);

As far as parameters go, at least right now when I'm trying to optimize over what "works best" for the rest of the problem, I do have to be sure that whatever I'm using is robust for a huge range of paramters... Although the parameters I listed are "good candidates".
param_n:=1000: #can vary from 100 to thousands (in principle)
param_omega_a:=100e9: #can vary between 1e9 and 5000e9 (likely a few hundred 1e9)
param_v:=1e8:param_x_l:=0.3: #can vary between 0.05 and 1
param_C_a:=20e-14:  # can vary between 1e-14 1000e-14
param_Z0:=50.0:  #fixed

If you have any ideas to make your code robust against a wide range parameters (especially n), please let me know.
thanks again!

EDIT:

I should note that playing with the initial guess and the number of evalutations of F(n) does not seem to help. Also, I've been playing more with Mac Dude's idea above (see get_theta_n_array3) and that does seem to be a factor of a "few" faster than my original code.

 

4 5 6 7 8 9 10 Last Page 6 of 15