Re: OOP in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg37624] Re: OOP in Mathematica
- From: atelesforos at hotmail.com (Orestis Vantzos)
- Date: Wed, 6 Nov 2002 06:58:29 -0500 (EST)
- References: <aq8653$e3i$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
I agree in general with Adrzej's position. It is true that traditional uses of Mathematica, namely mathematical computations of one kind or another, have little to gain from pseudo-OOP that is evidently alien to the functional/rule-based style. Nevertheless: a) People have started to apply Mathematica to a wider range of problems (XML for instance) and even when they attack common problems, they use it in novel ways (front-end programming is much in demand, yet the elegance of Mathematica's programming language turns into a nightmare in this case). OOP is the well established methodology in most of these cases. b) Maeder's package should never have been used as extensively as it did, although this is a strong indication that people do use OOP in conjunction with Mathematica. In the 'OOP in Mathematica- A concrete example' thread I provide a deceptively simple mechanism by which OOP can be implemented within the strict confines of Mathematica's functional/rule paradigm. The concept behind it appears very natural to me; it's all about letting a symbol use another symbol's DownValues. Anyway, Adrzej does not challenge the technicalities of it. He asks, why OOP? Why not stick to functional/rule programming? I can tell you what got me begging for OOP in the first place... I was working on a really large set of non-linear ODEs that had the really bad habbit of blowing up. I had to manually set the StopingTest option of NDSolve so that each time a variable blew, NDSolve would stop, return the time that had elapsed, the variable that did it and ofcourse the InterpolatingFunction up to that point. Then, I would automaticaly recalculate a new ODE system minus the blown variable and call a new NDSolve to carry on, etc. Finally, all those InterpolatingFunction objects had to be glued together and returned in a useful format along with all sorts of performance and debugging information. On top of all that, all the aforementioned information had to be stored in a file. I started wroting all the appropriate functions and ...got stuck! I knew how to write the relevant functions, but it just didn't work out really well. You see everything had to be passed from function to function in a literal form. But the data structures that resulted were both too nested and too large. I wrote elaborate rules that dug into the huge lists and did the job but they were both too complicated and too slow. The functions got really involved, with scores of arguments and local variables. You see, each functions had to splice the expression that was given, do its deed, and then pack it all up and pass it to the next function. It was hell... Then I decided that I would store all the intermediate information into symbols. I wrote a simple constructor and an interface. Finally, I could get the information when and where I needed it. It didn't change the core of what I was doing- no programming revelation per se. Most of the functions I had written remained the same actually. It was just that everything got much much tidier. The juicy part was still functional; encapsulation had simply made it more clear. The rest is history; once you accept that Mathematica programming works even when it operates on implicit information hidden in symbols rather on explicit one assorted in lists, OOP is only a few functions away. Orestis Vantzos