Community RSS Feed
http://community.wolfram.com
RSS Feed for Wolfram Community showing any discussions in tag Dynamic Interactivity sorted by active[✓] Call a slow running function from dynamic interface?
http://community.wolfram.com/groups/-/m/t/1205472
I have a custom function which demands much time (maybe several hours) to calculate result. I wanted to call the function from dynamic interface, where I define input variables and call the function by button. I found that the function outputs results differently from the case, when I call it without interface. And calculation is aborted after short time without any error message. The function is outside the interface. I tried different methods to force the function to run till end of calculation but in vain. I made a simple example to show the problem.
(*Example of function with long time of execution*)
long[max_] := Block[{ max1},
max1 = max;
Print["max=", max1];
Table[Print[i, " ", ProgressIndicator[i, {0, max}]]; Pause[2],
{i, 1, max1}];
Print["End"]
]
(*Call of long[max]*)
long[8]
The function runs till end.
(*Call of the same function from interface*)
DynamicModule[{},
Column[{
Row[{Control[{n, {3, 5, 8, 10, 20}}]}],
Button["Start", long[n]]}]
]
The function terminates after 6 sec of running
Is it possibility to call slow function from dynamic interface?Ivan Siahlo2017-10-19T16:02:43Z[GIF] Vitals (Animated von Mises distribution)
http://community.wolfram.com/groups/-/m/t/1199921
![Animated von Mises distribution][1]
**Vitals**
This one is pretty simple: there are 22 rows of dots, translating left or right depending on whether the row number is even or odd. Within each row, you can see the dots as plotting the density of the [von Mises distribution][2]. Specifically, the radius of each dot is the value of the von Mises pdf at that point.
Note that the von Mises distribution is like a Gaussian distribution on the circle. In particular, it is a periodic probability distribution, which is why each row is periodic, showing a total of 5 periods.
Here's the code:
Manipulate[
Show[
GraphicsGrid[
Table[{
Graphics[{
Lighter[ColorData["Rainbow"][1 - (n + 10)/21], .2],
Disk[{#, 0}, PDF[VonMisesDistribution[0, .3], Mod[# + (-1)^n t, 2 π, -π]]] & /@ Range[-4 π, 4 π, π/6]},
PlotRange -> {{-4 π - π/12, 4 π + π/12}, {-.5, .5}}]},
{n, -10, 11}],
Spacings -> {-6, Automatic}], ImageSize -> 600, Background -> GrayLevel[.1],
PlotRangePadding -> {None, Scaled[.0242]}
],
{t, 0, 2 π}]
[1]: http://community.wolfram.com//c/portal/getImageAttachment?filename=dots12sc.gif&userId=610054
[2]: https://en.wikipedia.org/wiki/Von_Mises%E2%80%93Fisher_distributionClayton Shonkwiler2017-10-09T00:55:26Z[GIF] Trifolium (Envelope of the trifolium curve)
http://community.wolfram.com/groups/-/m/t/1202255
![Envelope of the trifolium curve][1]
**Trifolium**
The animation shows 800 tangent lines to the trifolium as they slowly move around the curve. In order to make it, I first ran `PlaneCurveData["Trifolium", "ParametricEquations"]` to get the parametrization, which I then rotate to get a vertically-oriented trifolium:
tri[t_] := RotationMatrix[π/6].{-Cos[t] Cos[3 t], -Cos[3 t] Sin[t]};
After that, it's just a matter of creating the tangent lines with `InfiniteLine[]` and choosing some colors. Here's the code:
With[{d = 2 π/800.},
Manipulate[
Show[
Table[
Graphics[{Thickness[.001], Opacity[.8], Hue[Mod[(s + t)/π, 1]],
InfiniteLine[tri[t + s], tri'[t + s]]},
PlotRange -> {{-1.4, 1.4}, {-1.18125`, 1.61875`}}],
{t, 0., π - d, d}],
ImageSize -> 540, Background -> GrayLevel[.1]],
{s, 0, d}]
]
[1]: http://community.wolfram.com//c/portal/getImageAttachment?filename=lem8.gif&userId=610054Clayton Shonkwiler2017-10-13T03:19:40Z[GIF] Grid (Transformation of the square grid)
http://community.wolfram.com/groups/-/m/t/1204826
![Transformation of the square grid][1]
**Grid**
Unlike [_Part of the Journey_][2], [_Play_][3], and [_Limits_][4], this is not a conformal transformation of a regular grid on the plane. Instead, I've taken the square grid, inverse steregraphically projected it to the sphere, then orthogonally projected back to the plane, producing a collection of curves contained in the unit disk. This is not conformal since orthogonal projection does not preserve angles.
In the animation, I'm translating the entire grid by $-t (1,2)$ as $t$ varies from 0 to 1, which is a symmetry of the square grid, and applying the inverse-stereographic-project-then-orthogonally-project transformation.
There are a couple of quirks in the code. First, the `Disk[]` is there because I didn't extend the grid out far enough to actually fill in the center (which would have been computationally expensive); instead I just placed a small disk in the center to cover the hole in the middle. Second, the funny business on `x` in the `Table[]` is because I'm using progressively less precision for the grid lines which cluster in the center in order to cut down on computational complexity that doesn't actually contribute anything visible.
Anyway, here is the code:
InverseStereo[{x_, y_}] := {2 x/(1 + x^2 + y^2), 2 y/(1 + x^2 + y^2), (x^2 + y^2 - 1)/(1 + x^2 + y^2)};
With[{d = 30, cols = RGBColor /@ {"#FF5151", "#000249"}},
Manipulate[
Graphics[
{cols[[1]], Disk[{0, 0}, .07], Thickness[.003],
Line /@ # & /@ (Transpose /@ Table[InverseStereo[# - t {1, 2}][[;; 2]] & /@ {{n, x}, {x, n}},
{n, -d - 0.5, d + 0.5, 1},
{x, Join[Range[-d, -20], Table[-20 + i Abs[n]/40, {i, 1, 1600/Abs[n]}], Range[20, d]]}])},
Background -> cols[[-1]], ImageSize -> 540, PlotRange -> 1.1],
{t, 0., 1}]
]
[1]: http://community.wolfram.com//c/portal/getImageAttachment?filename=stereotiles12c.gif&userId=610054
[2]: http://community.wolfram.com/groups/-/m/t/1171765
[3]: http://community.wolfram.com/groups/-/m/t/1173214
[4]: http://community.wolfram.com/groups/-/m/t/1179440Clayton Shonkwiler2017-10-18T05:10:47Z[GIF] Voronoi visualization
http://community.wolfram.com/groups/-/m/t/1202074
I recently saw a gif showing the [growth of a Voronoi diagram][1] on [this][2] wiki page. This gif shows a Voronoi diagram but restricts each cell to lie in a disk that slowly grows over time.
I decided to recreate this with the Wolfram Language and thought I'd share the code and final result here.
#Visualization
First and foremost, here's the result:
![enter image description here][3]
#Code
First I start off with 20 random points in 2D:
pts = RandomReal[{-1, -1}, {20, 2}];
Then I extract each point's Voronoi cell by calling `VoronoiMesh` and then arranging the primitives to correspond to `pts`.
voronoi = VoronoiMesh[pts, {{-1, 1}, {-1, 1}}];
prims = BoundaryDiscretizeRegion /@ MeshPrimitives[voronoi, 2];
prims = Table[First[Select[prims, RegionMember[#, p] &]], {p, pts}];
Let's quickly pause to make sure the cells correspond to the correct point.
MapThread[Show[#1, Epilog -> {Red, PointSize[Large], Point[#2]}] &, {prims, pts}][[1 ;; 5]]
![enter image description here][4]
Now that we have the primitives, we can show the scene with disks of radius $r$ by applying `RegionIntersection` at each cell with a disk of radius $r$.
First we will discretize a disk to force `RegionIntersection` to return a `BoundaryMeshRegion`.
disk[{x_, y_}, d_, n_:100] := BoundaryMeshRegion[CirclePoints[{x, y}, d, n], Line[Mod[Range[n + 1], n, 1]]]
Now at radius $r$ we intersect, which I packed into a function. First, here's the code for a single cell. It will take the Voronoi cell, its corresponding point, and a color for styling purposes.
colors = RandomColor[RGBColor[_, _, _, 0.3], 20];
PartialVoronoiCell[r_][p_, cell_, color_] :=
BoundaryMeshRegion[
RegionIntersection[disk[p, r], cell],
MeshCellStyle -> {1 -> Directive[Thick, GrayLevel[.5]], 2 -> color}
]
The main function will effectively map over each point. When $r \leq 0$, we just show the points.
PartialVoronoiCells[_?NonPositive] = Graphics[Point[pts], PlotRange -> {{-1, 1}, {-1, 1}}, PlotRangePadding -> Scaled[.0125]];
PartialVoronoiCells[r_] :=
Show[
MapThread[PartialVoronoiCell[r], {pts, prims, colors}],
Epilog -> Point[pts], PlotRange -> {{-1, 1}, {-1, 1}}, PlotRangePadding -> Scaled[.0125]
]
This function is fast enough to visualize the growth with `Manipulate`.
Manipulate[PartialVoronoiCells[r], {r, 0, 1}]
![enter image description here][5]
[1]: https://en.wikipedia.org/wiki/Voronoi_diagram#/media/File:Voronoi_growth_euclidean.gif
[2]: https://en.wikipedia.org/wiki/Voronoi_diagram
[3]: http://community.wolfram.com//c/portal/getImageAttachment?filename=voronoi.gif&userId=46025
[4]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshot2017-10-1221.55.07.png&userId=46025
[5]: http://community.wolfram.com//c/portal/getImageAttachment?filename=screenshot.gif&userId=46025Chip Hurst2017-10-13T02:59:08ZAvoid to evaluate cells twice for the initialization of a Manipulate?
http://community.wolfram.com/groups/-/m/t/1204311
This manipulate program below allows the user to enter points on a LocatorPane and then draws a line through the points.
![enter image description here][1]
The Manipulate has an Initialization, where the programmer can define initial values for the points. The initial values are the variable ipts in the code below. What I observe is that the definition of the Manipulate must be evaluated twice before the modified values are displayed. Suspect that I am misunderstanding some fundamental concept about how initialization works. Could someone point out how to revise the code?
On a possibly related note, what must be done so that the variables, ipts, xMin and xMax in the code below have a scope local to the Manipulate?
*Steps to reproduce the problem:*
1. Action: evaluate the cell; Response: the manipulate will appear
2. Action: edit the code; change the value of ipts (e.g. change the first point to {0.15, 0.05}
3. Action: evaluate the cell; Response, the manipulate will appear, the first point will have the **original** value {0.15, 0.35}
4. Action: evaluate the cell; Response: the manipulate will appear, the first point will have the **revised** value {0.15, 0.05}
**Question**: what must change so that manipulate will display the revised value after step 3?
myTest2 = Manipulate[
(*User points*)
posSorted = Sort[pos];
xMin = Min[posSorted[[All, 1]] ];
xMax = Max[posSorted[[All, 1]] ];
gvfuncUser = Interpolation[posSorted, InterpolationOrder -> 1];
myPlot =
Plot[gvfuncUser[x], {x, xMin, xMax},
PlotRange -> {{0, 1}, {0, 1}}, Frame -> True, ImageSize -> 400];
Grid[{
{LocatorPane[Dynamic@pos, myPlot, LocatorAutoCreate -> True,
ContinuousAction -> False] }
}]
,
(*list of controls*)
{{pos, ipts}, ControlType -> None}
(*Initialization*)
, TrackedSymbols :> {pos, ipts}
, Initialization :> (
ipts = {{0.15, 0.35}, {0.25, 0.15}, {0.50, 0.17}, {0.75,
0.18}, {1, 1}};
posSorted = {}; (*do this so that posSorted is local to this Manipulate (?) *)
gvfuncUser = {};
)
, SynchronousUpdating -> False
];
myTest2
[1]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Manipulate_Initialization.PNG&userId=894223Robert McHugh2017-10-17T04:38:31ZMike Foale's Machine Learning Flight System
http://community.wolfram.com/groups/-/m/t/1179035
## Introduction ##
A few weeks ago, I had the privilege of speaking with Michael Foale -- astronaut, astrophysicist, entrepreneur, and Mathematica fan -- about his recent work with the Wolfram Language on the Raspberry Pi. As an experienced pilot, Mike thought he could use the Wolfram Language's machine learning capabilities to alert pilots to abnormal or unsafe flying conditions. Using a collection of sensors attached to a Pi, the Wolfram Language's Classify function would constantly analyze things like altitude, velocity, roll, pitch, and yaw to determine whether the pilot might be about to lose control of the plane. You can read [Mike's User story here][1], his experience with [Mathematica on the Space Station Mir here][2]. and the full code for Mike's Imminent Loss Of Control Identification system, or ILOCI, [is here][3].
## Getting the Initial Data ##
Mike decided that the Raspberry Pi would be a good base for this project because of how easy it is to connect various sensors to the device. In his case, there were 3 sensors he wanted to read from: an accelerometer, an aero sensor attached to the tail, and a flex sensor attached to the rudder. All of these are attached via GPIO pins, which the Wolfram Language can communicate through. In Mike's case, he wrote a MathLink driver in C to do this, but since he began this project we have been pushing to make GPIO communication easier. Now, the Wolfram Language can read from sensors with [the DeviceOpen and DeviceRead functions][4]. If Mike were to re-do this project, that would have saved him quite a bit of time and debugging!
![Left: Prototype Pi and sensor setup. Right: ILOCI attached to a small plane for a test flight.][5]
Before the Classify function can tell whether current flying conditions are normal or not, it must first learn what normal is. To do this, Mike took his Pi setup on a test-flight where he occasionally forced his plane to stall, or come close to stalling (please, do not try this for yourself!). After landing, he manually separated the sensor readings into "in family" and "out of family" moments -- that is, normal flying conditions and moments where loss of control is imminent.
## Importing the Data ##
For Mike's flights, he had the Pi save data from an initial test flight to a CSV file and had Mathematica import that file to train his Classify function on. For example:
datafile = FileNameJoin[{"","home","pi","Documents","training.dat"}];
data = Import[datafile];
For convenience's sake, I've embedded this same data in a notebook attached to this post, so that you can test and manipulate this data on your own as well. This data, saved under the variable "data", was divided up by Mike into the "in family" and "out of family" periods mentioned earlier:
noloc1 = Take[data, {3500, 3800}]; (* Ground, engine off *)
noloc2 = Take[data, {3900, 4200}]; (* Ground, engine on *)
noloc3 = Take[data, {4500, 4600}]; (* Takeoff, climbing at 60 knots *)
noloc4 = Take[data, {4800, 4900}]; (* Climbing, 70 knots *)
noloc5 = Take[data, {5000, 5200}]; (* Climbing, 50 knots *)
noloc6 = Take[data, {6200, 6300}]; (* Gliding, 42 knots *)
noloc7 = Take[data, {6900, 7100}]; (* Climbing, 60 to 70 knots *)
noloc8 = Take[data, {9200, 9400}]; (* Landing *)
noloc9 = Take[data, {9300, 9400}]; (* Rolling out*)
loc1 = Take[data, {6450, 6458}]; (* Straight stall *)
loc2 = Take[data, {6480, 6484}]; (* Left stall *)
loc3 = Take[data, {6528, 6534}]; (* Right stall *)
loc4 = Take[data, {6693, 6700}]; (* Right Yaw *)
loc5 = Take[data, {6720, 6727}]; (* Left Yaw *)
You might notice that the list above doesn't cover the entire dataset. That's because some of the data is kept aside for verification, to ensure the Classify function is recognizing "in family" and "out of family" moments correctly. This is a very important part of training any artificially intelligent program! Below are some plots of the above datasets, just to get a visual feel for what the Pi is "seeing" during a flight.
ListLinePlot[Transpose[noloc4],
PlotLegends -> {"AccelerationZ", "AccelerationY", "AccelerationX",
"RudderDeflection", "ElevatorDeflection", "TailYawRelative",
"TailAngleAttackRelative", "TailAirspeedRelative"}, Frame -> True]
![Sensor readings while climbing at 70 knots][6]
ListLinePlot[Transpose[loc1],
PlotLegends -> {"AccelerationZ", "AccelerationY", "AccelerationX",
"RudderDeflection", "ElevatorDeflection", "TailYawRelative",
"TailAngleAttackRelative", "TailAirspeedRelative"}, Frame -> True]
![Sensor readings while stalled][7]
These plots give us a good idea of what happens at some specific instances, but what does the flight as a whole look like? Recall from above that takeoff begins around datapoint 4500, the first stall around 6450, landing around 9200, and the rollout ends around 9400. According to Mike, the rudder movement around 11000 is simply moving the rudder to steer the aircraft back into the hangar.
ListLinePlot[Transpose[data],
PlotLegends -> {"AccelerationZ", "AccelerationY", "AccelerationX",
"RudderDeflection", "ElevatorDeflection", "TailYawRelative",
"TailAngleAttackRelative", "TailAirspeedRelative"}, Frame -> True,
ImageSize -> Large]
![Sensor readings from whole flight][8]
## Training the Classifier Data ##
After separating the data, Mike created Rules to label these moments as "Normal", "Stall Response", "Yaw Response Left", and "Yaw Response Right"; respectively "N", "D", "L", and "R". These Rules teach Classify which patterns belong to which label, so that later on Classify can tell what the appropriate label is for incoming, unlabeled data. Note that the ConstantArray functions simply repeat the data 10 times so the "out of family" moments are not overshadowed by the "in family" ones.
normal = Join[noloc1, noloc2, noloc3, noloc4, noloc5, noloc6, noloc7, noloc8];
normalpairs = Rule[#1, "N"] & /@ normal;
down = Flatten[ConstantArray[Join[loc1, loc2, loc3], 10], 1];
downpairs = Rule[#1, "D"] & /@ down;
left = Flatten[ConstantArray[loc4, 10], 1];
leftpairs = Rule[#1, "L"] & /@ left;
right = Flatten[ConstantArray[loc5, 10], 1];
rightpairs = Rule[#1, "R"] & /@ right;
Finally, with the data segmented and labeled, Mike created a ClassifierFunction able to take live data from the sensors, then quickly tell the pilot when something is wrong and how to correct it.
classify = Classify[Join[normalpairs, downpairs, leftpairs, rightpairs], Method -> {"NeuralNetwork", PerformanceGoal -> "Quality"}]
ClassifierInformation[classify]
![Output of the ClassifierInformation function][9]
Let's use this ClassifierFunction on a couple of the data points that we set aside earlier, to be sure the ClassifierFunction is correct, and to show how a ClassifierFunction is used.
nolocVerify = Take[data, {4600, 4700}];
locVerify = Take[data, {6587, 6595}];
classify[nolocVerify]
classify[locVerify]
![Results of Mike's classifier function on untrained data][10]
Recall that the ClassifierFunction returns one of 4 labels for each data point: "N" for normal, "L" for left yaw response, "R" for right yaw response, and "D" for down response. Mike's ClassifierFunction perfectly recognizes the first verification set, and comes close to being perfect on the second set. Not bad, given how little data he had to train it with!
This use-case gives a pretty good idea of how the ClassifierFunction works, but for a more in-depth example you can watch [this video from Wolfram Research][11].
## Using the ClassifierFunction on Real Data ##
At the moment I am neither a pilot nor the owner of an airplane, so performing a live test of Mike's ClassifierFunction would be a bit challenging. Fortunately, the Wolfram Language makes it easy to take Mike's recorded data and re-run it as though the ClassifierFunction were receiving this data in real time. First, we need to import the data that Mike recorded in his test flight. We actually did this already, when we called Import on the file containing the data. Next we'll import the timing data from the test flight. This is the absolute time in seconds and microseconds from the beginning and end of the flight, so subtracting the beginning time from the end time gives us the total time of the flight. With the times and the data known, we can determine how often the Pi read in measurements on the test flight. We will use that frame time to "replay" the test flight accurately. Mike's ILOCI system records timing information that we can Import from, but again I'll include it here for the sake of convenience:
timing = {1466861802, 255724, 1466867826, 498879, 11660};
dataseconds = timing[[3]] - timing[[1]];
datausecs = timing[[4]] - timing[[2]];
frametime = (dataseconds + datausecs*1.0*^-6)/(Length[data] - 1)
Now, let's use that frame length to create an animated output of the ClassifierFunction. This goes through the whole dataset and runs at the same rate as the Pi did. If we were actually flying an airplane, this would show us what the Pi thinks about our current environment, whether our motion is "in-family" or "out-of-family".
Animate[
classify[ data[[frame]] ],
{frame, 1, Length[data], 1},
AnimationRate -> (1/frametime),
FrameLabel -> {{None, None}, {None, "Full Flight Playback"}}
]
This would take a little over 90 minutes to run, and the non-normal readings go by fairly quickly, so let's focus in on some of the more interesting sections. First, let's see the straight stall that was reserved for verification. Again, the ClassifierFunction was not trained using this set -- it is brand new as far as the Classifier is concerned.
Animate[
classify[ data[[frame]] ],
{frame, 6580, 6595, 1},
AnimationRate -> (1/frametime),
FrameLabel -> {{None, None}, {None, "Stall Playback"}}
]
![Animate of the stall playback][12]
Notice that the Classifier constantly reads the situation and updates it's classification accordingly. Next let's look at one of the verification sets where everything was normal. It should read as "N" for the entire set:
Animate[
classify[ data[[frame]] ],
{frame, 6300, 6400, 1},
AnimationRate -> (1/frametime),
FrameLabel -> {{None, None}, {None, "Normal Playback"}}
]
![Animate of the normal playback][13]
## Conclusion ##
If we go back and count, there is about 60 lines of code. That's all that was needed to create plots, animations, and a neural net-based Classifier that might one day save lives. This is what makes the Wolfram Language such a powerful choice for projects like this -- quick prototyping and a plethora of built-in functions allows users to create some truly unique projects, regardless of experience or expertise. We hope that this will inspire you to start experimenting with your own ideas with the Wolfram Language!
[1]: http://www.wolfram.com/mathematica/customer-stories/training-a-neural-network-to-think.html
[2]: http://www.wolfram.com/mathematica/customer-stories/astronaut-places-a-customer-service-call-to-wolfram-research-from-space-station-mir.html
[3]: https://github.com/cfoale/ILOCI
[4]: http://reference.wolfram.com/language/guide/UsingConnectedDevices.html
[5]: http://community.wolfram.com//c/portal/getImageAttachment?filename=PiAndPlaneSetup.png&userId=313765
[6]: http://community.wolfram.com//c/portal/getImageAttachment?filename=LinePlot1.png&userId=313765
[7]: http://community.wolfram.com//c/portal/getImageAttachment?filename=LinePlot2.png&userId=313765
[8]: http://community.wolfram.com//c/portal/getImageAttachment?filename=LinePlot3.png&userId=313765
[9]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ClassifierInfo.png&userId=313765
[10]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ClassifierResults.png&userId=313765
[11]: https://youtu.be/ce6UptPYKxI?t=20m40s
[12]: http://community.wolfram.com//c/portal/getImageAttachment?filename=StallPlayback.gif&userId=313765
[13]: http://community.wolfram.com//c/portal/getImageAttachment?filename=NormalPlayback.gif&userId=313765Brett Haines2017-09-07T18:16:06ZIncrease speed in notebook that uses Dynamic[FinancialData]
http://community.wolfram.com/groups/-/m/t/1200792
I want to make a cfd that presents an analysis of the course of stock prices obtained from FinancialData and in which the user can jump from one stock to another. But when I for instance make a notebook with the following commands
Dynamic[p]
Dynamic{FinancialData[p,{2017,1,1}]
p="GE"
Mathematica becomes awfully slow, while other programs at the same time keep running at the usual speed. Is there any remedy for this problem?
In the Windows 10 task manager I can see that Mathematica uses only about 1% of the Intel i5 processor and 92 MB of the 8 GB memory while the Mathematica Kernel uses about 5% of the processor, 288 MB of the memory and 1 to 2 Mbps of my 50 Mbps download internet connection speed.Laurens Wachters2017-10-10T12:35:43Z[✓] Choose dates dynamically with a Slider?
http://community.wolfram.com/groups/-/m/t/1195481
I would like to select a date from a list of dates using a slider, and show the chosen date right underneath the slider in the form of a date string..
Take for instance the following simple list:
list={{2000, 1, 3}, {2000, 1, 4}, {2000, 1, 5}, {2000, 1, 6}, {2000, 1, 7}, {2000, 1, 10}, {2000, 1, 11}, {2000, 1, 12}, {2000, 1, 13}, {2000, 1, 14}}
So I could for instance choose with the slider the third element of this list, which is {2000, 1,5}, and then convert this with the command DateString[DatObject[{2000, 1, 7}]] to the data string "Wed 5 Jan 2000". Now I want this date string shown underneath the slider instead of the usual number, which in this case would be 3.
The slider would be for instance:
Slider[Dynamic[m],{1,10,1}
The problem is now that Dynamic[m] is not accepted by Part. With the command
list[[Dynamic[m]]]
one gets an error message that the result from the slider cannot be used as a part specification.
How do I solve this problem? Thanks in advance for your help.Laurens Wachters2017-10-01T20:35:36Z