Using a temp variable to store max value does not work for pop operations.
If you don't care about O(n) in the push operation:
My personal approach would be to keep a linked list of sorted items.
Whenever you pop an item, compare it to the highest item in the sorted list. If it is the same, remove the highest item from the list, in addition to popping the item. If it is not, just pop the item.
This way, you should always have the highest item at the last element of the linked list, and the time for popping is O(1).
If you also need O(1) for pushing, then I'll have to pass.
You can't. A stack is unsorted, which means that you have to inspect all N values to find the highest. That alone means it is at least O(N) while "constant time " means O(1)
You can do this by managing an additional stack that holds maximums.
The algorithm would be like this:
Upon push, compare the new element to the top of the maximums stack. If not less, push it there as well. Upon pop, compare the element to the top of maximums stack. If equal, pop it from there as well.
At any given time, top of maximums stack is the maximum element.
Related
I’m trying to emulate Minesweeper in Google Sheets, and for this I want to create a second map adjacent to the first with all of the correct values already in it. To randomize bomb position, I need a list of random numbers or cells(cells would be preferable). However, I cannot figure out how to do this without ending up repeating numbers. The result would ideally be a vertical array of cell coordinates. Thank you!
Answer
The following formula should produce the result you desire:
=SORTN(FLATTEN(MAKEARRAY(10,10,LAMBDA(row,col,ADDRESS(row,col)))),20,,RANDARRAY(100),)
In =MAKEARRAY, change the first 10 to adjust how many rows to randomly choose from, or the second 10 to adjust how many columns to choose from. The value in =RANDARRAY must be equal to the product of the number of rows and the number of columns. (e.g. in the above example, 10*10=100).
Change the 20 to adjust how many randomly chosen values to return.
Explanation
=MAKEARRAY is used to generate an array of every possible row and column combination. It accepts a =LAMBDA, which in this case is just the =ADDRESS function. The first two arguments of =MAKEARRAY determine how large the array should be, which is why changing them adjusts how many rows/columns to randomly pick from.
Then, the result of =MAKEARRAY is squashed into a single column using the =FLATTEN formula.
Finally, the entire thing is sorted randomly using =SORTN combined with =RANDARRAY. =SORTN also limits the number of results that are returned dependent on its second argument, which is why changing it adjusts how many results are returned.
If you want information on how to "freeze" the value of =RANDARRAY so it doesn't recalculate each time you change something, check out this question by player0.
Functions used:
=MAKEARRAY
=LAMBDA
=ADDRESS
=FLATTEN
=SORTN
=RANDARRAY
I am working with linked lists in MIPS, and have one example that I am not sure about. It says:
write function rotate(head, a, b) that rotates elements of linked lists from position a to position b, such that if element was on position i(that belongs segment a,b) its new position is b+a-i. Numbers a,b are choosen such that a<b. Now, I don't get point of this example, because after we change elements for every position i, list will stay the same because of the formula(also it is considered that position of elements in list starts with 1 and goes to length of list).
Also, for every node in list, I think it is enough to replace only value field for corresponding indexes right(next field is not neccessary). Last sentence I am considering only if I had example where elements of list would really change(if my assumption above is correct).
I have made a bar chart which aggregates my data, but is there any way I can split each bar based on the data it is aggregating - similar to how a stacked bar chart would look?
Here is a bad artists impression (thick blue lines mine). The idea is that it's important to know from looking at the graph if I sold 5 at £1, or 1 at £5.
Ideally this would work even if the price for each item is variable, but that is not essential (eg: if there is a 'hack' with hardcoding Apple = 3, I can live with that.)
I'm also fine inputting helper columns etc, within reason, but I would want to be able to easily continue to add things to the list on the left without having to add new helper columns each time (calculated ones are fine, of course.)
Thanks in advance.
UPDATE: With thanks to Kin Siang below, I ended up implementing a slightly modified version of their solution, which I am posting here for completeness.
I added a very large (but finite) number of helper columns to the right, with a formula in each cell which would look for the nth occurrence of the item in the main list (wrapped in an iferror to make the unused cells blank).
=iferror(index(FILTER($A:$B,$A:$A=$D2),E$1,2))
Theoretically it could run out of space one day, but I have made it suitably large that this should not be an issue. It has the advantage over the other solution that I do not need to sort or otherwise manipulate the input range and can continue trickling in data to the main list and have the chart automatically update.
Yes, it is possible to display the chart in your case, however need some data transpose in order to do so, let me show you the example with dataset
Assuming this is your original data:
First sort the data by alphabet, and enter this formula in new column
=if(G39="",1,if(G40=G39,I39+1,if(G40<>G39,1)))
Next add new column for categorical purpose, by using concatenate function
="Price"&I40
In the transform data for chart purpose, enter this formula to split all price into different row, different column for different product
=sumifs($H$40:$H$47,$G$40:$G$47,$A41,$J$40:$J$47,B$40)
After that i select stack bar chart and ensure the price in under series, in case in 23 will have some problem to set price at series correctly, you can use 33 data create stack bar chart and update the data range again, it will work also
Here is the cute chart you expected, accept if help :)
*When certain fruit has less price record, it is advised to fill in 0, as the data table need in same column (see the orange price 3), although I didnot test if blank
I tried to plot arrival delay and departure delay columns separately, it's clear the distributions are different.
I would like to show them on the same plot, but whenever I try to do so, both plots became one identical shaped distribution although I'm plotting two different columns! What am I doing wrong?
Thank you for your help in advance.
You need a Departure Delay (bin) field. You can create one by selecting Departure Delay in the data pane on the left sidebar and selecting Create bin.
Once you have that new field, you can place it on the Columns shelf next to the other bin field and just put SUM([Number of Records]) on the Rows shelf — getting rid of both CNT() fields.
That should let you see both histograms.
To answer your question about why your previous approach yielded the same chart, you were binning data in both cases by the Arrival delay.
The CNT([xxx]) fields are misleading. That just counts the number of records that have a non-null value in the [xxx] field. If [xxx] always has a value, its equivalent to SUM[Number of Records]). The bin field is what matters.
I'm working on describing a feature where we want to use color to signify a positive or negative number, where negative is red, positive is black. It's basically like this:
Given I bought 2 items
Then I have returned 1 item
Then on the return receipt I should see both items and their costs
And these lines should be black
Then below that I should see the item I return and it's cost as a negative number
And that line should be red
Since Behat/Mink can't do this yet, how might I test this? And is it something that really needs to be tested? My thought is since this is the feature that describes to the developer how the site should work, if I don't put it in here, how do they know that returned items need to be shown in red?
Ideas? Thanks :)
The colors are an implementation detail that don't have a place in the scenario. The important thing is that the return receipt tells you about
The original purchase
The returned item
So I'd write the scenario as
Given I purchased two items
And I returned one of the items
When I view the return reciept
Then I should see two items were purchased
And I should see that one item was returned
Now when you product owner decides that having a returned item as red isn't sufficient, and that it needs to be in a box with 'returned' as the title, you won't have to rewrite your scenario