I have a component of an experiment that asks participants to choose between earning 10 immediate points or a larger point amount in two weeks (points are later converted to dollar amount to provide incentive to the "larger later" choice). The later amount offered varies based on previous choices. The participant is given feedback on the choice he/she just made in the next routine. To set this up, I generated this in the code component in builder:
if key_resp_4.keys == 'left':
feedback = 'You chose 10 points immediately'
TotalNow = TotalNow + 10
add = (amount - 10)/2
amount = add + amount
elif key_resp_4.keys == 'right':
feedback = 'You chose more points in two weeks'
TotalLater = TotalLater + amount
amount = (amount + 10)/2
elif key_resp_4.keys in ['', [], None]:
feedback = 'You did not make a choice. No reward given.'
amount = amount
The "amount" variable generates a numeric value, which is updated based on a left or right response. "TotalNow" and "TotalLater" keep track of the total points earned for each condition and are displayed in the next screen. These variables are working just fine.
My problem lies within the feedback variable. I've run through the script quite a few times to better understand what is happening. For most of the trials (though not all)--regardless of whether or not I make a key press--the feedback screen prints the message designated for a non response: "You did not make a choice..." Here's the strange part, though. On the feedback screen, the "TotalNow"/"TotalLater" variables display point values indicating that I DID make a key response, even though the "feedback" text variable reports that I didn't. Further, the next trial shows the updated "amount" variable correctly.
Therefore, there seems to be some disconnect between the key response and the result shown by the "feedback" variable in the next routine. I suspect that the key response may be lagging. I suspect this because I have found that I am able to make two key responses in one trial (as evidenced by extra points appearing in the point total shown in the next routine). I have set the key response component to force the end of the routine, store only the first key, and discard any previous responses. Even with these settings, though, it is possible to make two responses.
Does anybody have ideas as to why these events are occurring? I'm puzzled by this myself. Any help is much appreciated.
-Ben
This is a rather unsatisfactory answer, but I resolved the issue first by following Jonas's advice and then by removing an extraneous loop that became obsolete through the programming of the experiment. This does not specifically answer the question of why the key response was lagging, but it seems to be working well now.
Related
I have asked a few questions related to this personal project of mine already on this platform, and this should be the last one since I am so close to finishing. Below is the link to a mock example spreadsheet I've created, which mimics what my actual project does but it contains less sensitive information and is also smaller in size.
Mock Spreadsheet
Basic rundown of the spreadsheet:
Pulls data from a master schedule which is controlled/edited by another party into the Master Schedule tab.
In the columns adjacent to the imported data, an array formula expands the master schedule by classroom in case some of the time slots designate multiple rooms. Additional formulas adjust the date, start time, and end time to be capped within the current day's 24-hour period. The start time of each class is also made to be an hour earlier.
In the Room Schedule tab, an hourly calendar is created based on the room number in the first column, and only corresponds to the current day.
I have tested the spreadsheet extensively with multiple scenarios, and I'm happy with how everything works except for the calculation time. I figured the two volatile functions I use would take some processing time just by themselves, and I certainly didn't expect this to be lightning-fast especially without using a script, but the project that I am actually implementing this method for is much larger and takes a very long time to update. The purpose of this spreadsheet is to allow users to find an open room and "reserve" it by clicking the checkbox next to it (which will consequently color the entire row red) allowing everyone else to know that it is now taken.
I'd like to know if there is any way to optimize / speed up my spreadsheet, or to not update it every time a checkbox is clicked and instead update it "manually", similar to what OP is asking here. I am not familiar with Apps Script nor am I well-versed in writing code overall, but I am willing to learn - I just need a push in the right direction since I am going into this blind. I know the number of formulas in the Room Schedule tab is probably working against me yet I am so close to what I wanted the final product to be, so any help or insight is greatly appreciated!
Feel free to ask any questions if I didn't explain this well enough.
to speed up things you should avoid usage of the same formulae per each row and make use of arrayformulas. for example:
=IF(AND(TEXT(K3,"m/d")<>$A$1,(M3-L3)<0),K3+1,K3+0)
=ARRAYFORMULA(IF(K3:K<>"",
IF((TEXT(K3:K, "m/d")<>$A$1)*((M3:M-L3:L)<0), K3:K+1, K3:K+0), ))
=IF(AND(TEXT(K3,"m/d")=$A$1,(M3-L3)<0),TIMEVALUE("11:59:59 PM"),M3+0)
=ARRAYFORMULA(IF(K3:K<>"",
IF((TEXT(K3,"m/d")=$A$1)*((M3-L3)<0), TIMEVALUE("11:59:59 PM"), M3:M+0), ))
I'm new to Stack Overflow and would just like to thank all the people that have unknowingly helped me so far. Anyhow, I'm currently writing the pseudocode for a program in which multiplication problems are generated for the user to answer. My professor wants this program to run until the user enters a sentinel value that would stop asking the user questions, and then display a report of how many questions they correctly answered and so forth.
All of that makes sense to me, and I'd probably be able to code most of that right now without struggling much. However, at the end of the direction sheet, it says "Your program should then repeat the process for another test taker". I'm not entirely sure how I'd go about doing that, since I have a 'while loop' running until the user terminates the program. The pseudocode is as follows:
BEGIN Lab 4 - Multiplication Program
Mult_Num_1 = Random positive single digit number
Mult_Num_2 = Random positive single digit number
Calculate the product
Display the multiplication problem, and sentinel value to quit
User inputs an answer
WHILE ( Answer != QUIT )
IF ( Answer == Product )
Inform user they are correct
Add 1 to Correct_Counter
Add 1 to Question_Counter
ELSE
Inform the user they are incorrect
Display the correct answer
Add 1 to Question_Counter
END IF
Calculate percentage of correct questions
Clear screen
Mult_Num_1 = Random positive single digit number
Mult_Num_2 = Random positive single digit number
Calculate the product
Display the multiplication problem, and sentinel value to quit
User inputs an answer
END WHILE
Display test report
END Lab 4 - Multiplication Program
I'd assume something needs to go after displaying the test report? I'm not entirely sure, but any help would greatly be appreciated. Thank you for taking your time to look over this!
We are implementing support for tracking of Mailgun events in our application. We reviewed the proposed event polling algorithm but find ourselves not quite comfortable with it. First, we would prefer not to discard the data that we have already fetched and then retry from scratch after a pause. It is not very efficient and leaves a door open for a long loop of retries, as it is not clear when the loop is supposed to end. Second, the "threshold age" seems to be the key to determine "trustworthiness", but its value is not defined, only a very large "half an hour" is suggested.
It is our understanding that the events become "trustworthy" after some threshold delay, let us call it D_max, when the events are guaranteed to reside in the event storage. If so, we can implement this algorithm in a different way, so that we do not fetch the data that we know are not "trustworthy" and make use of all data which have been fetched.
We would be fetching data periodically, and on each iteration we would:
Make a request to the events API specifying an ascending time range from T_1 to T_2 = now() - D_max. For the first iteration, T_1 can be set to some time in the past, "e.g., half an hour ago". For the subsequent iterations, T_1 is set to the value of T_2 from the previous iteration.
Fetch all pages one by one while the next page URL is returned.
Use all fetched events, as they are all "trustworthy".
My questions are:
Q1: Are there any problems with this approach?
Q2: What is the minimum realistic value of D_max? Obviously, we can use "half an hour" for it, but we would like to be more agile in tracking events, so it would be great to know what is the minimum value we can set it to and still reliably fetch all events.
Thanks!
1: I see no problems with this solution (in fact I'm doing something very similar). I'm also storing ID's of the events to validate I'm not inserting duplicate entries.
2: I've been working through this similar process. Right now I am testing with D_max at 10 minutes.
Additionally, While going through a testing process I'm running an additional task nightly that goes back over the entire day to validate a few things:
Am I missing existing metrics?
Diagnose if there is a problem with the assumptions I've made about D_max.
Relatively new to crystal and I've hit a bit of a snag with a formula.
I'm trying to create a formula that will report out when an RMA was received and how many. If none of the items have been received, I want it to show a message stating such, but if items from the RMA have been received I want it to return the receipt number.
Since a picture is worth a thousands words...
Current report view
I tried using an if then but I don't think you can combine strings with BAQReportResult values.
if {BAQReportResult.RMARcpt.OurReceivedQty}>0 then {BAQReportResult.RMARcpt.RMAReceipt}
After that I tried a variety of else statements but stuck here I am...
Any help is greatly appreciated!
I think you must declare a string type and then assign the value in else part.
Create a Formula and place in the Report, what has to be written in formula will be like:
stringvar text:="";
if {BAQReportResult.RMARcpt.OurReceivedQty}>0 then
text="{BAQReportResult.RMARcpt.RMAReceipt}"
else
text="There are ..."
If a customer were "silly" (being polite here) enough to try and add, as an example, 4.6 items to their basket, what would you expect to see? or how would you deal with it. Obviously, we only deal with digital quantities (our hacksaw broke last week).
There seems to be a lot of inconsistence across the web.
Amazon Rounds down (4.6->4, 1.3->1)
FireBox Rounds (4.6->5, 1.3->1)
Ebuyer ignores the input (no error)
Expansys removes the item from your basket
I'm assuming some site will show an error
Which is the best solution
Add JavaScript verification that would remove non-numeric input while the user is typing in
Implement backward solution for the situation when JavaScript is off, either display an error message or round the value but then display a message saying "your input has been adjusted"
ADDED: Also be aware that the character that separates the fractional part from the integer one differs from country to country. In US I believe it is '.', in Europe it is usually ','. If your applications is targeted at customers in different countries with varying number representation, it would make sense to implement the support for both characters in your application logic. Otherwise some users will get format error messages without knowing why - non-techie people are often unaware of this format issue.
How about validating the user input and accepting only numeric characters?
One solution would be to bring the incorrect input to the user's attention so they can correct it. Rounding can be too much of an assumption depending on the context.
Displaying an error message next to the amount something like this: "I'm sorry, we cannot supply you with 4.6 items. Please enter a whole number." ...or something along those lines.
Another solution would be to avoid displaying error messages by restricting the input field to only allow valid input. ie If you don't want 4.6 items...only allow the user to be able to type 0-9. If the user can't enter incorrect input then there is never any reason to display an error message.
Assuming you're talking about a web app here, you can limit the characters allowed in the input box.
Alternatively, IMO you could use spinner (+/-) controls to change the quantity.
I believe tesco.com does this.
The best solution according to me would be
Customer enters: 4.6
Value changes to 5 after submitting (or if 4.4, round it to 4)
Notice is displayed telling the user that only integers are valid and that the system has roundedy "your" input (4.6) to 5
One solution would be to inform the user that their selection is invalid when they tab off the edit field that's allowed them to enter the fraction.
A lesser option would be to round (down, unless you're greedy to sell 1 extra item), or to reject the input completely.
The best solution is to prevent fractions in the first place by giving them a slider or spin control to select only whole numbers.
At the end it's always safer add server side check.
So if the input it's not an integer value:
I will redirect the user to the same form.
I will set the field with the floor value (4).
I will put on top of the field a message like"This field must be an integer value. May be did you want 4 pieces of this product?"
In my opinion if your product is an shopping system then it makes sense that primary goal is to sell some items. Usually customers want to perform as less actions as possible, so the system should predict what customer could possibly want when typing incorrect inputs.
Amazon Rounds down (4.6->4, 1.3->1) - the best for me, because everything after the decimal point can be destined to some other input;
FireBox Rounds (4.6->5, 1.3->1) - as for me I don't like when someone want to sell me more than I want to buy, so better 'floor' than 'round';
Ebuyer ignores the input (no error) - then you'll sell nothing and user needs to enter some values once again;
Expansys removes the item from your basket - terrible, now I need to search for the item in the shop once again;
I'm assuming some site will show an error. - not bad but required user to retype value;
I would implemented as Amazon plus informing user that input was not fully clear and asking him to recheck the value. So if the system guessed right then user need to change nothing but if he mistyped he'll see it immediately.
Also you could log all this kind of incidents and then perform an analysis, what user typed for the first time and what was the actual count he bought. Just for curiosity...
Well, you definitely should never round up. You should not ever bill for more materials than the customer requested, no matter how inane the request.