Hallo,

I have an auction-task in which the participants play against the computer. The participants bet an amount of money up to 300 Cent and the computer bets a random amount. First I save both bets and devide them in order to display them in euro:

/ ontrialbegin = [values.bet_player = openended.bet.response / 100]

/ ontrialbegin = [values.bet_pc = round(rand(0,30)) / 10]

I use parallels on a mac and did there the programming. On this computer everything goes fine, but if I start the script on the computers in the lab, inquisit seems not to round the numbers. In most cases I get a floated number with lots of 9s and a 4 at the end. 

Maybe somebody of you could help me.

Thanks in advance

You need to make sure that your dev and lab machines are all running the same, up-to-date version of Inquisit.

hey!

Thanks a lot for your fast answer. On my dev machine the version is up to date and in the lab we use an online licence. The java web start should be also up to date, because it was updated last weak.

Has somebody any different suggestions?

Well, you need to realize you're dealing w/ binary (floating point) representations of real (in the mathematical sense) numbers. That's how computers do math. A consequence of this is that some real numbers cannot be expressed accurately in binary (the available bits are limited; additionally the representation to an extent depends on the given computer's type of processor); cf. https://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_conversion_and_rounding. For more info refer to any introductory text on numerical methods.

Your division forces a floating point representation thus there'll be inaccuracies. E.g. consider 1/10=0.1. However, in a binary (base 2) representation this yields an infinitely repeating fraction: 0.0001100110011001100110011001100110011001100110011...

At any finite number of bits, all you get is an approximation of the "real" 0.1. What the computer will actually have to work with is something like: 0.10000000000000001

To avoid this either

- stay within the realm of integers

- employ clever rounding, formatting, etc. See the functions reference in the Inquisit documentation for details on round(), fpart(), ipart(), format(), etc.

Regards,

~Dave

To illustrate this with a short example analogous to your use case. Suppose I have an integer(!) variable representing centimeters, but later want to present the result in meters. With integers, there are no practical precision issues -- they can be represented just fine in binary (except for really huge ones exceeding the number of available bits). Now, however, if I do a simple mathematical conversion to meters as one would do on paper, i.e., m=cm/100, I'll end up with a floating point result on the computer, i.e., representational issues, loss of precision due to the finite number of available bits. The strategy then is to never leave the realm of precise integers, but simply do a suitable string conversion on the precise integer result to display it as meters:

<values>
/ cm = 0
/ m = ""
</values>

<expressions>
/ cminm = {
        if(length(values.cm)==1)values.m=concat("0.0", values.cm);
        if(length(values.cm)==2)values.m=concat("0.", values.cm);
        if(length(values.cm)>2)values.m=concat(
        concat(substring(values.cm,0,length(values.cm)-2),"."),
        substring(values.cm, length(values.cm)-2, length(values.cm)-1))
        }
/ cminm2 = (values.cm/100)
</expressions>

<trial mytrial>
/ ontrialbegin = [values.cm=round(rand(0,99999))]
/ ontrialbegin = [expressions.cminm]
/ stimulusframes = [1=mytext]
/ validresponse = (" ")
/ branch = [trial.mytrial]
</trial>

<text mytext>
/ items = ("cm: <%values.cm%> | m(string): <%values.m%> | m(math): <%expressions.cminm2%>")
</text>

<block myblock>
/ trials = [1=mytrial]
</block>

Regards,

~Dave

thanks a lot!

I haven't had it in mind that the computer uses a binary system. Your example is really useful. Thanks again.

Cheers