The previous post (More torture tests) makes the page on which it is displayed go quite wonky. I have no idea where the bug lies, but it definitely highlights a problem.
(a>b) + 3*(a<b) + 4
Moderator edit - I changed <maple> to <pre> I believe the bug comes from the use of the less than and greater than signs. I will look into it.
I really doubt that backquotes are used, as it would results in things like `1+2`, which is clearly not what happens. You probably meant to say that forward quotes are used, which would be consistent with the behaviour I have seen.
Similarly, I doubt the typesetter cannot be the same as in the Standard Worksheet - that would produce such a huge load on the web server that the site would be unusable; using Classic would make no appreciable difference. And anyways, the typesetter in the Standard Worksheet produces different results on the previous example! What I am sure you meant to say is that the TTY version of Maple is used with the GIF driver for pretty-printing. Which just goes to show how useful that TTY version really is, no? Plus I recognize the GIF drivers' hideous choice of fonts. I could be wrong, but I rather suspect not.
Trivia question: how many typesetters are there in Maple? I mean, when you install Maple 10 on Windows, how many typesetters are there in that product? As far as I know, there are 6, with each one have slightly different layout rules.
Without cheating, can someone tell me the Maple input string I had to type to get
abs(Eval(abs(``[iota]),``^iota=``[1][1]))
as output? It also highlights some bugs in the typesetter used on this web site - the same input in Classic looks ``better''.
That was so much fun, that I decided to keep going. Let's see what various things do:
CFRAC([3, 7, 15, 1, 292, 1, 1, `...`])
numtheory[cfrac](Pi,6)
PLOT(CURVES([[0,0],[1,1]]))
<<1>>
Matrix(1,1,{(1, 1) = 1},datatype = anything,storage = rectangular,order = Fortran_order,shape = [])
and I get nothing particularly bizarre. That's almost too bad! (The reason I chose the above is that all of those objects in either Maple GUIs, from Maple 6 to Maple 10 are good sources of cut&paste bugs).
Trying to be sneaky:
x -> (1+1) x -> (1+1)
proc(x) (1+1) end proc(x) (1+1) end
and we see two interesting things: automatic simplifications inside a procedure, and elision of a procedure body (even without option copyright). I wonder why the last is so? OK, so can we get around that?
proc(x) options operator, arrow; (1+1) end proc(x) options operator, arrow; (1+1) end
Well, sort-of. Let's test it for real:
proc(x) options operator, arrow; if type(x,'real') then sin(x) else procname(args) end if end proc
proc(beta) options operator, arrow; if beta::real then sin(beta) else procname(args) end if end proc
which certainly is an interesting result.
> dsolve({diff(s(t),t) = A - A * rho^((1 - r^(theta * t)) * x) - v, diff(f(t),t)=((c - s(t)) / l) * m + x, diff(h(t),t) = x, f(0) = 0, s(0) = 0, h(0) = 0});
x (theta t)
A rho Ei(1, x r ln(rho))
{s(t) = A t + ---------------------------------- - v t
theta ln(r)
t
x /
A rho Ei(1, x ln(rho)) | m c
- -----------------------, h(t) = x t, f(t) = | ---
ln(r) theta | l
/
0
x (theta _z1)
m A _z1 m A rho Ei(1, x r ln(rho)) m v _z1
- ------- - -------------------------------------- + -------
l theta ln(r) l l
x
m A rho Ei(1, x ln(rho))
+ ------------------------- + x d_z1}
theta ln(r) l
A definite integral is considered ``simpler'' than a differential equation, so the above is solved. Most of the integrand is constant (with respect to _z1), so the part that needs to be integrated is quite compact.
Solving Sudoku puzzles via backtracking (ie brute-force) is really too easy, and takes a lot of the fun out of solving these puzzles! A much more human-like way of solving these is by forcing a recursion-depth of say 5 (which corresponds to how many things are easy to keep track of in ones' mind). Then one needs much more elaborate strategies to successfully solving Sudoko puzzles.
There are many different sites that offer a lot of suggestions about such strategies. I like this
Japanese puzzle site, as well as
Paul's Pages (and some of the links therein).
The
Sudoku Solver in Javascript over at Scanraid is fun to play with, as it offers a nice GUI. Making a Maplet that does the same would be fun!
Apparently, this puzzle:
1 - - - - - - - -
- - 2 7 4 - - - -
- - - 5 - - - - 4
- 3 - - - - - - -
7 5 - - - - - - -
- - - - - 9 6 - -
- 4 - - - 6 - - -
- - - - - - - 7 1
- - - - - 1 - 3 -
is the smallest known Sudoku puzzle which still has a unique solution. I found it over on
Lambda the Ultimate (a programming languages blog), in a
discussion on Sudoku.
One question: how did you generate that PDF? That is a very interesting way to view Maple code!
Using Firefox on a Windows XP machine, I clicked on 84_sudoku.pdf file above. I was then asked what I wanted to do with this compressed folder. If I try to view it using the compressed folder viewer, that fails. If instead I save the file to disk, it saves as a pdf file which Acrobat views just fine.
I am not sure I understand what is going on here. An incorrect MIME type somewhere?
The current evolution that I see in this site is very promising for its growth. The rapid reaction of the site implementors to the good suggestions is refreshing. More community moderators (and fewer current Maple employees), at least in the medium term, would be a good direction to move in.
A Wiki portion to this site is a tremendous idea. Other Wikis have worked really well; outside the obvious examples, the
Haskell Wiki has been a very successfull ``niche'' Wiki that has really helped that community come together.
I am particularly happy to see various Maplesoft employees, in particular some that are responsible for actually
doing stuff in many parts of Maplesoft's product lines, providing responses now and then. I particularly like it when they clearly label themselves as such. I certainly hope that the MaplePrimes community will not abuse this gesture of goodwill on Maplesoft's part.
To have a much better chance of getting help, your parameters (A, rho, theta, x, v, c, m) all need to be known numerically.
And, in any case, your problem can be solved symbolically! Even in Maple 9.5.
The suggestion of using partial evaluation to faithfully mirror Maple's behaviour is quite interesting (although it would require the ability to link against some of Maple's run-time, NAG libraries included). In fact, Stephen, my student Mike Kucera is working on a partial evaluator for Maple -- your desk will be right next this his! So this would be an interesting test for his work, though perhaps a mite too challenging for a Master's Thesis project.
It might also be interesting to see how far one can go via pure code generation, but with a bit of Maple help. This could be done if the complete interval over which the integration might be performed was known ahead of time. You could still integrate Int(f(x),x=a..b), but a..b would have to be contained in a fixed c..d. Then using a Chebyshev-Pade approximation to f over a..b, one could integrate this (exactly!) to give a fast numerical ``integrator''. To get fancier, one could probably to a finer singularity analysis of f(x) and interval sub-division, then Chebyshev-Pade approximation (rather like what evalf/Int itself does when straightforward numerical methods fail, in fact).
The suggestion of using partial evaluation to faithfully mirror Maple's behaviour is quite interesting (although it would require the ability to link against some of Maple's run-time, NAG libraries included). In fact, Stephen, my student Mike Kucera is working on a partial evaluator for Maple -- your desk will be right next this his! So this would be an interesting test for his work, though perhaps a mite too challenging for a Master's Thesis project.
It might also be interesting to see how far one can go via pure code generation, but with a bit of Maple help. This could be done if the complete interval over which the integration might be performed was known ahead of time. You could still integrate Int(f(x),x=a..b), but a..b would have to be contained in a fixed c..d. Then using a Chebyshev-Pade approximation to f over a..b, one could integrate this (exactly!) to give a fast numerical ``integrator''. To get fancier, one could probably to a finer singularity analysis of f(x) and interval sub-division, then Chebyshev-Pade approximation (rather like what evalf/Int itself does when straightforward numerical methods fail, in fact).
The <code> tag should not strip spaces - that is a definite bug. See how my favourite public blog
Lambda the Ultimate cleanly handles that tag for posting code.
Additionally, that blog also allows other tags, like <b> and <i> in posts, which make for more expressivity as well, I don't know why these are not allow in
Filtered HTML.
Last I had access to Maple's memory management (3 years ago, but it has been like that since about 1984...), the kernel did not explicitly track root nodes and block sizes, so that it has no way to know that a malloc'ed block is entirely free and thus can be given back to the OS. This would not necessarily be difficult to add though, especially for large memory blocks. Let's hope your suggestion gets heard, as it is relatively easy to show that Maple's gc is O(allocated_memory).
