I have two types of questions, each with 5 questions. For instance, questions A1, A2,...,A5 are about fruit and questions B1, B2,...,B5 are about vegetables.
I would like the questions to be displayed exactly once, in alternate order, randomly. For example, one participants might get the order B5, A1, B2, A3, B1, A4, B4, A5, B3, A2, while another participant might get A2, B1, A5, B3,...
The total 10 questions are currency listed within one block, but I could separate them into two blocks (by type), or into 10 different blocks, if needed to solve this issue.
I am hoping for a built-in solution in Qualtrics that doesn't require javascript (which I have never used), but if js is needed then I would appreciate some guidance on writing the proper code for this to work.
It looks like you could achieve this using Survey Flow with the "Randomizer" element. Add a randomizer to your survey flow and underneath it you can nest blocks that you want to randomize.
For example, if you have 2 blocks of 5 questions each, you could randomize the blocks such that the respondent is presented with one or both of the blocks, in whatever randomization proportion you'd like (or randomize them evenly using the "Evenly Present Elements" checkbox).
You can position the randomizer element as you would any other element in your survey flow, so if you need to combine it with branch logic it is nestable.
Related
Suppose we are getting data at the same frequency from two sources, S1 and S2, and we want to multiply them. However, S1 is noisy and we decide we want to take a rolling average three values of A before multiplying it with S2. Then we arrive at the following situation:
We have two buffers, B1 and B2, in which are stored the inputs of S1 and S2.
Some program P1 computes the rolling average from buffer B1, whose result is stored in buffer B3.
Finally program P2 multiplies the results in buffers B2 and B3 and outputs a result.
There are two different things that could be called "lag". Suppose the data arrived at time t, t+1s and t+2s.
Then we want the P1 output to be stored at time t+1s (in order for P2 to multiply it by the appropriate value from B2). So there is a lag of 1s between B1/B2 and B3 (i.e: the last value in B3 is always late by 1 compared to the last values stored in B1/B2).
But the first output of P1 is only produced at time t+2s. This is important because it informs us on when we can launch P2 for the first time. So in this sense there has to be a 2s delay on B3 compared and B1/B2.
My question is: do these different kind of lags have names? and perhaps what is the right way to deal with them?
I think the first type of lag would be referred to as Lead Time- the amount of time between when input is first given, and when any result is returned. The best may to mitigate this type of lag is seemingly to avoid starting / stopping where possible, to avoid the overhead.
The second type of lag I would just call general Latency- the delay between a cause (input) and its associated effect. What can be done to address latency depends a lot on context. Sometimes a process can be parallelized to minimize the time elapsed between start / stop. Sometimes rearranging the task ordering can allow for more efficient pipelining, reducing latency. Sometimes, there's nothing that can be done at all.
I'm newbie here.
I am currently trying to solve the problem regarding the sorting algorithm.
I will outline the situation:
we have 60 items. Variables of type A and B are written to these items. Variables A and B are stored randomly. Variables A and B have another parameter X, which indicates their material. (material may change during storage). Items are then taken one by one to another item with 10 elements, where we try to achieve the storage of 2 or 3 of the same types of variables A or B from the same material on one element. After saving the required number of variables with the same properties, they are subsequently removed from this item.
I tried to describe it as simply as possible, but maybe I should have described it with a real example.
It can be imagined as a warehouse that has 10 elements and takes from a conveyor that has a capacity of 60 elements. As soon as the warehouse has the same type of goods of the same material on one element, it dispatches the goods and releases its position.
So I want to remove the elements from the conveyor as efficiently as possible and sort them in stock according to requirements.
It occurred to me to sort by case for all options.
Thank you for all your ideas and comments. If it's not very clear, then I apologize and try to explain it differently. :)
In our current project, we need to allocate numbers of families to hosts every weekend for lunch.
Each host can serve set number of guests (host capacity).
Each family can have different number of members.
There are several rules need to be applied before family can be assigned to the host:
Some families don’t want to have lunch together (meaning it can’t be assigned to a host if that other family is already assigned to it).
A family cannot be allocated to same host for 2 consecutive weeks.
Children under 13 should be no more than 50% of host capacity.
Families with member older than 50 should be no more than 50% of host capacity.
and few more...
Each rule can have different weight of importance i.e. if first rule breaks then family to host allocation can’t take place, but the 3rd and 4th ones might be relaxed.
This kind of problem is similar to wedding plan table arrangement, but much more complex. I have researched for few days and seems like Genetic Algorithm might be the good direction. However, I'm stuck on how to model, encode the input & implement the algorithm.
I would really appreciate any advice. Thanks in advance.
Like any other genetic algorithm problem, you need to make valid/partially invalid chromosomes (scenarios which can be evaluated).
One example of a chromosome can be, W1: [{H1: F2, F3, F7}; {H2: F4, F6}; {H3: F1, F5}], W2: [{H1: F4, F3, F7}; {H2: F2}; {H3: F1, F5, F6}], ... meaning on Week 1 (W1), Host 1 (H1) is hosting families 2, 3 and 7 and so on.
This can be generated by random assignment or other methods, known as the Population Initialization
Now there needs to be a way to evaluate this chromosome. Which can be done on the basis of points defined in the question.
After this some essentials functions like crossover and mutation can be thought of.
Basic examples:
1) for mutation, families can be shifted or switched from one host to another,
2) for crossover, some weekends can be chosen from one parent, and some from the second, duplicate families can be adjusted.
Hope this helps.
I am looking to create a large list of items that allows for easy insertion of new items and for easily changing the position of items within that list. When updating the position of an item, I want to change as few fields as possible regarding the order of items.
After some research, I found that Jira's Lexorank algorithm fulfills all of these needs. Each story in Jira has a 'rank-field' containing a string which is built up of 3 parts: <bucket>|<rank>:<sub-rank>. (I don't know whether these parts have actual names, this is what I will call them for ease of reference)
Examples of valid rank-fields:
0|vmis7l:hl4
0|i000w8:
0|003fhy:zzzzzzzzzzzw68bj
When dragging a card above 0|vmis7l:hl4, the new card will receive rank 0|vmis7l:hl2, which means that only the rank-field for this new card needs to be updated while the entire list can always be sorted on this rank-field. This is rather clever, and I can't imagine that Lexorank is the only algorithm to use this.
Is there a name for this method of sorting used in the sub-rank?
My question is related to the creation of new cards in Jira. Each new card starts with an empty sub-rank, and the rank is always chosen such that the new card is located at the bottom of the list. I've created a bunch of new stories just to see how the rank would change, and it seems that the rank is always incremented by 8 (in base-36).
Does anyone know more specifically how the rank for new cards is generated? Why is it incremented by 8?
I can only imagine that after some time (270 million cards) there are no more ranks to generate, and the system needs to recalculate the rank-field of all cards to make room for additional ranks.
Are there other triggers that require recalculation of all rank-fields?
I suppose the bucket plays a role in this recalculation. I would like to know how?
We are talking about a special kind of indexing here. This is not sorting; it is just preparing items to end up in a certain order in case someone happens to sort them (by whatever sorting algorithm). I know that variants of this kind of indexing have been used in libraries for decades, maybe centuries, to ensure that books belonging together but lacking a common title end up next to each other in the shelves, but I have never heard of a name for it.
The 8 is probably chosen wisely as a compromise, maybe even by analyzing typical use cases. Consider this: If you choose a small increment, e. g. 1, then all tickets will have ranks like [a, b, c, …]. This will be great if you create a lot of tickets (up to 26) in the correct order because then your rank fields keep small (one letter). But as soon as you move a ticket between two other tickets, you will have to add a letter: [a, b] plus a new ticket between them: [a, an, b]. If you expect to have this a lot, you better leave gaps between the ranks: [a, i, q, …], then an additional ticket can get a single letter as well: [a, e, i, q, …]. But of course if you now create lots of tickets in the correct order right in the beginning, you quickly run out of letters: [a, i, q, y, z, za, zi, zq, …]. The 8 probably is a good value which allows for enough gaps between the tickets without increasing the need for many letters too soon. Keep in mind that other scenarios (maybe not Jira tickets which are created manually) might make other values more reasonable.
You are right, the rank fields get recalculated now and then, Lexorank calls this "balancing". Basically, balancing takes place in one of three occasions: ① The ranks are exhausted (largest value reached), ② the ranks are due to user-reranking of tickets too close together ([a, b, i] and something is supposed to go in between a and b), and ③ a balancing is triggered manually in the management page. (Actually, according to the presentation, Lexorank allows for up to three letter ranks, so "too close together" can be something like aaa and aab but the idea is the same.)
The <bucket> part of the rank is increased during balancing, so a messy [0|a, 0|an, 0|b] can become a nice and clean [1|a, 1|i, 1|q] again. The brownbag presentation about Lexorank (as linked by #dandoen in the comments) mentions a round-robin use of <buckets>, so instead of a constant increment (0→1→2→3→…) a 2 is increased modulo 3, so it will turn back to 0 after the 2 (0→1→2→0→…). When comparing the ranks, the sorting algorithm can consider a 0 "greater" than a 2 (it will not be purely lexicographical then, admitted). If now the balancing algorithm works backwards (reorder the last ticket first), this will keep the sorting order intact all the time. (This is just a side aspect, that's why I keep the explanation small, but if this is interesting, ask, and I will elaborate on this.)
Sidenote: Lexorank also keeps track of minimum and maximum values of the ranks. For the functioning of the algorithm itself, this is not necessary.
Since I am unsure how to phrase the question I will illustrate it with an example that is very similar to what I am trying to achieve.
I am looking for a way to optimize the amount of time it takes to perform the following task.
Suppose I have three sets of numbers labeled "A", "B", and "C", each set containing an arbitrary number of integers.
I receive a stack of orders that ask for a "package" of numbers, each order asking for a particular combination of integers, one from each set. So an order might look like "A3, B8, C1", which means I will need to grab a 3 from set A, an 8 from set B, and a 1 from set C.
The task is simple: grab an order, look at the numbers, then go collect them and put them together into a "package".
It takes awhile for me to collect the numbers, and often times an order comes in asking for the same numbers as a previous order, so I decide to store all of the packages for later retrieval; this way, the amount of time it takes for me to process a duplicate order would be dramatically reduced rather than having to go and collect the same numbers again.
The amount of time it takes to collect a number is quite long, but not as long as examining each package one by one, if I have a lot of orders that day.
So for example if I have the following sets of numbers and orders
set A: [1, 2, 3]
set B: [4, 5, 6, 12, 18]
set C: [7, 8]
Order 1: A1, B6, C7
Order 2: A3, B5, C8
Order 3: A1, B6, C7
I would put together packages for orders 1 and 2, but then I notice that order 3 is a duplicate order so I can choose to just take the package I put together for the first order and finish this last order quickly.
The goal is to optimize the amount of time taken to process a stack of orders. Currently I have come up with two methods, but perhaps there may be more ways to do things
Gather the numbers for each order, regardless whether it's a duplicate or not. I end up with a lot of packages in the end, and for extreme cases where someone places a bulk order for 50 identical packages, it's clearly a waste of time
check whether the package already exists in cache, perhaps using some sort of hashing method on the orders.
Any ideas?
There is not much detail given about how you fetch the data to compose packages etc. This makes it hard to come up with different solutions to your problem. For example, maybe existing packages could lead you to the data you need to compose new packages, although they differ in one way or another. For this there are actually dedicated hashing methods available like Locality Sensitive Hashing.
Given the two approaches you came up with, it sounds very natural to go for route 2. Hashing in the indices sounds trivial (first order is easily identified by the number 167, or string "167", right?) and therefore you would have no real drawback from using a hash. Maybe memory constraints as you need to keep old packages around. There are also common methods out there to define which packages to keep in the (hashed) cache and which ones to throw away.
Without knowing the exact timings is is not possible to be definitive, but it looks to me as if your idea 2, using some sort of hash table to store previous orders is the way to go.