Complicated loop function

[ac11ca]

Hi Michael,

(Sorry for the delay in replying, I went away for a few days).

Thank you for completing this revised version of the program. The inclusion of a simple tick-box choice regarding what assumptions to make about parameters will no doubt be useful for me down the track. In addition, the reorganising of the script has significantly improved my understanding of all the moving parts and boosts my confidence in potentially changing sections of the script in the future.

At this point, I really do not see any major improvements that can be made; I am thoroughly satisfied (and impressed at your ability!). The one thing I am slightly disappointed at is that I have been unable to see your experimental field behaviour script (which temporarily increases the size of a text input box) in action. Can you explain what I need to do to enable/activate this function?

Many thanks for all your help on this project,
Adrian

[Regulae]

G’day Adrian,

It’s good to know SCPT5 meets requirements. Perhaps it offers more combinations of parameter constraints than first envisaged, but there was a certain symmetry and simplicity in the “two checkbox” design. I was especially keen that it be understandable at a future date, and confining the handlers to one button may help. I also thought it good to have one version of the core calculation, to which the various repeats referred. This arrangement did not incur a significant speed cost. Given the intrinsic complexity of the core calculation, it was worth striving to make the surrounding machinery as simple and clear as possible. Variables and handlers were renamed several times in an effort to use the language to best advantage. The aim was to combine cognitive clarity with computational efficiency. SCPT4 was in a sense a stepping-stone to SCPT5.

You should be able to try the field behaviour, which could be called “field zooming”, by clicking field “Risky” (“Safe”, “Observed” “Progress” and “Output” also “zoom”). When clicked, field “Risky” should appear in the centre of the card at double its original height and textSize, unlocked and ready to edit. Moving the mouse outside “Risky” (i.e. mouseLeave) will make it “snap” back to its original place, relocking it ready for the next time it is clicked (so the field is initially locked, unlocks when zoomed, then relocks when the mouse leaves). The idea is to make small fields easier to edit, and field zooming enables some interesting card layout possibilities, especially in smaller revlets. Shift-clicking button “Field Behaviour” (bottom right of the card) lets you see the script involved. It was a bit of an experiment, and needs more work. I should mention a few things:
1. The “mouseEnter” section, which involves the selection, was a test so, if text was selected in the field when at its original size, the same text was selected after the “zoom”. This was only needed in conjunction with some scripting used in SCPT4., but not SCPT5, so it is really legacy code. I notice I left a “beep 1” in there, so I was still testing it.
2. The idea is to have the “zoomed” field visible on top of everything else on the card, i.e. its partnumber = the number of parts. There is a slight complication if the field happens to be in a group, as grouped objects have contiguous partnumbers. Say there are 50 objects on the card, and the field’s partnumber is 23, but it is in a group whose partnumbers run from 20 to 30, you can’t simply set the field’s partnumber to 50. What’s needed is setting the relayerGroupedControls property, which had slipped my mind. Anyway, that’s the issue the “group” condition is fumbling.
3. There is a motivation behind the code that makes the zoomed field flash green for 20 milliseconds. What I was exploring is providing subliminal (20 milliseconds is perhaps too long) cues to redirect the user’s attention to the zoomed field’s new location. Zooming is a sudden and significant change to the display, and it is an intriguing idea that providing subtle cues may make unusual interface behaviours seem psychologically “natural”. The use of signature “flash colours” (such as “green for zoom”) could perhaps condition the user’s expectations, giving them a greater sense of command over the system. The “flash” happens when the field expands- having the border of the field briefly flash green after zooming back down may be a useful modification to “complete the cycle”. The current implementation is really just a variant on animating a grow/shrink.
4. Something I intend to explore is making field zoom more “aware” of the borders of the card, so no side of a tall or wide field ever expands to closer than, say, 10 pixels inside the edges of the card, so it remains completely visible, and still allows you to mouseLeave in any direction. There are quite a few variations of positioning and textSize adjustments to try, but I believe preserving the proportions of the zoomed field to those it has at its “normal” size is important, as distortion could be disconcerting.

Thus there are needless complexities and pending refinements. The fields mentioned above (“Risky”, etc.) in SCPT5 should behave as indicated when clicked- if not, let me know.

I did look up Prospect Theory- most interesting. As it happens, I encountered some of the work of Tversky and Kahnemann during studies some years ago at the University of Melbourne. I was doing Philosophy, primarily mathematical logic. Their work is very relevant to informal reasoning and the cognitive biases to which it is prone.

Regards,

Michael

[ac11ca]

Hi Michael,

Cognitive biases in decision making are indeed my central interest here. Im glad to hear you also share a mild interest.

Although not vital to the program, I am curious to see this zoom function you have been describing. Unfortunately, I do not seem to be able to get it to work. When I click on fld (“Risky”, etc.) nothing happens - indeed, they are locked. Im not sure where the confusion lies. In case it matters, I am using build 610 version 2.9.0.

Cheers,
Adrian

[Regulae]

Hi Adrian,

Indeed, I believe the version is important, which I fear I overlooked. I vaguely recall that behaviors were introduced post version 3 of Rev (folks can correct me on this) so that may well be the source of the problem. I must apologise for the frustration caused. You can get things working by:

Code: Select all

set the script of fld “Risky” to the script of button “Field Behavior”

... and so on, for other fields. Thus the script will be available in the objects themselves. Thanks for bearing with me on this.

The subject I did some time ago focused on an interesting problem. The advent of computer statistics packages, like SPSS, seemed to enable researchers in the social sciences, such as Psychology, to undertake all manner of investigations. Unfortunately, there were potentially fatal pitfalls. In addition to the intrinsic difficulty people have with probabilistic reasoning, statistical terminology causes confusion. For example, the statistical sense of the word “significant” inevitably suggests the idea of “important”. Improved teaching methods are called for. A particular area I looked at was why the critical notion of statistical power was seldom taught. In a survey of 26 statistics textbooks written for social science students, few addressed the topic, and those that did relegated it to a brief section at the end, easily missed in a crowded curriculum.The cause of the problem could perhaps be found at the start, in the “Forward” or “Introduction”. Authors explained how they were acutely aware that the students were from non-mathematical backgrounds, and so sought to minimise mathematical notation, in favour of description and diagram. The motivation was laudible, but resulted in lengthy texts in which critical notions were buried or lost.

This led me to wonder whether improved mathematical notation could actually be part of the solution. The early development of “meaningful” mathematics was in Hypercard. It was encouraging, but hampered by Hypercard’s limitations. Until, one happy day, I stumbled across Revolution.

Yours,

Michael

[WaltBrown]

I didn't dive into all the calculations, but would a binary search rather than brute force search through the variable space allow faster execution - if the result space is not sensitive to hill climbing error?
Walt

[Regulae]

Hi Walt,

I confess to being so focused on getting the “crunching” repeats to work that I gave little thought to alternatives. I was content to let the core calculation “take care of itself”, and avoided any assumptions about the result space. Not only due to the intrinsic complexity of the core calculation- there was also the experimental objective of identifying those parameter combinations which, “plugged in” to the core calculation model, most closely match observation data. It seemed wise for the logic of the test at the end of the calculation to allow for the possibility that multiple parameter combinations might perform equally well. Still, I can’t say I sought alternatives. It is particularly instructive, having engaged with a problem such as this, to have someone suggest a different approach. I am investigating along the lines you indicate with great interest.

Yours,

Michael

[ac11ca]

Hi Michael,

Thanks for the tip on the coding change. The script now works and I think the intent is very useful (and, otherwise, just a neat feature).

Thanks also for your thoughts Walt. After going through this process, I am now starting to believe that others with a similar goal to mine do in fact use some sort of heuristic method, possibly, as you suggest, binary search. I am, however, not familiar with the hill climbing error.

Cheers,
Adrian

[Regulae]

Hi Adrian,

Glad to hear you’ve got the “field zooming” working. Thanks for letting me know. I should also thank Walt for his suggestions, which have set me on a path to some very interesting reading. A site I found recently was:
http://clublet.com/why?HillClimbingPitfalls
... which was quite informative.
I note in passing that the username “ac11ca”, in addition to being a quite pleasing palindrome, has the vague shape of a normal distribution, of significance to those with statistical inclinations.

Regards,

Michael

[ac11ca]

Hay Michael,

Thanks for the link. And also thanks for adding yet another meaning to my username that I hadnt previously noted.

Cheers,
Adrian

[WaltBrown]

Hi Adrian.
Hill climbing error in a search space is a kind of cognitive limitation when an algorithm thinks it is optimizing to a "best" solution (climbing up a hill) when there may be undiscovered better (taller) hills elsewhere in the search space.

Here's a page I found fun to read: http://en.wikipedia.org/wiki/List_of_cognitive_biases - while not listed there, another term for hill climbing error might be previous success bias
Walt

[ac11ca]

Cheers Walt

[ac11ca]

Hi Michael,

How are you? Ive just returned from an intensive summer school in Berlin - it's rather hot there I must say!

In the case that you are still interested... currently our program spits out a single set of paramaters that best fit the data. It was suggested to me that it might be the case that a large set of different paramaters might do a similarly well job and they pointed me towards the attached Figure (which was published in a Psych Science paper). This figure plots the predictive accuracy of a range of paramaters and thus gives the reader a fairer impression of what sorts of paramater combinations do best. My aim is to create a similar figure (Ive already emailed the author to work out what program he used to produce such an image). The important change for our program, therefore, is for it to collect/report the MSD (or might change to predictive success) for all the paramater combinations, rather than just updating the set each time it finds one with a lower MSD score. I dont think this should be a huge hassel, with any luck.

A second change I am thinking may be necessary might be a bit more work... You see, currently, we have three free paramaters: u, a=b, and d=g. I cannot plot three dimensions on a two-dimensional figure. Thus, I was thinking I could simplify and use the same version of simplified version Prospect Theory that they used in the attached paper. This simpler model does not include the paramater u (which if you look at my core calculation, only appear at the end. In fact, you can compare the simple and more complex versions of Prospect Theory at the bottom of the script of the "Model Fit" button). Thus, I would change the core calculation and this would need to be reflected in the coding so as not to adjust (or even involve!) a paramater u (of course, I would still want to keep the possibility of using the complex version of Prospect Theory, but just not for the purpose of creating this figure).

Anyway, this is where I am heading and would love your input. Please let me know if you are still interested.

Cheers,
Adrian