Wiring data through multiple frames of a Flat Sequence

[altenbach]

---

@VitekStepien wrote:

Here's the updated vi to bring everyone some joy - it's sequenceless. 

I know it's outside of the scope of the original question, but if you don't mind answering another question: when I divide or multiply a complex variable by a double, it will always show the red coercion dot to bring my attention to that. Is it really worth manually putting a conversion to complex in such trivial case? 

---

The correct way would be to eliminate all that duplicate code and use a (four iteration) FOR loop and shift registers! 4x less code!!! (easy to expand to fewer or more steps!). If you have a different problem suddenly involving 100 steps, your solution is not practical!

Dividing (or multiplying) a CDB by a DBL does NOT introduce a coercion dot because the operation is fully defined. There is no coercion if both inputs are scalars There currently is a coercion dot if you mix arrays and scalars and one input is DBL and the other CDB. This might be a bug, though.

There are some other interesting coercion dot behaviors involving complex. For example if you wire two integers to "RE/IM to complex" to form a CDB, there is no coercion dot anywhere. 😉

(more on coercion dots)

[JÞB]

Re: FSS frame vs flat frame decoration.  A Sequence frame introduces synchronization boundaries.   Like a subvi con pane or a loop iteration.  No code inside can execute until all data arrives even if all the data needed for some operations might arrive earlier.   and all data must exist for the frame, to exit before moving out.  That's data flow.  Decorations do not have tunnels or shift registers and cannot introduce unnecessary synchronization delays and lets LabVIEW do its job scheduling tasks optimally. 

Coercion dots.  For most scalar data it's ignorable....unless you get around rings or Enum type defs! When you see those dots you better check your aim! You may be shooting yourself in the foot. <caveat: one of my favorite Enums is error 0 pass 1 fail 2... multiply array elements is MAGIC then even if there are strange elements in the array >

[VitekStepien]

---

@altenbach wrote:

---

@VitekStepien wrote:

Here's the updated vi to bring everyone some joy - it's sequenceless. 

I know it's outside of the scope of the original question, but if you don't mind answering another question: when I divide or multiply a complex variable by a double, it will always show the red coercion dot to bring my attention to that. Is it really worth manually putting a conversion to complex in such trivial case? 

---

The correct way would be to eliminate all that duplicate code and use a (four iteration) FOR loop and shift registers! 4x less code!!! (easy to expand to fewer or more steps!). If you have a different problem suddenly involving 100 steps, your solution is not practical!

Dividing (or multiplying) a CDB by a DBL does NOT introduce a coercion dot because the operation is fully defined. There is no coercion if both inputs are scalars There currently is a coercion dot if you mix arrays and scalars and one input is DBL and the other CDB. This might be a bug, though.

There are some other interesting coercion dot behaviors involving complex. For example if you wire two integers to "RE/IM to complex" to form a CDB, there is no coercion dot anywhere. 😉

(more on coercion dots)

---

I could do a for loop, but the steps aren't identical so I would have to play with the varying time step - you're right that it would work great for scalability, but this is 4th order Runge Kutta, and you generally don't ever go to higher orders thus no need for scalability in this particular case. 

Thanks for the insight on coercion dots, that's really interesting what you wrote about CDB and DBL!

[altenbach]

---

@VitekStepien wrote:
I could do a for loop, but the steps aren't identical so I would have to play with the varying time step!

---

One easy solution would be to create an array of four time steps and autoindex on that array. Now you don't even need to wire N. 😉