# Tag Info

13

The problem relates to the granularity of MachinePrecision numbers. The number 70.329862 is represented as an integer times a power of 2: x0 = SetPrecision[70.329862, Infinity] (* 4949024067128413/70368744177664 *) (The denominator is 2^46.) The machine numbers near this number do not allow for the representation of 70.329862 with $MachinePrecision ... 13 Based on Mr.Wizard's answer and Szabolc's comments to it, I now understand that the code I posted does have undesirable side-effects and it should be avoided. Specifically, the scoping constructs Module and Block are meant to completely localize the variables in their first argument (for more information see this question). However, placing their scoped ... 10 Dynamic has this build into it. You can take advantage of the Dynamic second and third arguments. The second argument of evaluate as the dynamic is being updated. The third argument is evaluated when the mouse is released. Which is what you want. To illustrate, here is an example, where f[r] and g[r] are inside the arguments of the slider itself. This is ... 10 My defined function next find {nextpoint, nextdirection} value from {startpoint, startdirection} using NSolve. next[{sp_, sd_}][δ_] := Module[{φ, sol, fp, fd}, sol = NSolve[{{x[φ, δ], y[φ, δ]} == sp + t sd, Abs[t] > 10^(-9), 0 <= φ < 2 π}, {t, φ}, Reals]// Quiet; sol = If[Length[sol] > 0, sol[[1]]]; fp = {x[φ, δ], y[φ, δ]} /. sol; ... 9 ControlActive is useful for this purpose: DynamicModule[{r = 1, old = 1} , Grid[ { {Slider[Dynamic[r]], SpanFromLeft} , {Dynamic[f[r]], Dynamic[g[ControlActive[r, old = r]; old]]} } ] ] The variable old has been introduced to hold the "old" value of r. The key expression is ControlActive[r, old = r]; old, which always returns the value of ... 9 By default, DynamicModule uses SynchronousInitialization -> True. This causes the initialization to be performed on the preemptive link, disabling any updates to the front-end. In particular, print statements, cell creation and dynamic box updates will all be deferred until the initialization completes. If we wish to monitor that initialization within ... 8 Note that you've defined t as a Dynamic expression. A relational operator like GreaterEqual (>=) works with numeric expressions like the result of Clock. You could try something like this to get a displayed output that eventually switches from False to True: step = .1; Dynamic[{t, t = Clock[{0., 5., step}, 5., 1]; t >= 2}] 8 EDIT Input gets different rounding to machine-precision real if it's written in arbitrary precision! RealDigits[70.329862, 2] (* {{1, 0, 0, 0, 1, 1, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1, 1, 1, 0, 0, 0, 1, 1, 1, 0, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 1, 1, 1, 0, 1}, 7} *) RealDigits[ SetPrecision[70.329862000000000000, ... 8 Just a kickstart to get the equations right (yours are wrong) and an idea of the system dynamics: With[{Pr = 10, a = 1.181, b = 0.675, v = 0.77, l = 8/3}, pfun = ParametricNDSolveValue[{ x'[t] == Pr v (y[t] - x[t]), y'[t] == R (b/v) x[t] - a y[t] - (b/v) (R - (a v)/b) x[t] z[t], z'[t] == a l (x[t] y[t] - z[t]), x[0] == y[0] == 0.8, ... 7 Here's a trivial example of the method in my comment. I've used total absolute difference for error (you can use whatever you please), and I put in a Pause so you can observe the effect for this trivial problem that would be blink-of-an-eye fast. In reality, you'd want to use UpdateInterval or equivalent, or Sow if you want the "history" post-run. Doing ... 7 The reason for this behaviour is that as soon as the cursor gets away from a particular vertex marker it leaves the associated EventHandler. Here's a work-around, let's associate the event handler with the whole Graph. We just need to take care of updating the proper pos. DynamicModule[{ind = 1, pos1 = {1, 0}/2, pos2 = {1, 1}/2, pos3 = {-1, 0}/2}, ... 7 This is a very common problem for people who work on data analysis. Here as a solution to the problem using LocatorPane and a few other functions and tricks. TooltipListPlot[data_, tipFunction_, listPlotOptions___] := DynamicModule[ {displayQ = False, yRange , xRange, pt, minX, maxX, minY, maxY, tip, threshold, tipPosition, nf, dataPoints, ... 7 SynchronousInitialization -> True causes dynamic evaluations to occur on the preemptive link. This locks up the notebook front-end for the duration of an evaluation. To avoid locking up the front-end indefinitely, there is a default timeout of six seconds: CurrentValue[EvaluationNotebook[], DynamicEvaluationTimeout] (* 6. *) The values we see for x ... 7 Try this: Solve[c == 0.0625 + 0.0008*X - 0.0232*Y - 0.0157*Z + 0.0059*X^2 + 0.0112*Y^2 + 0.0160*Z^2 - 0.0063*X*Y - 0.0243*X*Z + 0.0211*Y*Z // Rationalize, Z] (* {{Z -> 1/320 (157 + 243 X - 211 Y - \[Sqrt](-375351 + 6400000 c + 71182 X + 21289 X^2 + 82226 Y - 62226 X Y - 27159 Y^2))}, {Z -> 1/320 (157 + 243 X - ... 7 Here's a walkaround: Manipulate[ x, Row @ List @ EventHandler[ Checkbox[Dynamic[x]], {"MouseDown" :> (x = True), "MouseUp" :> (x = False)}] ] 6 Expanding a little over rasher's answer: data = Table[{x, Log[3.5 + 2.5 x^2] + RandomReal[{-1, 1}]}, {x, 0, 10}]; r = {}; s = {}; u = {}; Dynamic[ GraphicsGrid[{{ Plot[Log[r[[-1]] + s[[-1]] x^2], {x, Min@data[[All, 1]], Max@data[[All, 1]]}, PlotLabel -> "Fitting", Frame -> True, Epilog :> {Red, PointSize[Medium], ... 6 Here's one solution that meets the criterions. I'll walk through the main ideas step by step. First I started by creating a list of circles and a list of lines. Then I formed a region from those elements, which I called grid. I also added the gridlines that were used originally and so recreated the plot: circles = Table[Circle[{0, 0}, r], {r, 1, 14}]; ... 6 You don't have repeat yourself. You can map a pure function defining the button over a list of the background colors and then apply Mouseover Like so: Mouseover @@ (Button[Panel["Print", FrameMargins -> {{4, 4}, {4, 4}}, Background -> #], Print["Print"], Appearance -> None] & /@ {Red, Green}) 6 Perhaps something like this? text = ""; EventHandler[ InputField[Dynamic@text, String, ContinuousAction -> True], {"ReturnKeyDown" :> Paste["\n"]} ] 6 The problem seems to be that a TagBox that is generated is handled incorrectly by the front end. The TagBox has the form TagBox[bigExpr, Deploy, DefaultBaseStyle -> "Deploy"]. In this expression the second argument Deploy is quite meaningless. I couldn't trace any further than this TagBox as I cannot see how the front end handles it. How the kernel ... 6 In your example the resolution of image is going to zero with number of points and you will see the scattered field after addition of some dozens of thousands of points.. What is the sense of such drawing and moreover the sense of dynamic updates of such graphics? May be it is better to use something like this, with pre-defined size: data = Table[0, {i, ... 6 you could start with a simple hack of your code to extract the intersections; Something like {x1, y1} = Transpose[line]; {x2, y2} = Transpose[RotateLeft[line]]; gr2 = {(x1^2 - x1*x2 + y1*(-y1 + y2)), (y1 - y2)} // Transpose // Most; which can be encapsulated in the ellipseSimLowLevel as follows ellipseSimLowLevel[ellPos_, θ_, aimAt_, refls_, ... 6 This appears to be a front-end bug involving the evaluation of arrays and built-in functions within a DynamicBox. The original example can be made to work by defining max = Max; and using the user function max in place of the built-in functionMax: max = Max; DynamicModule[{s = 1, q = {{False}}}, {Checkbox[Dynamic[q[[1, 2 - max[s, 0]]]]], Dynamic[q[[1, 2 ... 6 I believe that highlighting is there specifically to encourage you to use DynamicModule rather than Module: DynamicModule[{A = 1}, Manipulate[Plot[A Sin[k x], {x, 0, 20}], {k, 1, 10}]] One reference: http://forums.wolfram.com/mathgroup/archive/2011/Sep/msg00198.html Also related: Table function with Part[] call misbehaving, but only after initial ... 6 An alternative approach using CurrentValue["MouseOver"]: Button[Panel["Print", FrameMargins -> {{4, 4}, {4, 4}}, Background -> Dynamic@If[CurrentValue["MouseOver"], Green, Red]], Print["Print"], Appearance -> None] or, without the Panel, Button["Print", Print["Print"], Background -> ... 5 How about this: ClearAll[framed, button,$opts]; $opts = {}; Options[framed] = {a -> 1}; button[x_] := With[{opts =$opts}, Button[x, Print@framed[x, opts]]]; framed[x_, opts : OptionsPattern[]] := Block[{\$opts = Flatten[{opts}]}, Framed[{button[x], OptionValue@a}] ]; and you use this as before: Print@framed["Push", a -> 1111] ...

5

Quick fix is to add ContentSelectable -> False, ImageSize -> Dynamic[Automatic, None] to Graphics options. Now the it is behaving well with exeption of orange frame that appears to allow you to change ImageSize, which is supressed by Dynamic[#, None]. More generic approach Something strange is happening. When we set Deployed -> True and ...

5

For example: Manipulate[ LocatorPane[Dynamic[{x, y}], Graphics[{Red, Disk[]}]], {{x, 0}, InputField}, {{y, 0}, InputField} ]

5

Explanation of the behavior First, let me dispense with the OP's second example. I assume RandomReal[{-1, 1}] is treated as not depending on any symbol (except possibly RandomReal, although I would not be surprised if Protected symbols were excluded from dynamic tracking). So unlike Clock, RandomReal will not cause an update merely because it will ...

5

Update. Thanks to Eldo, Dynamic is needed outside the InputField. DynamicModule[{a = 1, b = 20, fuc = "1"}, Deploy[Style[Panel[Grid[Transpose[ { {"Input Format", "Value"}, {PopupMenu[Dynamic[fuc], {"1", "2"}], Dynamic@InputField[ If[fuc == "1", a, b], Number, Enabled -> Dynamic[fuc == "1"] ...

Only top voted, non community-wiki answers of a minimum length are eligible