What is the current row in a list
Greg Osenbach
How do I determine what the current row in a list my experiment is using? I have been messing around with this one for hours. If anyone can point me int he correct direction, it would be most appreciated.
Thanks,
Greg
Peter Quain
looking at the text dump of your edat output, perhaps you are running
List called BlocklList, and this trial is Sample: 2. A property of
the List object is [ListName].Sample, and it is recorded here as an attribute.
*** LogFrame Start ***
Procedure: BlockProc
BlockList: 5
Value: 1
EV: 1.80000000
SD: 2.40000000
CorrectAnswer: 1
Attempts: 7
LastValue: 2.9
Type: 1.0000000o
Running: BlockList
BlockList.Cycle: 1
BlockList.Sample: 2
TrialCount: 13
Test.RTTime: 26215
Test.RT: 73
Test.RESP: 1
Test.CRESP:
*** LogFrame End ***
myrow = c.GetAttrib (BlockList.Sample)
>Checked by AVG.
>Version: 7.5.552 / Virus Database: 270.11.3/1966 - Release Date:
>22/02/2009 5:21 PM
--
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.552 / Virus Database: 270.11.3/1966 - Release Date: 22/02/2009 5:21 PM
Chris Blais
real-time for debugging you can write an inLine:
debug.print "ListName_Row=" & ListName.Sample
where ListName is the name of the list and the .sample numbers range
from 1 to the number of items in the list and they numbered in the order
in which they appear in the list.
Greg Osenbach
It is .Sample! That's the missing method I was looking for! Thanks guys!
Greg
Greg Osenbach
"Sample is not a property of the Object"
Suggestions?
My line of code:
Debug.Print "Row = " + str(c.GetAttrib(BlockList.Sample))
And:
If (c.GetAttrib(BlockList.Sample) = Lot1) Then
Lot1CE = CEValue
End If
If (c.GetAttrib(BlockList.Sample) = Lot2) Then
Lot2CE = CEValue
End If
Thanks,
Greg
Eliezer Kanal
attribute from c", or "get attribute from context". Context is sort of
the base-level storage of the entire experiment. You don't want to get
an attribute of the context, you want an attribute of BlockList. I
think you want to try
str(BlockList.GetAttrib("Sample"))
I don't have eprime on this computer, though, so I can't test that.
Good luck -
Cheers,
Eliezer Kanal
PhD Candidate, Bioengineering
Laboratory for Computational Neuroscience
University of Pittsburgh
Greg Osenbach
although that gets me an error:
GetAttrib: Missing Parameter(s)
Thanks,
Greg
Chris Blais
Hmm...I've never actually used the .sample method. Have you tried
calling it as BlockList.Sample (in the same way as you might call
Target.RT)?
Greg Osenbach
Debug.Print "Row = " + str(BlockList.Sample) just gets me an invalid property error.
Peter Quain
ah ... even though [ListName].Sample is logged in the edat file (with
the property syntax (.)), it isn't a property of the List Object.
-----------------------------------------------
The List object derives from Factor. The List has no additional
properties or methods.
See the Factor object for further information.
Properties
ActionDelay Filename Name ResetCondition TargetOffsetTime
ActionTime FinishTime OffsetTime ResetEveryRun
TargetOnsetTime
Deletion ID OnsetTime StartTime TerminateCondition
Duration LoadMethod Order Tag
Methods
AddLevel GetNextAttrib PeekAttrib SetAttribLogFlag Size
GetAttrib GetPrevAttrib Reset SetNested Terminate
GetAttibLogFlag GetProc Run SetProc
GetCurrentAttrib Load SetAttrib SetWeight
--------------------------------------------------
i spose you could add an attribute to your list(s) .. say called
'lstsample' and number sequentially.. and then grab that value
sss = [ListName].GetCurrentAttrib("lstsample")
Chris Blais
I know it's logged as BlockList.Sample in the eDat file, but yes, it
doesn't exist as a method/property of the object.
Given your code:
Lot1CE = CEValue
End If
If (c.GetAttrib(BlockList.Sample) = Lot2) Then
Lot2CE = CEValue
End If
the same purpose? For example, name a column LotValue which has "Lot1"
or "Lot2" as its value and then:
If (c.GetAttrib(LotValue) = "Lot1") Then
Lot1CE = CEValue
Elseif (c.GetAttrib(LotValue) = "Lot2") Then
End If
David McFarlane
First, you all need to go back and look at the online E-Basic Help and
look at the "Context" and "List" entries where much of this gets explained.
Second, as you will note there, List.GetAttrib is different than
Context.GetAttrib. List.GetAttrib requires that you supply both a level
number and an attribute name, whereas Context.GetAttrib takes only an
attribute name. So Eliezer's suggestion would not work because it uses
the wrong syntax. It also would not work because a List object only
knows its own attributes (columns) and nothing else.
At least Eliezer knew to submit the attribute name as a quote-enclosed
string, e.g, "Sample", which gets me to point three. As clearly
explained and illustrated in the documentation, the attribute name must
be a *string*, you cannot use a mere variable name or property. Thus,
Greg should simply have used
c.GetAttrib("BlockList.Sample") ' note the use of quotes!
in the first place.
Finally, in reference to some other postings on this topic, there is
exactly one and only one Context object created in any E-Prime program,
and it is automatically given the simple name "c". That Context object
always contains *all* the attributes active at the current time in the
program.
You all really need to take a time out and get some basic lessons in
object-oriented programming.
Regards,
-- David McFarlane, Professional Faultfinder
David McFarlane
>i spose you could add an attribute to your list(s) .. say called
>'lstsample' and number sequentially.. and then grab that value
>sss = [ListName].GetCurrentAttrib("lstsample")
Yes, even I shot my mouth off a little too soon (I was at home over
breakfast, now I made it to my work site). Peter actually has the
most serviceable answer here, although there is a slightly slicker
approach that may work. And the previous answers using ".Sample" are
not strictly correct, although it may by accident work in some
cases. Let me explain.
Suppose you have a List named List1. When you run that list, you
will find three related columns in the resulting .edat file: List1,
List1.Cycle, and List1.Sample. If you only run one cycle of List1,
*and* run in sequential order, *then* List1.Cycle will always show 1,
and List1 will always equal List1.Sample. However, if you run in
random order, List1.Cycle will still always show 1 *but* List1 will
only equal List1.Sample in the event that the "random" order turns
out to be sequential, otherwise the values in these two attributes
will differ -- List1.Sample will always show sequential values,
whereas List1 will show which random row of List1 was selected for
that iteration of the list. Finally, if you run for more than one
cycle, then, regardless of whether you use sequential or random
selection, List1.Cycle will show which cycle of the list is running,
and after cycle 1 then List1 will *never* equal List1.Sample -- i.e.,
List1.Sample will continue to increase sequentially, while List1
again shows which row of the list was selected for that iteration of the list.
Whew! So how do we summarize all that?
- The attribute "List1" shows which row of the list has been selected
for the current iteration of List1.
- The attribute "List1.Cycle" shows which repetition of List1 in in progress.
- The attribute "List1.Sample" shows how many times we have taken a
sample from List1 so far. (This attribute is always strictly
increasing, and in some cases could be used for a built-in trial
counter, though in general you would to better using your own script
variable for that.)
So, after all that, Greg could use something like
sss = c.GetAttrib("MyList")
(There are even fancier things you can to with casting functions in
case you don't know what list name will be used and want to determine
that programmatically at run time. But that is far too advanced a topic.)
But I really prefer Peter's answer, since it is a little clearer
(insofar as it relies a little less on deep understanding of E-Prime
lists and attributes) and allows for more control and flexibility.
And please, as always do not take my word for any of this! I insist
that you to construct your own demonstration programs and test this
for yourselves.
My apologies to all for not getting this right the first time, and
for once again posting a lengthy explanation,
Greg Osenbach
I will take another crack at this now and let you all know how it goes. I eventually gave up last night about midnight in frustration at nothing working how I intended it. I am sure lack of sleep may have been a factor. :)
Cheers,
Greg
David McFarlane
>I am a LabVIEW programmer
So I am curious, why would you switch to E-Prime from LabVIEW? Does
E-Prime have some advantage over LabVIEW? Or did you just get stucke
with a decree from on high?
Thanks,
Greg Osenbach
Greg
David McFarlane
>LabVIEW programing is my day job. My wife is currently working
>towards her PhD in psychometrics and her department uses E-Prime for
>running experiments. I am helping out one of her classmates with a
>project since no one in the program really knows much about
>programming and they were having a difficult time on their own.
Ah, so you did get stuck with a decree from on high :). Same here,
if I had my druthers I would still program everything in C, or
perhaps graduate to C++ or MatLab. Please post a comparison review
here once you get more experience, perhaps some of us would want to
switch to LabVIEW if we only knew it better.
Greg Osenbach
I am not sure what the price points are.. A seat of LabVIEW runs from about $2,500 for the basic package. I have no idea how that compares with E-Prime.
Are you familiar with LabVIEW then?
Greg
David McFarlane
>Well, first off, LabVIEW make it very easy for people to program
>things badly :)
LOL! I don't know that E-Prime does any better, but I defer to your judgment.
>I am not sure what the price points are.. A seat of LabVIEW runs
>from about $2,500 for the basic package. I have no idea how that
>compares with E-Prime.
Yikes! (Although I found a note from 2007 showing a "base price" of
$1200.) By comparison, if you ask you can still get a full EP1
license for $700. As for the current EP2 product, as detailed at the
PST sales site, (http://www.pstnet.com/products/e-prime/#Pricing ) a
single "Professional" license runs $1000, what I call the "base"
edition runs a mere $800 for one license, and you can get a
"run-time" license (no E-Studio hardware key) for $125. Network
licenses and quantity discounts are also available.
>Are you familiar with LabVIEW then?
As it turns out, I have been told by a user in our organization that
we have a site license for LabVIEW, so I could explore it for no
charge! Now if only I had the time to spare...
Greg Osenbach
If you ever get the urge to take a look at it, I would be more than happy to answer any questions you may have :)
Greg
Peter Quain
i thought that the key selling point of specialised stimulus
presentation software is low level routines - probably written in C
or C++ (?) - that optimise interaction with the OS (and thus its
devices) to provide millisecond precision timing accuracy for the
higher level routines that organise the stimulus properties and
collect responses. A programmatic interface to these higher level
routines makes their manipulation easy and powerful (if you can work
out where to put dots, and the like :), but it doesn't touch the OS interface.
I'm wondering whether you could be confident that standalone
applications built in C etc could provide that sort of accuracy
without a hell of a lot of testing and modification of the OS
interface routines, and then tuning them on individual machines.
Same basic question with LabView (i thought it was a data
acquisition, processing tool, with a GUI and a maths language), and
MatLab (data manipulation tool, full script interface). Can you build
stimulus presentation paradigms in these applications ..track
blanking signals properly for example? Could you check easily their
performance on different machines? We've identified some substantial
timing errors in a couple of paradigms written in C++. On the other
hand, our e-prime data from visual paradigms shows that on an
appropriate machine e-prime can perform as pst state. If you went
this way, could you trust the timing?
>No virus found in this incoming message.
>Checked by AVG.
>24/02/2009 1:35 PM
>
>
>
>--
>No virus found in this incoming message.
>Checked by AVG.
>24/02/2009 1:35 PM
--
No virus found in this outgoing message.
Checked by AVG.
David McFarlane
Peter,
> i thought that the key selling point of specialised stimulus
> presentation software is low level routines - probably written in C
> or C++ (?) - that optimise interaction with the OS (and thus its
> devices) to provide millisecond precision timing accuracy for the
> higher level routines that organise the stimulus properties and
> collect responses. A programmatic interface to these higher level
> routines makes their manipulation easy and powerful (if you can work
> out where to put dots, and the like :), but it doesn't touch the OS interface.
Well put, thank you! I agree with much of your sentiment throughout,
but allow me to attempt some counterpoint nonetheless.
> I'm wondering whether you could be confident that standalone
> applications built in C etc could provide that sort of accuracy
> without a hell of a lot of testing and modification of the OS
> interface routines, and then tuning them on individual machines.
Indeed, nor would I take for granted that PST or any other company has
done that job for us. As I recall, long ago PST itself marketed a
product called MEL ("Micro Experimental Laboratory") that was then found
to have a subtle timing error that affected some experimental results.
And even now PST does not seem competent to make sound and video work
properly under Vista, how confident can we be that their product does
not have other problems lurking in its critical timing?
As for the necessity of tuning individual machines, even PST advises
that we tune each machine individually for critical timing with E-Prime,
so they have not even relieved us of that burden. To its credit PST
provides a tool for that, their RefreshClockTest. But even then I would
not take for granted that their program works as advertised. Indeed, I
tore into the guts of their program myself, and was heartened to find
that the few lines of code that did the critical work in that vast
program implemented one of the three algorithms that I would use myself.
Only then would I consider using their test program (and even then I
rewrote three streamlined alternatives to suit my own tastes). As I
keep telling all my researchers and everyone online, *if* they care
about critical timing (not everyone has such a need) then someone in
their lab *must* thoroughly read and understand chapter 3 of the User's
Guide that comes with E-Prime. Sadly, I don't know that anyone follows
through on that.
No, buying a commercial product does not relieve any of us in any way of
the duty of understanding the underlying principles of our tools and
doing our own extensive testing of their shortcomings. The surety of
science comes not from taking the work of others for granted, but in the
growing network of continued and redundant fact-checking. Sadly, I find
that fact-checking attitude far too lacking among the research labs of
my acquaintance, and relying on a product like E-Prime helps them to
continue in their lax practices.
As I keep telling my researchers, they should never trust anyone's
software, not even mine. Yes I apply a lot of expertise and care to
guarantee the critical performance of my programs (to the dismay of my
researchers, who would generally rather that I just quickly dash off
some barely working slop), but in the end each researcher has the
responsibility to fully verify for themself the suitability of the tools
they use. (E.g., I know a student who lost 2-1/2 years of dissertation
research with paid clinical subjects because they blindly trusted an
E-Prime program from another world-renowned researcher.)
Now you do have a point that making this all work in C or the like would
still require that someone have deep understanding of the OS in order to
work around its vagaries. I keep forgetting that I did all that C
programming back in the days of DOS, before preemptive multitasking, so
my programs more or less took complete control of the processor with no
special effort. That was great. But those days are long gone. And the
systems we used back then did not have the graphics or multimedia
capabilities that we have today (though for simple text and
low-resolution graphics, for all their power I doubt that the task
presentation systems of today can perform any better than an Apple II or
a Commodore 64).
So I do have PST to thank for a product that put all the added power of
Windows machines to work for presenting behavioral tasks. And indeed,
it was I who encouraged our researchers to standardize on E-Prime,
because it really did leap-frog beyond what I could do at the time in C
and DOS. And on the whole, I continue to endorse E-Prime until I chance
upon a better product (which would please me much, I detest PST's
business practices).
But in principle, a suitable subroutine or object library in C or C++ or
C# or MatLab or whatever could provide as much facility for critical
timing as E-Prime. In fact, when you think of it, that is all that
E-Prime does anyway. Under the covers (and as anyone can see if they
peruse the online E-Basic Help as I have) E-Prime is just a dialect of
Microsoft Visual Basic with a specialized object library, and E-Studio
is just a pretty graphical "skin" or front-end over that. Moreover, if
you study the reviews as I have, you will find that E-Prime accomplishes
its timing feats only by relying on Microsoft's DirectX technology,
nothing proprietary or peculiar to E-Prime. Indeed, other products such
as DirectRT, Inquisit, and Paradigm accomplish the same feats using the
same underlying technology. Anybody practiced in DirectX could do it.
So it would not be that much of a stretch to provide a similar library
for skilled programmers to use in a language of their choosing. And if
someone wanted to add a graphical front-end for the sake of dedicated
non-programmers (who by their own inclination and admission are ill
suited to programming intricate behavioral tasks no matter how you dumb
down the programming platform, and therefore ought really to leave this
task to so many others better inclined and practiced anyway), so be it
(think Linux with user-choosable desktop environments and shells). Even
better if this were open source. Now in practice I do not know that any
such thing is available. But heck, if enough of us were just motivated
enough, we could form a consortium and make it ourselves.
And with C++ or the like we would have a much more serviceable and
well-ordered platform for building precision tools. Heck, in C we could
even use inline assembly code for critical points (as I did for some
projects in those bygone days). And we would have a much more
extensible platform -- I cannot easily extend E-Prime with my own custom
libraries as I could with C, E-Prime's PackageCall notwithstanding (I
have yet to find a non-commercial E-Prime developer who builds on that
feature).
> Same basic question with LabView (i thought it was a data
> acquisition, processing tool, with a GUI and a maths language), and
> MatLab (data manipulation tool, full script interface). Can you build
> stimulus presentation paradigms in these applications ..track
> blanking signals properly for example?
I too thought MatLab was just an analysis tool, so I was surprised when
I learned some of our researchers used it for presenting tasks, even for
fMRI. So I took a look and was amazed. Seems that a variety of
specialized Matlab modules or libraries are available for task
presentation and all sorts of other things. And it can do things that
put E-Prime to shame. Just for instance, people have asked here how to
mirror-reverse text on-the-fly in E-Prime. E-Prime has no hope of doing
any such thing. But MatLab can not only do the text mirror-reversal on
the fly, I have seen it animate the the text and make it rotate and
distort and fly across the screen, all on-the-fly, and all with just a
few function calls. That is precisely why one of our fMRI researchers
uses MatLab from their own laptop (a MacBook, if you must know) instead
of using the E-Prime system that we have set up for everyone else. I
have not looked into MatLab's timing accuracy, but ...
> Could you check easily their performance on different machines?
Yes -- the principles of a time checking program are pretty
straightforward and constant (as illustrated in PST's own
RefreshClockTest), and I have built such tools with every programming
platform I use. No problem. I would hope that everyone else does the
same ....
> We've identified some substantial timing errors in a couple of
paradigms written in C++.
... just as you. Clearly you too know how simple it is to build time
checking tools for a given platform. No big deal, it just has to be done.
> On the other hand, our e-prime data from visual paradigms shows that on an
> appropriate machine e-prime can perform as pst state.
My preliminary tests show pretty much the same, as long as we are clear
on what "PST states" -- as carefully discussed in great detail in
chapter 3 of the E-Prime User's Guide, more or less millisecond
accuracy, with occasional and unavoidable (though minimizable) lapses
due to the vagaries inherent in any modern preemptive multitasking
system. I am confident that skilled programmers could do the same with
with many other programming platforms, especially using DirectX.
So having considered all this further, yes, if I could program only for
myself, and given a suitable function or object library, then I would
still rather do everything in straight C or the like.
But I do not program for myself, and therein lies the rub. The
behavioral researchers I work with would hardly stand for the sort of
text-based and fully regular development platform that suits me; and
admittedly I find the E-Prime GUI helpful in working with these
researchers. (To be sure, as far as mating underlying text-based source
with a GUI front-end, I find that the initial designers of E-Prime
(Brandon C, I suppose this includes you) have done a masterful job,
largely through the provision of Inline objects.) And yet, it
repeatedly confounds me how researchers keep overlooking the terrific
programming capacity so masterfully given to them in the E-Studio GUI
objects and instead gravitate directly to E-Basic script. Go figure.
Peter, you sound like one of the few who actually bothers to test their
systems, and knows how to do it. Sadly, I find your attitude and
competence rare. But I would very much like to have my misgivings
proven wrong.
There, I got that off my chest. And for anybody who did not simply
throw this straight into the trash (as I might well have done myself),
my apologies for cluttering your inbox with this long rant.