If I expand the Arrays, they all look the same on the inside. Why then is the first one labeled as [Array[4]] and the last one as [Array[4], Array[4], Array[4], Array[4]]?
Thanks!
As the little i icon explains, expand an object shows its present value.
This would happen if you log the same array instance multiple times, and add items between logs.
It prints the value of the array (the collapsed line) immediately, so it shows the original value of the array.
When you expand it, it expands the current state of the object, including later additions.
Related
I would like to reference the value of an element in a dash callback. I don' want that element to be a trigger to my callback so I can't call it an input (otherwise it will trigger the input).
Is this possible or is the callback nature one in which the context is only in the inputs and outputs.
If this is not possible, is there a way to capture the callback trigger (yes ctx.triggered_id) and then return a no-op (i.e. don't do anything).
Worst case I have to rebuild 4 plots and a table for nothing if this field changes. It is essentially a category field. If the item (element of category) is empty when we trigger the callback (with another filter) I want to populate the item list with all items from the category - hence need to know current category.
If I change the category I have a different callback that sets the item selection values - that is all good.
I tried adding category as an input and returning nothing if that is the trigger (unsurprisingly this upsets things).
I could just let it run but it is spurious work for the system and not fast.
Just in case...anyone else is as "limited" as I.
dash.State is what I needed. It passes arguments without using them as triggers. So callback has Inputs, Outputs and States.
I wrote the following custom qgsfunction:
#qgsfunction(args='auto', group='Custom', referenced_columns=[])
def f1(currentfeature, feature, parent):
return "%s\n%s" % (repr(currentfeature),repr(feature))
In the config for the label I enter the following expression:
f1($currentfeature)
And here is the result:
I always believed that the $currentfeature would hold the same value as the implicitly passed argument feature, but they appear to be separate objects.
Can someone please either
confirm that they should be the same value, or
explain the difference between the two
(I also experience other odd things when executing my own custom functions, and I suspect something is not behaving as it should. Sometimes the addresss of the object changes when I zoom in or out, the address seems to cycle between af few values, and simply takes the next value in the cycle when I do any kind of zoom action. And the reason why I got to experiment with this in the first place is because I did not get the expected/correct attribute values back)
I have an inventory of 30 variables that are randomly selected. When one variable is chosen a question that corresponds with that variable should appear. Instead no matter which variable is chosen, the block at the end of the code is chosen. I even got rid of the randomizer so I could choose which variable was chosen, but the code still went all the way to the bottom. How can I fix this?
Here is a screenshot of part of the code:
The problem with your code is that none of your if blocks can ever evaluate to false. After all, Inventory does contain every of it's items. Therefore every say is executed, but everey output is replaced by the subsequent one. Due to the speed with which this happens, you can only see the last one.
A solution is to select an item into another variable and compare this variable to the list, like so:
My goal is to build a 5x5 grid of images. In the following code, row, col and rowcol were created as variables local to the sprite, and newcol, newrow and cats are global. (By the way, is it possible to tell which variables are local and which are global? It's easy to forget or make mistakes.)
The result is a 5x1 grid only, as seen here.
I am unclear as to the order of execution of these statements. Does when I start as a clone get called before or after add_cat gets called the second time? My tentative conclusion is that it gets called afterwards, yet the clone's global variables seem to contain their values from beforehand instead.
When I attempted to debug it with ask and say and wait commands, the results varied wildly. Adding such pauses in some places fixed the problem completely, resulting in a 5x5 grid. In other places, they caused a 1x5 grid.
The main question is: How to fix this so that it produces a 5x5 grid?
Explanation
Unfortunately, the execution order in Scratch is a little bizarre. Whenever you edit a script (by adding or removing blocks, editing inputs, or dragging the entire script to a new location in the editor), it gets placed at the bottom of the list (so it runs last).
A good way to test this out is to create a blank project with the following scripts:
When you click the green flag, the sprite will either say "script one" or "script two", depending on which runs first. Try clicking and dragging one of the when green flag clicked blocks. The next time you click the green flag, the sprite will say whichever message corresponds to the script you just dragged.
This crazy order can make execution incredibly unpredictable, especially when using clones.
The solution
The only real solution is to write code that has a definite execution order built-in (rather than relying on the whims of the editor). For simpler scripts, this generally means utilizing the broadcast and wait block to run particular events in the necessary order.
For your specific project, I see two main solutions:
Procedural Solution
This is the most straightforward script, and it's probably what I would choose to go with:
(row and col are both sprite-only variables)
Because clones inherit all sprite-only variable values when they are created, each clone will be guaranteed to have the correct row and col when it is created.
Recursive Solution
This solution is a bit harder to understand than the first, so I would probably avoid it unless you're just looking for the novelty:
I have a circular queue of ordered items. I want to know if an item with the value of "x" is in it.
What is the best way (algorithm) to do this?
If you can access each item by index, you can use a binary search.
If you can only see the first item, you need to pop them from the queue until the search key is lower than the key of the item you just popped. Since the queue is sorted, you can stop as soon as you know that the key can't be in the queue anymore.
[EDIT] Since you can access by index: Warp the circular queue in an object which maps it to an "array" (i.e. with a method get(index) where index runs from 0 to length-1 and which internally does ((index+start)%length).
That way, you can apply the binary search without thinking about the actual data layout.
"Best" is a subjective term and circular queues are rarely large enough to warrant binary searches so I'd opt for simplicity in the absence of information regarding queue size. The easiest way is just to start at the head and check each element until the tail (or you've passed beyond it in the order) to see if it exists.
Let's say your head variable points to the first item that will be removed and the tail points to the next place to put an item. Further assume that you're wasting an item slot to simplify the code (a trick to simplify the code and tell the difference between an empty and full queue). That means and empty queue is indicated by tail == head.
ptr = head
while ptr != tail:
if element[ptr] = searchvalue:
return true
if element[ptr] > searchvalue:
return false
ptr = (ptr + 1) % queuesize;
return false
can we traverse in the opposite direction? ie from tail to head. if so then we can design something that can utilize it. ie decide which way to proceed the search.
Since it is ordered we can guess about its position (just a guess or perhaps utilize statistics if available) and then start the full search only in direction which would get the result in less pulls
The OP I suspect, has a fixed sized circular buffer. Two search conditions occur.
One while the buffer is filling and one when the buffer is filled where wrap around has occurred and there is over writing of previous stores.
The first case is a linear search with the start 'slot' at zero and the end slot is presumably recorded/maintained.
The second case is trickier. The start slot circulates as previous stores are over written. The end slot also circulates, just one position following the start slot.
To do a linear search over these moving indexes a translation is needed to place the start slot at zero and the end slot at the buffer size.
How that algorithm works is yet to be determined.