Mathematica 4 complex packed arrays bug

*To*: mathgroup at smc.vnet.net*Subject*: [mg19095] Mathematica 4 complex packed arrays bug*From*: slinger at signal.dra.hmg.gb (Chris Slinger)*Date*: Thu, 5 Aug 1999 01:35:13 -0400*Organization*: DERA Malvern*Sender*: owner-wri-mathgroup at wolfram.com

Thanks to everyone who has been involved in tying the Mathematica v4 complex packed array bug down. These included: hay at haystack.demon.co.uk, ErsekTR at navair.navy.mil, rfinley at medicine.umsmed.edu, schaferk at communique.net, tgarza at mail.internet.com.mx, kuska at informatik.uni-leipzig.de I thought I would briefly summarise the current state of play. Firstly, a simple demonstration of the bug: In[1]:= $Version Out[1]= "4.0 for Microsoft Windows (April 21, 1999)" In[2]:= f=Fourier[{1}]; f[[1]]=2.0 + 1.0 I; f Out[2]= {2. + 2. I} The result should, of course, be {2. + 1. I}. Wolfram Support (see bottom attachment) confirm that a bug exists when setting parts of complex, packed arrays under certian circumsrances. Actaully, they like euphemisms, and call it "wrong behaviour" :-) You will recall that packed arrays are a new Mathematica feature, appaearing for the first time in v4. To demonstrate that the bug occurs in other situations (and is not a problem associated with Fourier[], for example), note : In[3]:= f=Developer`ToPackedArray[{1. + 1. I}]; f[[1]]=2.0 + 1.0 I; f Out[3]= {2. + 2. I} However, integer components seem fine: In[4]:= f=Developer`ToPackedArray[{1. + 1 I}]; f[[1]]=2.0 + 1.0 I; f Out[4]= {2. + 1. I} In[5]:= f=Developer`ToPackedArray[{1. + 1. I}]; f[[1]]=2.0 + 1 I; f Out[5]= {2. + I} This confirms that it is the new packed arrays, and that we can expect problems whenever we try setting parts to any non-integer, complex packed array. Therefore, any function which generates a packed complex array (to enhance speed of execution and reduce memory use under v4) - such as Fourier[] - could cause problems in any subsequent setting of non-integer parts in the resulting array. The conversion to packed arrays is done "automatically by many functions that generate large lists" (according to the on-line help for Developer`ToPackedArray[]), so the instances where this bug could give erroneous results would seem to be quite large (unfortunately, I do not have a list of the functions - any ideas ?). There are several ways around this. As suggested by Wolfram Support, conversion to unpacker array format is one (using Developer`FromPackedArray[]), but this is at the cost of extra memory and the loss of some speed. Another, far more satisfactory, is to use ReplacePart[]. This seems to work well (especially as the bug in ReplacePart[] in version 3 has been fixed !). Finally, it does seem somewhat surprising that this has not been picked up before, methinks. <IF> Wolfram developers did know about it, it is yet another example of a situation where a bug list would have saved users a lot of time rediscovering something that Wolfram already knew... Thanks again to everyone who contributed, -chris ----- Begin Included Message ----- From: support at wolfram.com To: mathgroup at smc.vnet.net Subject: [mg19095] [TS 14003]--Re:Re: [TS 13854]--Re:HELP ! - Mathematica v4 not producing correct results when compared to Mathematica v3 Hello, Thank you for the email. I spoke with one of our developers and they said that the problem is definitely wrong behavior. This has absolutely nothing to do with Fourier. It is wrong behavior, but the wrong behavior is in setting parts for complex packed arrays under certain circumstances. He recommended that you use the following workaround: output = Developer`FromPackedArray[Fourier[ideal]]; Do[output[[i,j]]=ideal[[i,j]],{i,1,2},{j,1,2}]; output This problem will be fixed for the next release. No date is yet available for when this will be released. I hope this helps.