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

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