BreakPoint
Rube Goldberg Code
Simple task. Read a CSV file and get the two columns, dropping the header row (seen here)
Apparently, we need to read the file twice with different delimiters and transpose setting to get a 2D array, one transposed and one not, one containing the first column and one containing both columns, delete the first row or column, transpose or not as needed, delete one column if there is more than one, then reshape to a 1D array to get each column. I am running out of breath!
Equivalent code:
@altenbach wrote:
Simple task. Read a CSV file and get the two columns, dropping the header row (seen here)
Apparently, we need to read the file twice with different delimiters and transpose setting to get a 2D array, one transposed and one not, one containing the first column and one containing both columns, delete the first row or column, transpose or not as needed, delete one column if there is more than one, then reshape to a 1D array to get each column. I am running out of breath!
Equivalent code:
@altenbach wrote:
I am scratching my head for an hour but I still have that nagging feeling that this code fragment could be simplified.
Are you suggesting that any wire branch could rename wire y to wire x? Seriously, that is a simple RELABEL of the value. A poor way to relabel the wires value but, other methods are not as demonstrative.
How else would YOU relabel a wire?
WHERE: y =x (as scope. ) LET....
I know , I think that you forgot that jarjon.
Except that wire labels are something else. Even if you have a formula node output and name it "y", then create an indicator on it, the indicator will be named "output variable", not "y". And if you show the wire label of that wire, it is initially blank.
According to my casual testing, a formula node cannot be used to change the name of a wire.
@altenbach wrote:
Except that wire labels are something else. Even if you have a formula node output and name it "y", then create an indicator on it, the indicator will be named "output variable", not "y".
The output label of a type cast is "*(type *) &x" when I tried it.
But why would you need this?
If the output is an indicator output of a VI, simply label the indicator how you want it.
If you want to use a unnamed bundler, but you want your elements labeled, wire a cluster constant.
If you want to use variant magic, well, this might actually be a decent way. Unless you start with a variant input.
I don't recall ever needing this.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
I don't recall ever needing this.
Yes, that was my point. We can label a wire manually for clarity, but otherwise the name is irrelevant.
(As mentioned much earlier, if we need to ensure that a data copy is made to work around a compiler issue, we have the "always copy" function. Any other kludge clouds the intent of the programmer and might even get optimized out by the compiler.) 😄
