MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: a LOT of Mathematica bugs (some very old)

  • To: mathgroup at smc.vnet.net
  • Subject: [mg95088] Re: a LOT of Mathematica bugs (some very old)
  • From: Daniel Lichtblau <danl at wolfram.com>
  • Date: Tue, 6 Jan 2009 04:10:24 -0500 (EST)
  • References: <d8f9dc63-f100-423e-a982-a2176f0ff4f8@r10g2000prf.googlegroups.com>

On Jan 4, 6:32 am, "Marcelo Surnamed" <contat... at gmail.com> wrote:

I can respond to a few of these.

> [...]
> Terrible Performance
>
> x = IE;
> Timing[Do[x = x /. IE -> E^(IE/E), {12}]; x]
>
> {4.687, E^E^(-1 +
>   E^(-1 + E^(-1 +
>     E^(-1 + E^(-1 +
>       E^(-1 + E^(-1 + E^(-1 + E^(-1 + E^(-1 + E^(-1 + IE/E)))))))))=
))}
>
>  mathematica 2.2 do it in a flash :
> [...]

Here is a more direct example:

Timing[Im[-1 - E^
  (-1 - E^(-1 - E^(-1 - E^(-1 - E^(-1 - E^(-1 - E^(-1 - E^(-1 - e^
(-1)))))))))]]

This slowdown is currently under investigation. My hope is to restore
something closer to the old behavior. Though the code is sufficiently
complex that I make no guarantees in this regard.

I should mention that there are similar examples where the speed
improves significantly between versions 2.2 and later. Here is one
such.
Timing[(-1/5 + (47*I)/20) ^ (1/10000)]


> SparseArray
> [...]
> *******
> Mathematica  eats a lot  system memory when this sparseArray
> is  (eg 300 x 300 x300) - Is it needed/by design ?
>
> gg = SparseArray[{i_, j_, 1} -> 1, {300, 300, 300}];

Using rules with patterns causes level recursion and substantial index
iteration in the process of constructing the sparse array. This in
turn seems to require considerable memory. One can generally improve
on this situation by giving explicit pattern-free rules.

dim1 = 200;
dim2 = 200;
dim3 = 100;

In[28]:= Timing[gg1 = SparseArray[{i_, j_, 1} -> 1,
  {dim1, dim2, dim3}];]

Out[28]= {2.12668, Null}

In[29]:= Timing[gg2 = SparseArray[Flatten[Table[{i, j, 1} -> 1,
  {i,dim1}, {j,dim2}]], {dim1, dim2, dim3}];]

Out[29]= {0.140978, Null}

On smaller examples you could check that Normal[gg1]===Normal[gg2]. I=
f
you set all dimensions to 300, gg2 will build without fuss in around
0.27 seconds on my machine.On a machine with substantial memory and
good speed, I can get gg1 in around 14 seconds (I really did not want
to risk hanging my own desktop).


> *********
> generated output does not mach the display
>
> ReplaceAll[
>  Plus[Times[-1, Power[E, Times[1, Power[x, -1]]]],
>   Power[E, Plus[Times[1, Power[x, -1]], Power[x, Times[-1, x]]]]],
>  Rule[x, DirectedInfinity[-1]]]\

I see a result of Indeterminate. I believe that to be a viable outcome
for this input.


> *******************
> Sum[(-x k)^k, {k, 0, Infinity}]
> *******************
> Function tends to Log[2]
> f[k2_] = N[-1 Sum[(1/k) (-1)^k, {k, 1, k2}]] // FullSimplify
>
> But this series diverges
> NSum[ (-1)^k  (f[k]/k), {k, 1, Infinity}]
> [...]

I suspect NSum gets fooled, using default behavior, from having
insufficiently many points to assess convergence. One gets what I
think is a better result by using more terms.

NSum[ (-1)^k  (f[k]/k), {k, 1, Infinity}, NSumTerms->200]

This gives -1.06272 + small imaginary part.

Alternatively one can tell NSum to not check for convergence.

In[61]:= NSum[ (-1)^k  (f[k]/k), {k, 1, Infinity}, VerifyConvergence-
>False]

SequenceLimit::seqlim:
   The general form of the sequence could not be determined, and the
result
    may be incorrect.

Out[61]= -1.07067

I do not know if the claim of divergence is a bug or a feature.

Daniel Lichtblau
Wolfram Research


  • Prev by Date: generalization of Bernoulli numbers to Pascal types
  • Next by Date: Re: how to solve this problem?
  • Previous by thread: Re: Re: a LOT of Mathematica bugs (some very old)
  • Next by thread: Problem with Rasterize[] on Strings