## 11716 Reputation

7 years, 136 days

## point=infinity...

Your odetest examples are not correctly treated. You cannot use asympt when the series solution is around a finite point (e.g. 'point'=0). asympt does a series expansion around infinity!
Note also that not all ode solutions have series expansions; e.g. for Ex 6, the series can be obtained only with MultiSeries:-series,
so, for x>0 (series and dsolve cannot do it).

## Of course...

@acer  Of course, but that is what the user has asked.

## asympt...

@Axel Vogt Your last command should be:
MultiSeries:-asympt(%, x, 6);
or simply,
asympt(%, x, 6);

Actualy, odetest(sol, ode)  does essentially the same thing.

## Puiseux series...

@nm All your "positive" examples are regular series or Puiseux series.
The solution of the ode in the question is not of these types, and I suspect that odetest rejects it.
But the asympt approach is acceptable in my opinion and works.

## ?...

@smithss  This one cannot have a solution: there are more columns than colors!

## < 10^5...

@Carl Love Actually the max number of permutations used is small:

(9!/(3!*2!*2!)) * 6 = 90720

because once a permution if found for a column, it is kept.
The puzzle can be easily solved by hand.

It would be interesting to find a puzzle which cannot be solved this way!

## infinity...

@C_R It would not be a good idea to simply return infinity, because the arithmetic with oo is complicated.
This is why there is try ... end try.  See also ?events
Example

```try
EllipticK(1)
catch "numeric exception: div":
infinity;
end try;
```

infinity

## @jud What I get is: ...

@jud What I get is:

## 1,2,3...

@jud  Yes, it seems that in newer versions, DrawSubgroupLattice outputs numbers (1,2,...) instead of symbols (`1`,`2`,...); unfortunately I have not tested Carl's code before posting.
You will have to try my approach which works.

## document mode...

@jud Because you are using the document mode, create a prompt and paste the code there.

## sum, pochhammer...

@ecterrab Very nice, congratulations!

I was curious to see why Sum=add is needed (instead of value).
It seems that sum has problems with pochhammer. If we replace pochhammer with P,  (and then back), value works.
Here is an example:

```S:=Sum(pochhammer(2*k - n + 1, 2*n - 2*k)*pochhammer(3 - k, k)/((n - k)!), k = 0 .. n):
value(%); # ?
#                               0
seq( value(eval(S,n=N)), N=1..6 );
#                       2, 6, 12, 24, 0, 0

```

The result of value(S) should be  2*n*(n - 1)/GAMMA(-n + 5)  (instead of 0)
which is actually obtained using  assuming n::posint

In this case, the correct values can be obtained with limit insted of eval.

(The situation is similar to sum(k, k=1..n) where n is also "assumed" integer).

## @ecterrab In order to use this work...

@ecterrab In order to use this workaround I had to replace ex1 with allvalues(ex1) in ex2 due to the Sum(..., alpha=RootOf(...)).
BTW, in an older Maple version I have on a small laptop, your first workaround worked for the "assuming" example (applied blindly!); here ex1 contains a hypergeom function, and diff(...) is absent in ex1. It seems to be a better answer (at least in this case). Maple is interesting!

Best regards,
vv

Edit.

The answer of ex1 contains an inert sum and diff(u, y\$p), for p in 0..k.
But in this case (when diff is accepted) a much simpler symbolic answer is

ans := pochhammer(-j,j)*Diff((y^2)^j*(x*y^2+2)^(-1-j),y \$ k);
value(eval(ans,[j=2,k=4,x=0,y=0]));
6

This one is not fragile :-)

## CayleyTable...

```elem:=[Elements(g2)[]]:
c1:=CayleyTable(g1,elements=elem):
c2:=CayleyTable(g2,elements=elem):
```

## @jud It is possible, but is has not...

@jud It is possible, but is has not much sense. You may compare the Cayley tables. But you must be sure that the elements and their orders are the same, so, to be safe, the tables should be constracted by you.
C6, as a PermutationGroup, is generated by a 6-cycle in Symm(6). How could it be exactly equal to a subgroup in Symm(5)?

## fragile?, workaround?...

@ecterrab Thank you. However I consider the expression generated by D as very fragile and it needed your workaround.
The symbolic diff is mainly used for nonnegative integers j, k, so, why use GAMMA(-2*j) inside it?
Actually, the workaround does not work (division by 0) when j,k are assumed nonnegint.

```restart
f := (x, y) -> 1/(2 + x*y^2);
ex1 := D[1 \$ j, 2 \$ k](f)(x, y)  assuming j::nonnegint, k::nonnegint;
ex2:=simplify(eval(ex1, [k = 4, Sum = add]), GAMMA);
eval(ex2, [j=2,x=0]);
```

 2 3 4 5 6 7 8 Last Page 4 of 161
﻿