I've seen this on images multiple times, and just don't get it at all. Here is the javadoc:
https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Flux.html#flatMapSequentialDelayError-java.util.function.Function-int-int-
image in question(sorry, I'm unable to show it directly)
https://projectreactor.io/docs/core/release/api/reactor/core/publisher/doc-files/marbles/flatMapSequentialWithConcurrencyAndPrefetch.svg
Can someone explain, why is there 1 red square box? Why it's internal Flux was completed so soon? Based on what (in original flux) if purple is still emitted? What am I missing?
The image is correct as far as I can tell.
What am I missing?
You seem to be assuming that the flatMapSequential() call is somehow affecting when the fluxes end, or when they emit their elements - the red flux ending after only one element and the others continuing for two. This isn't the case - this is just an example of what happens when you call flatMapSequential() on fluxes that just so happen to behave in this way.
If it helps, imagine they're 3 fluxes returning database records from a query. The green flux is subscribed to first, then it returns a result (but doesn't complete, because it's got another record to return still.) The red flux is then subscribed to, returns a result & completes (because there was only one record matching the query.) The Purple flux is then subscribed to, returns one result, then the green & purple fluxes return another result and then both complete.
In this case, if the red flux didn't complete, then the purple flux wouldn't be subscribed to until at least one of the green or red fluxes complete (since the max concurrency in this case its 2.) So picking fluxes that behave in this way for the example allows the image to be concise, as well as demonstrating both the "sequential" and the "max concurrency" elements visually.
Related
I want to draw activity diagram to test a specific phone. I have tried to start with synchronous operation on choosing 3 random phone . can you please check if I have done them correctly , just started learning this process and couldn't figure out if I have to use synchronous or loop for choosing 3 random phone as well
To that I am choosing 3 same type phone randomly for the test.
Initially I check for packaging damage - if it had damage then return to production manager
If no package damage - then open box and check for physical damage - if damage found then return to production manger
if no physical damage then test for functionality damage - if no damage then consider the product as Test passed.
The first horizontal bar is a fork node, meaning that the control flow is split into three concurrent threads. So A1, A2, and A3 are three actions that are executed in parallel. The second horizontal bar is a join node, meaning that once that all of these actions have been finished, the control flow will continue (with the first decision).
I think that this is not what you want to show: The first action "Randomly take 3 samples" already gives you three samples and you would process each one of them in the same way, so you should rather have a loop with three iterations around the part with the decisions.
In general, try distinguish between actions, objects and states - A1, A2, A3 seem to be objects and not actions, and "Test passed" is the resulting state and not an action either.
The part with the three decisions itself is fine (except that personally I like to draw the control flow either from top to bottom or from left to right, but not back - but this is a matter of taste).
Here is an introduction to activity diagrams with some good examples.
I am using opencv and openvino and am trying to figure out when I have a face detected, use the cv2.rectangle and have my coordinates sent but only on the first person bounded by the box so it can move the motors because when it sees multiple people it sends multiple coordinates and thus causing the servo and stepper motors to go crazy. Any help would be appreciated. Thank you
Generally, each code would run line by line. You'll need to create a proper function for each scenario so that the data could be handled and processed properly. In short, you'll need to implement error handling and data handling (probably more than these, depending on your software/hardware design). If you are trying to implement multiple threads of executions at the same time, it is better to use multithreading.
Besides, you are using 2 types of motors. Simply taking in all data is inefficient and prone to cause missing data. You'll need to be clear about what servo motor and stepper motor tasks are, the relations between coordinates, who will trigger what, if something fails or some sequence is missing then do task X, etc.
For example, the sequence of Data A should produce Result A but it is halted halfway because Data B went into the buffer and interfered with Result A and at the same time screwed Result B which was anticipated to happen. (This is what happened in your program)
It's good to review and design your whole process by creating a coding flowchart (a diagram that represents an algorithm). It will give you a clear idea of what should happen for each sequence of code. Then, design a proper handler for each situation.
Can you share more insights of your (pseudo-)code, please?
It sounds easy - you trigger a face-detection inference-request and you get a list/vector with all detected faces (the region-of-interest for each detected face) (including false-positive and false-positives, requiring some consistency-checks to filter those).
If you are interested in the first detected face only - then it could be to just process the first returned result from the list/vector.
However, you will see that sometimes the order of results might change, i.e. when 2 faces A and B were detected, in the next run it could still return faces, but B first and then A.
You could add object-tracking on top of face-detection to make sure you always process the same face.
(But even that could fail sometimes)
I have a pipeline in Beam that uses CoGroupByKey to combine 2 PCollections, first one reads from a Pub/Sub subscription and the second one uses the same PCollection, but enriches the data by looking up additional information from a table, using JdbcIO.readAll. So there is no way there would be data in the second PCollection without it being there in the first one.
There is a fixed window of 10seconds with an event based trigger like below;
Repeatedly.forever(
AfterWatermark.pastEndOfWindow().withEarlyFirings(
AfterProcessingTime.pastFirstElementInPane().plusDelayOf(Duration.standardSeconds(40))
).withLateFirings(AfterPane.elementCountAtLeast(1))
);
The issue I am seeing is that when I stop the pipeline using the Drain mode, it seems to be randomly generating elements for the second PCollection when there has not been any messages coming in to the input Pub/Sub topic. This also happens randomly when the pipeline is running as well, but not consistent, but when draining the pipeline I have been able to consistently reproduce this.
Please find the variation in input vs output below;
You are using a non-deterministic triggering, which means the output is sensitive to the exact ordering in which events come in. Another way to look at this is that CoGBK does not wait for both sides to come in; the trigger starts ticking as soon as either side comes in.
For example, lets call your PCollections A and A' respectively, and assume they each have two elements a1, a2, a1', and a2' (of common provenance).
Suppose a1 and a1' come into the CoGBK, 39 seconds passes, and then a2 comes in (on the same key), another 2 seconds pass, then a2' comes in. The CoGBK will output ([a1, a2], [a1']) when the 40-second mark hits, and then when the window closes ([], [a2']) will get emitted. (Even if everything is on the same key, this could happen occasionally if there is more than a 40-second walltime delay going through the longer path, and will almost certainly happen for any late data (each side will fire separately).
Draining makes things worse, e.g. I think all processing time triggers fire immediately.
Here is my problem which I am trying to solve since one complete year. With no success till end of the year. I have to seek help and a concrete solutions from the stackoverflow experts.
My problem statement:
I have been working with some design patterns which I want to trace if eulerian path exist(as shown in below gifs), programmatically. Below are the patterns and the way I wanna draw them(gifs).
What I wanna achieve:
Give the design pattern images as input. I want trace the design pattern image in a single stroke as shown in the gifs(gifs animations are just examples of how the patterns is drawn in single stroke). Once I get the x and y coordinates of the image in single stroke fashion(eulerian path). I will feed those coordinates to my program to just trace those coordinates.
Thing to be noted in the animation:
1) basically its an undetected graph (the nodes being the vertices of your shapes, the edges if exists being the strokes between 2 vertices). (eulerian path)
Here are the 15 unique shapes which I used to build the patterns with:
I have more then 400 patterns(3 patterns already shown below) and till now I am not able to find a generic solution for this. I have manually got the x y coordinates of the patterns and placed it in sequence. But that is not at all scalable.
How to trace the patterns such that each node is visited only once ?:
1st kind of pattern and the way it should be drawn:
2nd kind of pattern and the way it should be drawn:
3rd kind of pattern and the way it should be drawn:
Perhaps you can look into the traveling salesman problem if your still struggling with the above. TSP visits cities only once. And if in your case each node is a crossing for your strike-through then this might help.
Check here for the python code to look at. I've checked and the print statement looks nice and structured. Well done cMinor!
Edit based on discussion: file 1, file2, file3.
Let's set the context/limitations:
A linked-list consists of Node objects.
Nodes only have a reference to their next node.
A reference to the list is only a reference to the head Node object.
No preprocessing or indexing has been done on the linked-list other than construction (there are no other references to internal nodes or statistics collected, i.e. length).
The last node in the list has a null reference for its next node.
Below is some code for my proposed solution.
Node cursor = head;
Node middle = head;
while (cursor != null) {
cursor = cursor.next;
if (cursor != null) {
cursor = cursor.next;
middle = middle.next;
}
}
return middle;
Without changing the linked-list architecture (not switching to a doubly-linked list or storing a length variable), is there a more efficient way to find the middle element of singly-linked list?
Note: When this method finds the middle of an even number of nodes, it always finds the left middle. This is ideal as it gives you access to both, but if a more efficient method will always find the right middle, that's fine, too.
No, there is no more efficient way, given the information you have available to you.
Think about it in terms of transitions from one node to the next. You have to perform N transitions to work out the list length. Then you have to perform N/2 transitions to find the middle.
Whether you do this as a full scan followed by a half scan based on the discovered length, or whether you run the cursor (at twice speed) and middle (at normal speed) pointers in parallel is not relevant here, the total number of transitions remains the same.
The only way to make this faster would be to introduce extra information to the data structure which you've discounted but, for the sake of completeness, I'll include it here. Examples would be:
making it a doubly-linked list with head and tail pointers, so you could find it in N transitions by "squeezing" in from both ends to the middle. That doubles the storage requirements for pointers however so may not be suitable.
having a skip list with each node pointing to both it's "child" and its "grandchild". This would speed up the cursor transitions resulting in only about N in total (that's N/2 for each of cursor and middle). Like the previous point, there's an extra pointer per node required for this.
maintaining the length of the list separately so you could find the middle in N/2 transitions.
same as the previous point but caching the middle node for added speed under certain circumstances.
That last point bears some extra examination. Like many optimisations, you can trade space for time and the caching shows one way to do it.
First, maintain the length of the list and a pointer to the middle node. The length is initially zero and the middle pointer is initially set to null.
If you're ever asked for the middle node when the length is zero, just return null. That makes sense because the list is empty.
Otherwise, if you're asked for the middle node and the pointer is null, it must be because you haven't cached the value yet.
In that case, calculate it using the length (N/2 transitions) and then store that pointer for later, before returning it.
As an aside, there's a special case here when adding to the end of the list, something that's common enough to warrant special code.
When adding to the end when the length is going from an even number to an odd number, just set middle to middle->next rather than setting it back to null.
This will save a recalculation and works because you (a) have the next pointers and (b) you can work out how the middle "index" (one-based and selecting the left of a pair as per your original question) changes given the length:
Length Middle(one-based)
------ -----------------
0 none
1 1
2 1
3 2
4 2
5 3
: :
This caching means, provided the list doesn't change (or only changes at the end), the next time you need the middle element, it will be near instantaneous.
If you ever delete a node from the list (or insert somewhere other than the end), set the middle pointer back to null. It will then be recalculated (and re-cached) the next time it's needed.
So, for a minimal extra storage requirement, you can gain quite a bit of speed, especially in situations where the middle element is needed more often than the list is changed.