Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2000
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2000

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

Search the Archive

Re: Big trouble with Mathematica Code parsing --

  • To: mathgroup at smc.vnet.net
  • Subject: [mg26322] Re: [mg26244] Big trouble with Mathematica Code parsing --
  • From: Jacqueline Zizi <jazi at club-internet.fr>
  • Date: Sun, 10 Dec 2000 21:38:06 -0500 (EST)
  • Sender: owner-wri-mathgroup at wolfram.com

To Louis Pecora  and people having this kind of problem.
-------------------------------------------------------------------

Thanks  for your  notebook. I just opened it as it is,  without running
it.
I can notice that there is 4 blue error messages before the "result"
that annoys you:

- Part::"pspec": "Part specification \!\(Null\) is neither an integer
nor a \
list of integers."
- Part::"pspec": "Part specification \!\(Null\) is neither an integer
nor a \
list of integers."
- Part::"pspec": "Part specification \!\(Null\) is neither an integer
nor a \
list of integers."
- General::"stop": "Further output of \!\(Part :: \"pspec\"\) will be \
suppressed during this calculation."

Try to understand what are the messages before asking any question on
the result. Just think to a person skiing very fastly and falling.
Probably you will not be able to understand how things will finish, if
you just see the fall? In clear: as long as you have error messages,
consider that something wrong happened and that the results can't be
guessed or guarantied. In Fortran things are different, you are dead as
soon as you fall.

So please get rid of your messages by having running code FIRST before
commenting the result.
In clear : " please debug your code"

For that, I suggest:

1) as I  notice that you have quite often a lot of stuff in ONE large
cell, to cut things in as many cells as possible. Doing that you can
localize the problem more easily. Why do you put all your eggs in one
basket when typing it in? Why don't you put one thing in one cell right
from the beginning?

2) to try to see if  Return is really usefull. For me it shows as it is
not most of the time. For example, you have in a little one cell:

(* Make original Smallworld matrix. *)
makswmat[n_, k_, c_] := Module[{},
    setlatticedata[n, k, c];
    Return[makswmat[]];
    ]

It is quite difficult to follow what you are doing as you have funny
names for your functions that have a meaning just for you. So I might
miss something but I believe that this could be rewritten in 2 cells
that gives the same effect:

a) a cell  text containing : Make original Smallworld matrix
b) another cell , an  Input  cell containing:
makswmat[n_, k_, c_] := (setlatticedata[n, k, c]; makswmat[])

Indeed you are just applying 2 functions in the makswmat body, so Module
is not usefull. Applying makswmat will return the last value i.e.
makswmat[].
Doing so you'll have 1 line to check instead of 5 as the cell text can't
bring error for evaluation.

3) when all this is done, Evaluate cell after cell and go on only if the
code is clean enough and there is no error message. With some chance,
your "Big Trouble" will not be there anymore.

If still there, call again Mathgroup, as I see quite a lot of other
things in your code that are warm beds for user's errors being.

I hope this helps.

Jacqueline Zizi



  • Prev by Date: Re: Re: embedding Mathematica equations in MS Word part 2
  • Next by Date: Re: Re: Big trouble with Mathematica Code parsing -- Rant.
  • Previous by thread: General linear functions
  • Next by thread: rules for Sign[_]^n