As some expressions involving 'floor' and 'ceil' did not simplify as I have expected, I have gone to basics. In ?trunc > Description it is stated:

ceil(x) = -floor(-x)

But 'simplify' does not seem to know about this equation as this expression should simplify to 0:

simplify(ceil(x)+floor(-x));

                         floor(-x) + ceil(x)

In principle, this seems to be a weakness in 'simplify'. For comparison, in Mathematica 5:

Hey,

I've a problem with my maple version right since some time.

Every time I want to print the printing dialog states in the status line of the printer: "No jobs will be accepted" (this is freely translated from german).

also piping the output into a file doesn't work, it simple doesn't create that file.

If I start xmaple in a shell I got this:

Has anyone tried the technique used here, to run Maple 12's 32bit Classic GUI with the 64bit Maple 12 kernel binaries, on Linux?

Should I try and update it to work with Maple 11 or 12?

It looks like some symlinks would have to change or be added, relative to the way that I did it for Maple 10.

Has anyone ever tried to do a similar thing on 64bit Windows?

Dave L

Yesterday  the Maple 12.01 update installed on my computer.

Today, Maple 12.01 Standard does not start. Nothing happens, And after many minutes, nothing continues to happen (Douglas Hofstadter).

Maple 12.01 Classic starts--really fast.

Maybe it's the update. The other intervening factor was the very recent critical Windows secruity update.

Does anybody have a similar experience?

  Int(phi(u-a*I)*exp(k*u*I),u = -infinity .. infinity);
  Change(%, u-a*I = s, s); subs(s=u,%): expand(%): combine(%,exp);

                   infinity
                  /
                 |
   ...

The following would appear to be a pretty straightforward improper integral for Maple to handle:

q := Int( 1/x^p, x=1..infinity );
                                /infinity      
                               |          1    
                               |          -- dx
                               |           p   
                              /1          x    

Things start of well, with Maple recognizing that the answer depends on the value of p:

value( q );               # fine
                         /   (-p + 1)                  \
                         |  x         - 1              |
                    limit|- -------------, x = infinity|
                         \      p - 1                  /

The first case is when p>1:

value( q ) assuming p>1;  # good
                                      1  
                                    -----
                                    p - 1

The other case should be for p<1:

value( q ) assuming p<1;  # say what?
                            infinity p - infinity
                            ---------------------
                                    p - 1        

  restart; interface(version);

    Classic Worksheet Interface, Maple 12.00, Windows, Apr 10 2008 Build ID 347164

  Int(1/(u^2+1/4)*exp(I*u*k),u=-infinity...infinity); value(%);

                                  0

but

  Int(1/(u^2+1/4)*exp(I*u*k),u=-infinity...infinity...

[I am using Maple 12.01 with Windows XP].

I tried to use gfun[listtorec] to find a recurrence for a particular sequence (given below), but the recurrence found is not correct.
Yet,  guessgf apparently gives the correct generating function.

>with(gfun):
>L:=[5, 8, 14, 24, 42, 72, 126, 216, 378, 648, 1134, 1944, 3402, 5832, 10206, 17496, 30618, 52488, 91854]:
>rec:=listtorec(L,u(t));
               [{-u(t + 2) + 3 u(t), u(0) = 5, u(1) = 8}, ogf]
 

It looks like `forget` works on procedures with option 'cache'.

I realize that there is a routine Cache:-RemovePermanent. But should `forget` be clearing the permanent Cache entries for a procedure?

> cacheFunc := proc() option cache; print(args); args; end proc:
> Cache:-AddPermanent( cacheFunc, [5], 10 );
> op( 4, eval(cacheFunc) );
                      Cache(512, 'permanent' = [5 = 10])
 
> forget(cacheFunc);
> op( 4, eval(cacheFunc) ); # NULL return, it's empty

One of our TAs reported this to me earlier today. (A student reported it to him.)

Sum(sin(1/10000.0*i^2), i = 0 .. 199):
%, value( % ), evalf( % );
            199                                                   
           -----                                                  
            \                                                     
             )      /                 2\                          
            /    sin\0.0001000000000 i /, 80.85387129, 127.2891137
           -----                                                  
           i = 0     

The student used evalf. I suggested that value was a better first option in this case. Since this is just the sum of a fixed set of numbers, an even better alternative is to use add:

add(sin(1/10000.0*i^2), i = 0 .. 199);

                                 80.85387132

The problem disappears when Digits increases to (at least) 15.

The following example was shown to me by Matthias Kawski.

He noticed a difference in the way Maple 12 handles some definite integrals from the way they were done in Maple 8. Both cases point out some problems. I'll offer my explanation of the problem after I show what Matthias observed: First, the results from Maple 8. Each of these 4 examples evaluates a definite integral in two different ways, the first using a function and the second using an expression. All looks fine until the last example.

I find that for some plots the choice of location for tickmarks and axes labels in the Classic version is better than the Standard one. Eg. here:

with(plots):
complexplot3d(sin(z), z=-Pi-1.5*I..Pi+1.5*I,axes=boxed,
style=surfacecontour,tickmarks=[[-Pi=-Pi,0=0,Pi=Pi], 
default,default],orientation=[72,49]); 

Classic:

Which is the difference between them? (besides being builtin or not). For the simple examples that I have tested, their output seems the same, eg:

`convert/function`(f,[1]);
                                 f(1)

`?()`(f,[1]);
                                 f(1)

To be "updated" I have defined in Maple 12 an "identity function" using '_passed', but the output shows 'args':

id:=()->_passed; 
                           id := () -> args

Based on the paragraph:

Prior to Maple 10, _passed and _npassed were called args and nargs. For backward compatibility, these names will continue to work as synonyms for the new names.

from ?using_parameters, I find this result unexpected. In fact, I would have expected the other way round, ie that here:

Hi,

at the moment I am writing my bachelor thesis. I use maple to compute

the smith normal form of a matrix.

I would like to know whether there is some information about the complexity of maple's

implementation of the smithForm algorithm (package linearAlgebra).

Thanks,

rauraz