a bunch of questions: sample/cycle count, accessing different context attributes

[David McFarlane]

Stock reminder:  1) I do not work for PST.  2) PST's trained staff 
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)


At 10/12/2011 01:28 PM Wednesday, you wrote:
>Hello experienced e-Prime hackers!
>
>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!

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.