MathGroup Archive 2009

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

Search the Archive

Re: Help with a possible bug

  • To: mathgroup at smc.vnet.net
  • Subject: [mg98943] Re: Help with a possible bug
  • From: Raffy <raffy at mac.com>
  • Date: Wed, 22 Apr 2009 05:12:54 -0400 (EDT)
  • References: <gsivea$9bt$1@smc.vnet.net> <gsk2gp$nu3$1@smc.vnet.net>

On Apr 21, 2:09 am, Bob F <deepyog... at gmail.com> wrote:
> On Apr 20, 5:11 pm, M8R-lj1... at mailinator.com wrote:
>
>
>
>
>
> > At work we seem to have stumbled on a strange bug between Table and
> > Part.  We can reproduce the bug on differently configured Mac and
> > Linux boxes.  I tried Wolfram support, but they claim they cannot
> > reproduce the bug.  So I was hoping someone could try it out and
> > report their results.    Thanks in advance to all volunteers.
>
> > For us, the bug is new in 7.0.1. It does not show up in version 6.
> > To reproduce it, fill up a 17 x 267 matrix with 3s.  Compute the sum
> > of some of the columns and you get the result 51 (17 x 3).  But if on=
e
> > computes the sum for the last few columns, the result is completely
> > off.  The bug seems to arise from the interaction of optimizations =
 i=
> n
> > Table and the use of All inside of Part.
>
> > ------------  code
>
> >   mat = Table[3, {i, 1, 17}, {j, 1, 267}];
>
> >   sum = Table[Total[mat[[All, j]]], {j, 1, 249}]
>
> >   sum1 = Table[Total[mat[[All, j]]], {j, 1, 252}];
> >   sum2 = Table[Total[mat[[All, j]]], {j, 1, 252}]
>
> > ------------  end code
>
> > If you look at sum1, it will be correct on a fresh copy of the
> > Kernel.  The problem only arise from the second time on.
>
> > Thanks,
>
> > Papin
>
> > Email: ImportString["cGFwaW5AY294Lm5ldA==", "Base64"]
>
> How bizarre!! On my Mac with version 7.0.1 every sum for the last 18
> columns is bogus, and it appears that the bogus values keep changing
> in some sort of random way. For example if you tried
>
> mat = Table[3, {i, 1, 17}, {j, 1, 267}];
> Manipulate[
>  sum = Table[Total[mat[[All, jj]]], {jj, 1, mm}], {mm, 1, 267, 1}]
>
> everything is OK up thru 249th column (and even thru the 267th the
> first time on a fresh kernel just like you described), then as soon as
> you select any other of the 250th thru 267th columns - they total goes
> squirrely from then on for all subsequent TOTAL's that are calculated,
> and changes every time you look at any of the last 18 (even looking at
> the same column total the numbers are different, ie look at column
> 267, then 266, then 267 again and the numbers are different from the
> first time you looked), so there is apparently some sort of random
> gibberish it is picking up when the totals are calculated.
>
> Try sending Wolfram the Manipulate command and it's trivial to
> reproduce on a Mac -- make sure you stay on the phone with them while
> they try it on a Mac.
>
> To make it even more obvious, change the starting index on the
> Manipulate to 248 and start "playing" the manipulate and watch it go
> bonkers. The numbers seem to always be 9 digits and are between the
> upper 200 millions and the middle to upper 300 millions in magnitude,
> but didn't seem to get much different even after letting the
> Manipulate play for quite a while at the highest "speed".
>
> Let us know what they say.
>
> -Bob

It is definitely a bug with auto-compilation.

SetSystemOptions["CompileOptions" -> "TableCompileLength" -> Infinity]
will restore expected operation.


  • Prev by Date: Re: Mathematica in conjunction with outside program; NMinimize fails.
  • Next by Date: Re: Help with Speeding up a For loop
  • Previous by thread: Re: Help with a possible bug
  • Next by thread: Re: Re: Help with a possible bug