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.