Delete a "row" in an array?

[altenbach]

You probably did not notice that you are responding to a thread that is 20+ years old and many things have changed since. For example we have conditional tunnels now.

Users here typically prefer functional VIs over truncated pictures. It also helps to clean up the code for clarity, e.g. try to remove all these unecessary wire bends.

From looking at your pictures, your code is quite inefficient and convoluted. Try to improve it!

[altenbach]

---

@dudenohair wrote:

Another approach is to just index the array you want to delete from in a for loop and do your "keep or toss" evaluation within the loop. 

---

Here's an equivalent, but arguably simpler version of that. Agreed?

[dudenohair]

I agree that is better.  I've never used those conditional terminals before and didn't know about them.  I was looking at the "20 year old thread" because it was a question that I had myself and I didn't like any of the answers.  The code I posted was code I am literally working on right now to get something for my application.    That's why my code wasn't "cleaned up" and I used a copy and pasted image instead of creating a VI.

Having said that, that was my first and last post to this forum.   I was trying to help look at something another way that I thought was easier. It's going to be my last post simply because of the way you berated me for posting it.    You won't have to worry about my ugly and inefficient code any more, but you will need to worry about your difficulty in dealing with others the rest of your life. 

[altenbach]

---

@dudenohair wrote:

Having said that, that was my first and last post to this forum.   I was trying to help look at something another way that I thought was easier. It's going to be my last post simply because of the way you berated me for posting it.    You won't have to worry about my ugly and inefficient code any more, but you will need to worry about your difficulty in dealing with others the rest of your life. 

---

Sorry you feel that way, but you obviously did not correctly understand how things were meant. There was no "berating" present or intended but I understand that text alone can easily be misunderstood or taken the wrong way and no amount of emoticons can fix that. If you read my post once more with an open mind, you will find my comments polite, factual, and encouraging.

I strongly encourage you to continue participating here. It's one of the best ways to learn how to become an even better LabVIEW programmer. 😄

Good luck!

[altenbach]

As a very (very!) friendly reminder, I also strongly suggest to use "built array" instead of "insert into array" for appending (or prepending) a value that has one less dimension. (scalar into 1D array, 1D array into 2D array, etc.)

"Insert into array" should be reserved for the rare case where somethings need to be inserted somewhere in the middle, shifting all higher values up in memory (very inefficient, never to be used in a tight loop!) of if you need to insert columns into a 2D array (also very inefficient because most elements need to be moved in memory).

Compare the following two fragments:

Top: we need to worry about what the default values are for the disconnected inputs. (some might first guess it prepends at index=0, for example)

Bottom: it is immediately clear what the code does. Less diagram waste.

[dudenohair]

---

@altenbach wrote:

From looking at your pictures, your code is quite inefficient and convoluted. Try to improve it!

---

I'm glad no offense was meant, but a better way to say the same thing would be:  "Try the code I posted.  I think you will agree it is more efficient and easier to follow."   

Or, if the style offends you, you could have said, "Hi new poster, thanks for your input.  However,  before posting new code, you should check out the "Style Guidelines for posting code" at link https://.... because these simple rules help improve every user's experience."

There are better ways to communicate opportunities for improvement.  I get that technical people don't often work on soft skills, but when they do, their effectiveness multiplies.   

Since my web search turned up this thread as the top link for the topic, I'm surprised the most efficient way wasn't already here after 20 years.

[altenbach]

It is unfortunate that you even found that old stale thread. There are plenty newer ones (example 1, example 2) that are better. You were right that the last old post here has gigantic room for improvement! (I even created an entry in the Rube Goldberg thread 😄 Unfortunately, your code does not qualify for that "honor" 🙂 )

Sorry for being somewhat terse with my posts. Saves me a lot of time. 😄

(One of those days I will create a macro that will insert some idle chit-chat before each reply: "Hello new user and welcome to the forum. You came to the right place. I hope you will find what you are looking for. This forum is mostly run by volunteers not employed by NI from all over the world and not all are fluent in English, leaving the possibility open for misunderstandings. If you feel offended, ask for clarification first. This is a welcoming place and we all try to do our best. One of the reasons we are graphical programmers might be that we are not very good with words.")

[billko]

---

@dudenohair wrote:

---

@altenbach wrote:

From looking at your pictures, your code is quite inefficient and convoluted. Try to improve it!

---

I'm glad no offense was meant, but a better way to say the same thing would be:  "Try the code I posted.  I think you will agree it is more efficient and easier to follow."   

Or, if the style offends you, you could have said, "Hi new poster, thanks for your input.  However,  before posting new code, you should check out the "Style Guidelines for posting code" at link https://.... because these simple rules help improve every user's experience."

There are better ways to communicate opportunities for improvement.  I get that technical people don't often work on soft skills, but when they do, their effectiveness multiplies.   

Since my web search turned up this thread as the top link for the topic, I'm surprised the most efficient way wasn't already here after 20 years.

---

Well, they aren't really "Style Guidelines for posting code" as much as general LabVIEW best practices.  And this is also going to be terse, but also just to the point, and not meant to offend.  LabVIEW best block diagram coding practices aren't just there to make sure the code you create is aesthetically pleasing.  In a nutshell, disorganized coding with lots of bent wires, misaligned subVIs, wires going behind objects, etc, are like text code with random indents.  The compiler doesn't care, but if you created text code with random indents and a developer working with your code came in yelling "Where's the person who wrote this???", I'd point to your desk and then leave for lunch so I could have some plausible deniability for whatever came next.

When posting a potential solution to a problem, the code should always be neat and well-documented.  Then the OP can concentrate on understanding the solution and not where the input of a node came from, or why stuff was coded that way.

That being said, I'm usually a bit kinder to new people on the forum.  😉  @altenbach can be a bit terse sometimes, but he always means well, and he's always willing to help.  He is a wealth of knowledge.

[dudenohair]

Alright guys.   I'm ok now.   Honestly it isn't that unexpected to get "terse" responses.  For years I have lurked "Stack Overflow" and noticed how few people get around to answering the actual question presented and prefer to berate the posters instead for some small slight that everyone else seems to know to avoid. I would never post on Stack Overflow because I know 50% of the responses would be complaining about how I posted or the people would pretend to be dumb and not answer the question because I didn't spoon feed all the tiny details about the application.  The questions on their own seem very straightforward and generic, yet people pretend they can't answer them.   A labview example would be "How do I conditionally execute code based on an input?"  The easy answer would be "Use a case structure."   But on Stack Overflow, you would get responses like "We can't help you if you don't post your code.  We aren't mind readers."  Or "Why would you ever in your right mind want to do that?  Can you tell me about what your code does and why it needs to do that?"  Or the ever popular "We would answer your question, but you didn't post that in the right forum, idiot.  Try going to the "all about case structures" thread instead of the "help" forum."

And I did use his code.  Much appreciated.

[altenbach]

Sometimes (i.e. often 😮 ) we criticize code. We never (or almost never) criticize people. 😄