Re: What is the point of having Initializations in DynamicModule and Manipulate?
- To: mathgroup at smc.vnet.net
- Subject: [mg123051] Re: What is the point of having Initializations in DynamicModule and Manipulate?
- From: "David Park" <djmpark at comcast.net>
- Date: Tue, 22 Nov 2011 05:32:45 -0500 (EST)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- References: <398831.35647.1321702630679.JavaMail.root@m06> <008c01cca6e3$cf88ae50$6e9a0af0$@net> <18060170.45623.1321740380976.JavaMail.root@m06>
Hi Mike, (After looking at today's replies on MathGroup.) But isn't it all very complicated and unintuitive? This basically arises because WRI wanted a set-piece Manipulate statement that would do just about everything for standalone dynamic displays. I just about never use the Manipulate statement. It takes more than a Manipulate statement to present a significant idea. One has the feeling that the Initialization option was added as an afterthought to make Manipulate work on some additional cases. Then this was carried over to DynamicModule. It is so much easier to write custom dynamics using the basic WRI routines. You can write specifications in a logical and intuitive form. For a long time I was confused as to how one would write dynamic displays that had primary and secondary dynamic variables. The primary dynamic variables would be ones that were set by controls such as Sliders or Locators. The secondary dynamic variables are ones that depend on the primary variables and might be used in various ways. It really took me a year after Version 6 came out to figure out the straightforward way to do this. The template goes like this: DynamicModule[ {(* primary dynamic variables with initial values *), (* dependent dynamic variables *), (* other variables *), calcAll}, calcAll[primary variables] := definition; (* Initialize dependent variables *) calcAll[primary variables]; (* Formatted display statements containing graphics, controls and results. *) ] The calcAll routine is called in the second argument of Dynamic within each control. For example, it we had three points being controlled by three Locators, then one of the Locators might look like: Locator[Dynamic[ptA, (ptA = #; calcAll[ptA, ptB, ptC]) &], .] (In some cases we might have more than one calc routine with different routines used in different controls.) Of course, things that have to be refreshed in the display have to be wrapped in Dynamic. Also this allows us format the presentation in any manner we wish and not have to manipulate the Manipulate options or guess which controls or what format will be used. This has always worked for me and is very convenient. There is an extended step by step tutorial on this in the PlaneGeometry section of Presentations. It is centered mainly around dynamic geometric diagrams, something like Geometer's Sketchpad, but the basic format works for everything. Presentations also has page formatting commands (panelpage, page, pagelet, phrase, twocolumn) that make it easy to format presentation displays. The next release of Presentations will have several new Sliders. VernierSlider allows the user to control individual digits of an extended precision variable (although holding down Alt or Ctrl+Alt when moving a slider gives finer control with present Sliders). MultiSlider allows a single slider to be used to control multiple variables and eliminates the proliferation of Sliders in a single dynamic display. David Park djmpark at comcast.net http://home.comcast.net/~djmpark/ From: Mike H [mailto:mike.honeychurch at gmail.com] Hi David, The background was that I approached tech support after noticing that stuff that was to be initialized was not being evaluated prior to the body of the DynamicModule. My code is too lengthy to post -- runs to several pages and the initializations are about a page of code. So the point of my question to users is whether they expect initializations to occur *initially*, i.e. prior to the evlaution of the body of the DynamicModule. The code I posted was an example sent to me by tech support of something working as designed. However that code works as my code does, i.e. the body is evaluated *prior* to the initializations. To me if that is by design the design is wrong. If I place all my initialization code in the body of the DynamicModule then everything works fine, but my point is solely about how the option In Initialization is functioning. The example provided is working as designed apparently -- whereas I regard it as not working. I welcome the views of other users about this. Maybe some of you can point out why this is a feature rather than a flaw. Mike (Armand when I post from Google groups)
- Follow-Ups:
- Re: What is the point of having Initializations in DynamicModule and Manipulate?
- From: Andrzej Kozlowski <akoz@mimuw.edu.pl>
- Re: What is the point of having Initializations in DynamicModule and Manipulate?