LabVIEW vs. E-Prime

[David McFarlane]

<Lengthy rant here, if I were you I might well just pass by this one!>

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.

-- David McFarlane, Professional Faultfinder


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---