a bunch of questions: sample/cycle count, accessing different context attributes
fledgeling e-Prime mastah
I have a few questions that don't seem to be explained in the e-Prime
documentation, but I see that experienced e-Primer's should know how
to tacke :). BTW: I am using e-Prime 1, not 2, but I don't know if
there is much difference between the two.
The first problem is, how do I display the sample / cycle number? I
found here that you use c.getAttribute("List.sample") and the same
with cycle. However, how do you find the total number of samples and
cycles? I found a workaround for number of samples, i.e. you get
List.Order.Count, but this is a hack because apparently certain
orderings alter this number. However, the cycle count is still a
mystery for me.. any thoughts?
My bigger worry is something else, though. I have a TrialList with an
appropriate Proc performing my main experiment, and iterating over a
number of samples. In each sample the subject makes decisions that
will affect his earnings, which are basically taken as earnings from a
single, randomly chosen, round (or sample, in e-Prime terms).
Let's say my structure looks more or less like this:
MainProc:
...
TrialList
TrialProc:
.. main experiment ..
endProc
DeterminePay (inline script)
endProc
So, in the TrialProc the experiment goes on and sets an attribute in
TrialList (i.e., one of the columns) to AmountWon. Then, in the script
DeterminePay, which is one level above the experimental procedure, I
need to read in that amount and display a message saying how much the
subject earned.
I tried accessing things through TrialList.getAttribute(payingRound,
"AmountWon"), but turns out that this only allows one to access the
ORIGINAL values in the TrialList table, not the values set by the
subject during the experiment. Hence, this approach is lost, at least
I can't figure out how to make it work.
My second approach has the following structure:
MainProc:
...
DetermineRound (inline script)
TrialList
TrialProc:
.. main experiment ..
SetWinningAmount (inline script)
endProc
DeterminePay (inline script)
endProc
where I set the (random) paying round and a global attribute
WinningAmount through
c.SetAttrib("WinningAmount"), -1
in the DetermineRound script, then if the script SetWinningAmount
detects that we reached that round (i.e.,
c.GetAttrib("TrialList.sample") = payingRound) it sets WinningAmount
to the value won in that sample. Finally, the script DeterminePay
tries to read in the WinningAmount attribute and display it.
The problem with this second solution is that the attribute
WinningAmount is visible in both MainProc and TrialProc, but changes
made within TrialProc are not visible in MainProc; in C++ terms, it
seems as if the context is passed to TrialProc by value and not by
reference :).
I have seen many times that people were somehow able to determine
subject pay at the end, so does anyone know a workaround for this? If
everything fails, I can read this manually at the end of the
experiment from the data recorded by e-Prime, but being able to code
it up would be much preferred :).
Thanks in advance!
David McFarlane
takes any and all questions at
http://support.pstnet.com/e%2Dprime/support/login.asp , and they
strive to respond to all requests in 24-48 hours -- this is pretty
much their substitute for proper documentation, so make full use of
it. 3) If you do get an answer from PST Web Support, please extend
the courtesy of posting their reply back here for the sake of others.
That said, here is my take...
I see two questions here: (1) How to find the sum of the Weights in
a List (which I gather is what you mean by "total number of samples
and cycles")? (2) How to pass a value to Procedures at the same or
higher working/logging levels? And the answers remain the same for
EP1 or EP2. So...
(1) Well, based on both my own experience and information from
Brandon Cernicky (one of the architects of E-Prime), E-Prime has no
facility for providing the sum of Weights of a List; in fact, EP does
not even have a facility for reading any of the individual Weight
values. So you can only resort to a workaround, as outlined by
Brandon himself long ago at
http://support.pstnet.com/forum/Topic1244-5-1.aspx : create an
attribute in the List to mirror the Weight values. Your program
could then sum those mirrored values, etc. Of course, that puts the
burden upon you to make sure that whenever you change a weight value
you also change the mirrored value in the List.
So let me here propose an alternative workaround that occurred to me
just now. Although EP does not have a List.GetWeight method, it does
have a List.SetWeight method. So just reverse Brandon's advice: Add
a normal List attribute where you enter the intended weights, and
then use inline code to set the List Weights using the "mirrored"
values at runtime. That should be interesting.
(2) This question comes up again and again and again (even this week
already), and the answer is simple: You need to study Chapter 4
("Using E-Basic") of the User's Guide that came with E-Prime, and use
a global variable. But I will elaborate a bit this time.
First, this has nothing to do with whether or not the "context is
passed to TrialProc by value and not by reference". Rather, you
simply misunderstand the concept of the EP "Context", not surprising
because PST does such a poor job of explaining this (although you
could start again with Chapter 4 of the User's Guide). Contrary to
common impressions, Context attributes are *not* variables. Only
variables are variables. And attributes propogate only downward to
lower branches off of the same Procedure, they do *not* propogate
upward or "sideways", not even to the next iteration of the same
Procedure (because to do the next iteration you must first exit the
Procedure, pop up a level, and then push down into the Procedure again).
So that is the long way of saying that you want to use a global
variable for this, not an attribute, and you will learn about that in
Chapter 4. Attributes have an entirely different purpose, although I
do not know how to describe that at the moment so this will have to suffice.
-- David McFarlane, Professional Faultfinder
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." (Richard Feynman,
Nobel prize-winning physicist)
fledgeling e-Prime mastah
some tutorials, like the E-Primer and such, which unfortunately don't
talk much about the coding part of it. Also, since coding ability is a
bit limited (like that 'you can't find the sum of weights' part), it
seems to me that one is doomed if he wants to do something that E-
Prime architects did not think of, even though most people would be
happy with it. It's a generic problem, so do not think of me dissing E-
Prime, it does have great features.
I found on PST website that you can access .sample and .cycle
attributes, but they never mentioned the totals of those; in fact,
they hardcoded theirs in the examples provided on the website, which
is very peculiar. Is there any reason why one would not allow you to
check the bounds of an array?
Regarding attributes, I simply don't understand why you would have
attributes.. Chapter 4 doesn't touch that very much, apart from saying
that attributes are logged by default, which is what I want. From the
code that I studied while writing my own thing, they seemed like
global variables and were used like normal variables, actually.
Similarly, accessing the elements of a List is done through
attributes, so that compounds the issue for me, suggesting that
somehow e-Prime's work horse is attributes, not variables.
Anyways, your solution is very good and I will put it to use as soon
as I can. Thanks a bunch!
Michiel Spape
Just to say, sorry about the lack of coding bits and bops in the E-Primer, we'd been working to extend that, but with a target audience of students without *any* coding experience, and a limited amount of time, there's so much you can do. Secondly, I find that, unlike you, the "coding ability" in E-Prime is not limited at all, unless you want to do awfully cool stuff, like accessing databases, 3d graphics, whathaveyou, which is generally outside the scope of psychologists. If you want, and I had such a phase as well, it's really rather easy to do your whole experiment in inline, using canvas, loops, etc. At that point, it becomes quite clear why one would use attributes at all: it provides a lot of clarity, not only for yourself, but also for others. Tons of code with somewhere saying somewhere something along the lines of Fixationduration = currentTrial[reorder[trialnum]].FixDur is mindboggling.
2p.
Best,
M
(and I think you're welcome to 'disrespect' the mighty e(vil)-prime all you want!)
Michiel Spapé
Research Fellow
Perception & Action group
University of Nottingham
School of Psychology
www.cognitology.eu
--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-p...@googlegroups.com.
To unsubscribe from this group, send email to e-prime+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.
This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.
This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
David McFarlane
>Is there any reason why one would not allow you to check the bounds
>of an array?
For that, use the LBound() and UBound() functions -- see the
"Arrays", "LBound", and "UBound" topics in the E-Basic Help facility
(which serves as the E-Basic programming reference), or read up on
arrays in any available reference on Microsoft Visual Basic for
Applications, of which E-Basic is a derivative. By comparison,
List.Size returns the number of levels (rows) in a List (and thus I
suppose acts like the size of an array), but this does not take into
account the Weights. Each List has an associated Order object, and
Order objects have a Count property (as you have already observed),
but I cannot even begin to describe how Order objects work.
Again, Lists are *not* arrays, just as attributes are *not*
variables. They each have distinct uses and behaviors.
>Regarding attributes, I simply don't understand why you would have
>attributes..
I am still working on a definitive answer to that, stay tuned...
In the meantime, please look at my posts at
http://groups.google.com/group/e-prime/browse_thread/thread/5425e03968cab428
and
http://groups.google.com/group/e-prime/browse_thread/thread/b0ce54870b723fc3
for some very general introductory guidance.