Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
1996
*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 1996

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

Search the Archive

Re: More Anomalous Behaviour with Indexed Variables

  • Subject: [mg3317] Re: [mg3256] More Anomalous Behaviour with Indexed Variables
  • From: mrj at cs.usyd.edu.au (Mark James)
  • Date: 26 Feb 1996 13:34:06 -0600
  • Approved: usenet@wri.com
  • Distribution: local
  • Newsgroups: wri.mathgroup
  • Organization: The University of Sydney
  • Sender: daemon at wri.com

Jens-Peer Kuska wrote:

> Hi Mark,
> 
> at first
>   I think that it is really dangerous to use sutch side
>   effect, because there is *no* guarantie that NDSolve evaluate
>   the differential equations in the same order as given. NDSolve
>   has to do a lot of things bevore it can start with the numerical
>   solution.

That's true, but the benefits are too hard to resist.  It has
sped my code up by a factor of three.  I hope it will still
work in 3.0.  Even better, I'd like to see a parameter for
NDSolve where one can specify a function to be called at the
beginning of every integration step.
 
> at second
>   don't talk about efficient solutions, Mathematica is a interpreter
>   and will be allways 100 or more times slower than a compiled
>   code. You can still using Mathematica via MathLink for dawing and post processing.

True too.  I have considered doing this, though it would involve buying
a C compiler, choosing an algorithm, finding appropriate code on the
net, purchasing an MMA version that has Mathlink, and working out how
to make Mathlink work.  I will have to do this eventually when my
simulations get larger.

Your solution using list indexing rather than function definitions
will not work, as initializing f results in f[[1]] being replaced
by 0 when the equations are initially evaluated by NDSolve.
Updates in f[[1]] will never be used.  TracePrint displays this:

(*
     PARAMETER IS: f[[1]]
*)
Clear[ f, calc ];
f={0.};
calc[ v_Real ] := ( f[[1]] = Sqrt[v]; 0 );
TracePrint[
NDSolve[ {dummy'[t]==calc[p[t]], dummy[0]==0, p'[t] == -p[t] + f[[1]], p[0]==0 },
         {dummy,p}, {t,0,1}, Compiled->False ]
, TraceDepth->1 ]

Frans Martens has send me a solution that works, both on this simple
example and my realworld system.  For the example system it
involves simply replacing f[1] by f[1.] in the defintion of calc.
Apparently NDSolve coerces all function indices to reals.
All my integration variable and equation parameters are now indexed
by reals.

Thanks for taking the time to have a look at this. -- Mark


  • Prev by Date: Re: More Anomalous Behaviour with Indexed Variables
  • Next by Date: [Q] Erfi - what is it?
  • Previous by thread: Re: More Anomalous Behaviour with Indexed Variables
  • Next by thread: Combinatorics question