1

(MMA v. 14.0, and 13.0)

This is a strange behaviour I encountered when trying to determine Fourier coefficients in the most naive way:

n = 17;
eqv = Table[c[0] + Sum[ccos[k] Cos[Pi  t  k] + csin[k] Sin[Pi  t  k], {k, 1, n}] + 
       E^t == 0, {t, Range[0, 1, 1/(2 n)]}];

coeffv = NSolve[eqv, Join[Flatten@Table[{ccos[k], csin[k]}, {k, 1, n}], {c[0]}]][[1]]
Length@coeffv
Length@Join[Flatten@Table[{ccos[k], csin[k]}, {k, 1, n}], {c[0]}]
Length@eqv


(* Output: 
   {ccos[1] -> 1.07451 + 0.00353982 c[0], ...}
   34
   35
   35
*)

Every solution in coeffv has a linear dependence on c[0], and no solution is given for c[0]. Clearly, this can't be right... somehow it doesn't solve the linear system of equations, even though there are as many variables as equations.

However, for $n=16$

(* Output:
   {ccos[1] -> 1.0643, csin[1] -> 0.331322, ...}
   33
   33
   33
*)

everything is ok. This holds for any number smaller than 16, and any number larger than 17 doesn't work either.

Solve alone does not give a result for $n\geq 4$ in reasonable time. (Because it refuses to make the coefficients numerical, which is fine by me. Doing a N around everything invalidates my variable names, but I can fix that...)

Domen
  • 23,608
  • 1
  • 27
  • 45
Confuse-ray30
  • 347
  • 9
  • better not to use l for variable name, it looks like 1 on the screen and hard to read your code. you can choose any other letter. L is not used by Mathematica so you can use that. Or use n – Nasser Mar 25 '24 at 11:47
  • @Nasser Sure, now it's called $n$ in the code. Can you reproduce this behaviour? – Confuse-ray30 Mar 25 '24 at 11:55
  • I cannot reproduce the issue on v14.0.0. (Windows). – Domen Mar 25 '24 at 11:56
  • @Domen But that's precisely the issue! You used 35 equations and 35 variables. You should get 35 numbers as a result, not 34 with dependence on one of them! – Confuse-ray30 Mar 25 '24 at 11:56
  • Ah, I was only referring to the warning message (which I don't get). Please check #102724. Namely, increasing WorkingPrecision (for example NSolve[..., WorkingPrecision -> 30]) seems to solve the issue :) – Domen Mar 25 '24 at 12:27
  • @Domen Hm, yes, you are correct. Strange as it is, this fixes the issue, but raises another one: The Speed is atrocious. I don't understand whether this system in particular is just difficult to solve or something, but I don't expect 35 variable systems to take 10 seconds (I will have similar things with like... 500 variables, which shouldn't be a problem at all either, sub 1 second at most.). In fact, MMA seems to have speed problems a lot when solving equations. – Confuse-ray30 Mar 25 '24 at 12:59
  • @Domen The Output is not the actual output of MMA, just text I wrote to describe the output, since it would otherwise clutter. Those aren't error messages. – Confuse-ray30 Mar 25 '24 at 13:14
  • If you have a linear system of equations, then just use LinearSolve, for example: LinearSolve[ Table[{1}~Join~Flatten@Table[{Cos[Pi t k], Sin[Pi t k]}, {k, 1, n}], {t, Range[0, 1, 1/(2 n)]}], Table[-E^t, {t, Range[0, 1, 1/(2 n)]}]] (wrap with N for higher $n$ when badly conditioned matrices start to appear). If you don't have a linear system, then it will be best to ask a question with your actual problem, not some other, made up one :) – Domen Mar 25 '24 at 14:17
  • @Domen Afaik, Solve can recognize it is linear and thus employs linearsolve without you having to extract the matrices etc. (I tested that with large systems anf see which one is faster, random entries.) But those examples were quick. Just in "real life" it seems more difficult. (Note: My systems are linear.) Try doing the modification you suggested and see how long it takes. It is surprisingly long. – Confuse-ray30 Mar 25 '24 at 15:02
  • @Confuse-ray30, I wouldn't be so sure of your first statement. As for LinearSolve: Don't use exact numbers. It takes only 0,3 s (or 1,4 s with higher precision) for $n=100$. – Domen Mar 25 '24 at 15:12
  • @Domen thanks for the tips! If thats the case, I guess it must have been because my tests only ran with randomnumbers of machine precision – Confuse-ray30 Mar 25 '24 at 15:40
  • 2
    I'm also seeing some unexpected behavior which I will report if I don't figure it out first. I will speculate that n=17 is the start of trouble due to matrix conditioning and machine arithmetic. At that value the smallest singular value in the coefficient matrix is around 10^(-15) (so within an order of magnitude of the machine precision epsilon), whereas at n=16 it is around another order of magnitude larger (near 10^(-14)). – Daniel Lichtblau Mar 25 '24 at 16:59
  • I reported this speed issue. As for workaround, could do `Timing[ {rhs, mat} = CoefficientArrays[eqv, vars]; solls = LinearSolve[N[mat, 100], rhs];]

    Out[200]= {0.012747, Null}`

     – Daniel Lichtblau Mar 25 '24 at 17:35
  • Interesting. Well for all intents and purposes, I will just do FourierSeries, but it is good to know that I'm not the only one weirded out. – Confuse-ray30 Mar 25 '24 at 18:01

0 Answers0