## 110 Reputation

6 years, 210 days

## How to fix for-loop slowdown...

Maple 2018

Hello,

I have a very large expression I'm tring to average (by doing limit(1/L*int(<expr>,t=-L..L),L=infinty) ). However, given that this expression is so large (sum of 11k terms), I'm was looking for ways to speed up the calculation and use less RAM.

I found that applying the lim@int seperately to each term of the sum helps. Also, since my integrand has various functions of other variables (eg. f(x), g(y), etc), Maple seems to go faster if I freeze those functions using frontend.

However, the problem I'm running into is that, as I'm running through my for-loop to apply lim@int to each term, Maple starts running slower and slower, as well as taking more and more RAM. Additionally, it doesn't go to completion because it runs out of stack space.

Is there an optimization trick to avoid this problem? I've tried garbage collecting after each iteration; that helps the RAM problem (at a cost of speed), but it still slows down over time.

I've attached my code: MWE.maple. Fair warning: on a non-server computer, it is liable to run very slow.

## Possible bug with pdsolve and assuming?...

Maple 2018

Hello,

I was trying to apply some assumptions to a pdsolve command and noticed a strange error. Here's a minimal working example.

```restart():

pdsolve(diff(f(t,x),t) = 0, {f(t,x)}, ivars = {x, t}) assuming x::real:```

returns

`Error, (in simpl/relopsum) invalid terms in sum: diff(f(t,x),t) = 0`

Is this indeed a bug, or is it expected behavior?

## How to expand a sqrt...

Maple 2018

Hello,

I'm having trouble simplifying this square root:

```assume(p::positive):
sqrt(sqrt(p^2+1)-1)*sqrt(sqrt(p^2+1)+1):
expand(%);```

I expect it to give just p but instead it returns the full, unsimplifed expression.

This appears as part of a larger expression, and if it fails to simplify, terms won't cancel and the expression is much longer than it needs to be.

Thanks!

## pdsolve erratically returns null result...

Maple

Hello,

I've run into a strange problem with pdsolve. I'm attempting to solve a small PDE system. It seems pdsolve is quite capable of handling it, as it will occasionally return a valid answer. However, equally often, it returns a NULL result. And this is without changing anything else in the code: consecutive runs randomly produce a valid or NULL result.

The only possible explanation I have is that, since this is a part of a larger code (~2k lines), perhaps something is going on with memory management? This is being run on a server (24 cores, 50GB RAM), so the total memory usage never rises above 0.5%. The cpu usage does hover around 100%-105% of a single core, but I doubt that's a problem. I've tried increasing stacklimit, processlimit, and cacheclearlimit, but it didn't seem to help.

So, my question is, what sort of debugging or testing can I try? Are there any standard "tricks" to use here?

Thanks!

## PDEtools:-Solve causes name collison...

Maple

Hello all,

When using maple's differential equation solvers (dsolve or pdsolve), solutions will often have undetermined constants (or functions) _C1, _F2(x), _F5(t,x), etc. These are automatically generated and could potentially cause name collisions. I've found that passing names as part of the solver's ranking prevents this. For instance

```D[1,1](y)(t,x) + y(t,x) = 0:
pdsolve(%);```

would return y(t,x) = _F1(x)*cos(t) + _F2(x)*sin(t). However, if _F1(x,z) is defined elsewhere, then passing

```D[1,1](y)(t,x) + y(t,x) = 0:
pdsolve(%, {y(t,x), _F1(x,z), _F2(x,z)});```

instead returns y(t,x) = _F3(x)*cos(t) + _F4(x)*sin(t), preventing a collision.

However, it seems that PDEtools:-Solve doesn't follow this same convention. Indeed, calling PDEtools:-Solve(%, {y(t,x), _F1(x,z), _F2(x,z)}) on the above system returns y(t,x) = _F1(x)*cos(t) + _F2(x)*sin(t).

In all fairness, this is only a problem since my "colliding" functions are actually different functions: they differ in their arguments. When the arguments are the same (for instance, passing {y(t,x), _F1(x), _F2(x)} to Solve) then no collision occurs.

Nevertheless, having two different functions with the same name is causing problems for my code (later invocations of Solve with both _F1(x) and _F1(x,z) causes an "found functions with same name" error).

Is there any trick to avoid this behavior?

Thanks!

 1 2 3 4 5 Page 2 of 5
﻿