Here's an assume vs assuming difference worth keeping in mind

> restart:
> is(x^2>=0) assuming x::real;
                                     true
 
> restart:
> f := proc() is(x^2>=0); end proc:
> assume(x::real):
> f();
                                     true
 
> restart:
> f := proc() is(x^2>=0); end proc:
> f() assuming x::real;
                                     false

I am using Maple 14 in Windows xp.

If you enter an equation, or expression into a table the screen display shows more than adequate amount of blank space remaining in that particular table row.  However, when you look at the document in print preview or after printing it out you find that the free space in the row is not correctly displayed.  This is by no means subtle.  For example, I enter an equation into a table and it looks like at...

A long while ago, I wrote a couple posts (part1 and part2) about mining data from the US SSA website.  I subsequently adapted the code from those blog posts into a visual application with sliders and interactive plots.  If you have played with the new ?MapleCloud functionality in Maple 14, you may have seen it posted already.

Amdahl's Law is a formula for determining the theoretical speed up when parallelizing a function. For example, imagine we wanted to parallelize a function that spends 90% of its time in one algorithm. If there is a parallel version of that algorithm, how much faster would the entire function run with 2, 4 or more cores?

In the book Introduction to Maple by Andre Heck books.google.co.uk/books  the author manage to plot the canadian flag
in maple by using the following code:
 

restart:
with(plots):
with(plottools):

X := proc (cc) local S, R, mapleleaf, rectangles, border:

S := proc (t) options operator, arrow; 100/(100+(t-(1/2)*Pi)^8) end proc:
R := proc (t) options operator, arrow; S(t)*(2-sin(7*t)-(1/2)*cos(30*t)) end proc:
mapleleaf := plot([R, proc (t) options operator, arrow; t end proc, -(1/2)*Pi .. (3/2)*Pi], coords = polar, axes = none, color = cc, numpoints = 1000):
mapleleaf := subs(CURVES = POLYGONS, mapleleaf):
rectangles := rectangle([-5, -1], [-3, 4], color = cc), rectangle([3, -1], [5, 4], color = cc); border := plot({-1, 4}, -3 .. 3, color = black):

display([mapleleaf, rectangles, border], view = [-5 .. 5, -1 .. 4]) ;

end proc:

Ap := Array(1 .. 2, 1 .. 2):   

Ap[1, 1] := X(red):         Ap[1, 2] := X(blue):    
Ap[2, 1] := X("green"):    Ap[2, 2] := X("Orchid"):

display(Ap);

 

Consider the following situation.  A thread acquires a mutex, then enters a critical section.  However when executing in the critical section, the thread access a memory location.  If that memory location is not in cache, the thread will wait for a few hundred cycles.  If accessing the memory location causes a page fault (the memory was swapped out to disk), the thread may need to wait a few million cycles.  However while this thread is waiting, it is still holding the mutex.  This means that other threads will not be able to enter the critical section, and may

A MaplePrimes member recently asked me how to sort two sets, using the permutation of one to sort the other.  For example, given the list

L1 := [3+I, I, 2, -1, 5, 4]:

sort it according to its magnitude and then permute the second list

L2 := [a, b, c, d, e, f]:

in the same manner.

The following interaction with Maple's Excel link came to my attention today.  I thought it had many interesting points that lead to insights about Excel and Maple that are worth sharing.

So it appears that using subscripts in Maple is not a good idea. I ran into this problem for the first time yesterday, and is documented here: http://www.mapleprimes.com/forum/drivenharmonicoscillatoramplitudephaseangle#comment-32780 And now it seems I've run into it again. Or possibly I have made a mistake ;) This is part of an implementation of Newton-Cotes method of numerical integration: restart: NCcoef := proc(N::integer) # procedure returns the Newton-Cotes coefficients for an # appoximation with N+1 points local a,c,p,h,B,LH,RH,eq,seqeq,seqco: h := B/N:

It has been a while since my last post.  I'm sorry about that, but I have been busy trying to the fix bugs reported as part of the Maple Beta program.  I'm also running low of good parallel programming topics.  So, as always, if you have topics you'd like to hear about (or hear more about) feel free to ask.

Today I am going to post a brief note about a blog that I find quite interesting.

Cliff Click Jr's Blog: http://blogs.azulsystems.com/cliff/

I came across this issue on my course today, and found it somewhat surprising: restart:Digits:=7: foo:=1/2*sqrt(3): evalf(foo); 0.8660255 evalf[5](%); 0.86603 evalf[5](foo); 0.86605 I suppose this means that whatever algorithm Maple uses to compute the square root also works to the specified level of accuracy and the above is a result of accumulated rounding errors.

I came across the tutorial/manual here, which I found to be most excellent for a beginner in Maple, such as myself:

http://www.maths.ox.ac.uk/courses/2009/moderations/mathematics-maple/exploring-mathematics-maple/material

The page will also be updated with lecture notes and sample code

To judge results of functions coded in double precision against precise results (as they may be given by Maple) one has to respect decimal presentations on one side and IEEE on the other side.

For that one can use routines developed by Florent de Dinechin, which are worth to be better known.

Here is a Maple sheet showing how one can do it (looking at the complex valued power function using evalhf versus using MS VC2005 as an example).

There was some recent discussion about Maple's Standard GUI having two parsers. (See here, and its parent.)

I've been accumulating a list of some differences between the parsers of 2D Math and 1D Maple notation, for the same given pasted input.

In particular, I'm interested here in differences...

This blog will contain postings documenting some of my mathematical travels. In particular it will chronicle my experiences and problems in learning maple and the mathematics I am studying along the way.