Re: subscripted variables and comments
- To: mathgroup at smc.vnet.net
- Subject: [mg24479] Re: subscripted variables and comments
- From: "David Bailey" <db at salford-software.com>
- Date: Wed, 19 Jul 2000 01:21:53 -0400 (EDT)
- Organization: University of Salford, Salford, Manchester, UK
- References: <8kjd7u$dsd@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
"David Chapman" <d.a.chapman at open.ac.uk> wrote in message news:8kjd7u$dsd at smc.vnet.net... > This may be too vague for anyone to help, but any ideas would be > gratefully received. > > I'm using lots of subscripted variables which I have set up with > Symbolize (Mathematica v4). I use them in long > functions in Packages created from Notebooks with the 'Auto Save > Package' facility, and the function > definitions contain comments (* ... *). > > I get things working OK, then do a minor edit and find that when I load > the package (<< blah.m) into a > notebook I get messages indicating that it has got confused by the > subscripted variable, eg: > > Syntax::bktwrn: > "elect(2 B\_laser-B\_elect)" represents multiplication; use > "elect[2 B\_laser-B\_elect]" to represent a function. > > (The first elect in this was the subscript of B\_elect) If I open the > Notebook that I used to create the Package > and run the function from there I don't get the message and the function > can be used fine. Sometimes the > solution seems to be to remove any spaces on either side of the > comments, but on other occasions I've not > found any spaces and I've resorted to deleting all my comments from the > function definition - which is a pity > since my programs are confusing enough even with the comments present! > I am not certain, but I think this is a manifestation of a bug associated with autogenerated packages that was present in 3.0 and 4.0. When you save a notebook containing a lot of 2-dimensional stuff you sometimes find that the associated .M file is created in a corrupt form. The solution is to save the file TWICE one after another. Surprisingly, this seems to produce a valid .M file every time! I have reported this bug. I wonder if anyone at Wolfram Research could comment further. David Bailey Salford Software