Gary Rubin

That's exactly what I thought of.

Excellent "cat skinning"

Uh, oh. Ben, were you not reading the CLAD thread yesterday, or did you just feel like rattling some cages?

Edited to add link.

I always enjoy the trajectory of LAVA discussions; you never know exactly where they're going to lead.

I understand your frustration. I felt it, too when I was preparing for my CLAD exam. But I kept studying the material before I took the test. And because of that I see no ambiguity at all in either question. To me the answers to both questions are no-brainers. (D and 120,30). But I KNOW THE MATERIAL. I know how arrays and coercion works. I knew the material and I passed my CLAD years ago. That was my point. It's not so much the "right" answer as it is knowing the answer NI wants to here. And that answer is not necessarily "wrong".

I would agree with Yair, et al, here. I think that you took enough practice tests to get a feel for their language, and you therefore had a good feel for each question's intent. The intent of the question, and what the question actually says are not always the same thing, as shown by Yair's examples.

I share the opinion that D and (120,30) are the most likely answers, but not necessarily the right answers.

No. I do mean "consistent" - they're similar enough to match without breaking the code.

I think the problem in this case is that "consistent" is not a technical term and it can cause confusion. As such, it should not have been there, just like "best" should not be in there.

I see what you mean. I read that one as being the most wrong answer. In my mind, coercion dots show that data types are not consistent. I would probably used the word "compatible" where you used "consistent".

The most correct answer of the four given, IMO, is that the types are consistent.

Don't you mean inconsistent?

A coercion dot indicates that:

A) A polymorphic operation will be performed on the data

B) The data types are consistent

C) Data values are being coerced because they are out of range

D) A data buffer is created to handle data conversion

The answer they're looking for is D, right? And you're going to tell me that a data buffer is not always created?

The point would be to present the stories <snip> If you want a parallel, think of the greek mythology).

I would certainly be interested in reading that...

The good thing is that I don't need to choose a version - I have the Hebrew version, and there's only one.

Reminds me of one of my classes in college. One of my liberal arts requirements was a Roots of Western Civ. class. We read things like the Odyssey, Gilgamesh, and parts of the bible. The professor was a Classics professor who had studied ancient Greek. He disagreed with the English translation of many parts of the bible.

Well, you did basically ask me to do it and since I didn't know those verses, I even had to look it up.

Your post actually gave me an idea - a blog which would basically be a recap of all the interesting stories in the bible in bite-size pieces. This should probably be cool, because I'm guessing most people either don't know the stories or remember only twisted/partial versions of them. My inspiration for this was this blog, but I was thinking of only doing the interesting stories and of making the posts much shorter (and also of not giving any commentary).

By simply choosing a version of the bible, I think you'd be opening yourself up to lots of flaming by people who subscribe to other versions...

That said, I think it's a cool idea!

Congratulations Ben!

Why has nobody posted a "Knights who say 'NI!'" video clip yet?

Just like in the US - where the oz can measure mass *and* volume!

Thisis a song on the topic by a local kids' band...

Someone in the UK can correct me, but when I was in Wales in 1996, I seem to remember that there was odd mixing of the systems there. Dried goods and fresh produce were measured in different systems (oz. vs. kg)? And distances on roads were measured in km, but on distances on footpaths were in yards or miles? I don't remember exactly, but I recall thinking at the time that it was strange.

...but no-one directly reports to me - filling out performance reviews is for managers, not engineers

Did you just refer to yourself as an engineer? Won't they take away your physics degree for that?

Push "Watch this topic"

I was going to suggest the same.

You can then go into your settings and remove the watch.

I gotta get me one of those SSDs...

Doesn't he work for you? Can't you just go take it?

Or you could just forget about the whole budget thing and go with one of these.

I'm not particularly a purist, so if its neat, easily understood but not the quickest piece of code on the planet, then thats fine.

I wouldn't consider myself a purist either, but my current project is very performance sensitive. Also working in Matlab has made me think in terms of vectorized calculations.

Not sure what you mean by "whenever possible". If you need to "iterate" then I don't really see any other alternatives apart from "while" loops which don't have inherent capablity to dynamically terminate on the array length. Example perhaps?

I was referring mostly to the difference between your two test codes. One does an operation inside a loop, the other performs the same operation on a vector. Of course, most of the time you're using a loop, you have no choice in the matter because of the need to iterate.

That said, one example is a phase wrap on a vector. The logic is: if a>180, a = a-360. if a<-180, a=a+360. Because LV's Select does not allow the boolean input to be a vector, my first thought was to use a for loop. Instead, I was able to come up with a more efficient vectorized approach using modulos.

Intriguing question. Well. Rather than just saying "try it" I"did it".

For loop original 10000 runs = 5080 ms.

No for loop 10000 runs = 2ms

For loop with 10000 run loop normal but code loop // (2cores)) 10000 runs = 2887 ms

For loop with 10000 run loop // (2cores) and code loop // (2cores)) 10000 runs = 2 ms

Ok, I get the factor of ~2 speedup from the 5.08 seconds to the 2.887 seconds, but I'm pretty surprised at the last line. I think I would have have expected no difference, as both cores should already be fully committed by virtue of the code loop being parallelized.

And now you see why I avoid for loops whenever possible. The Boolean to 0,1 likely has an allocation associated with it, which is why you don't want to do that in a loop...

Unfortunately you can't because it uses serialised data. I've actually found very few scenarios (so far) where I can use that feature. That maybe due to how I partition my code and the type of implementations.

Oh, right. I guess the shift register would get in the way... I haven't played with that feature yet (or LV2009, for that matter).

Actually, that got me thinking. I wonder what the performance difference is between your original looped approach from a couple days ago and the unlooped one. And does that change significantly if you multithread the looped one?

Now your just being difficult...lol.

Ah, I like that one!

Especially if you're using LV9 on a multicore system and can multithread the loop.

It appears that if your own post is the last post in the topic, you cannot add another reply. Instead it becomes an edit to your previous post.

Is this a bug or a feature?

Labview is highly optimised for "for" loops. They are very efficient. Far more so than most other array primitives/operators.

No disagreement here. I still try to avoid using them if I can.

Try it.

Ideally I need to find the start and stop of all the gaps. I need separate out and save the chunk of data between the gaps.

The output of your example just provides a mask that indicated when the data is valid.

I don't think that's his desired output.

Litteraly...you don't need the for loop.

I think that only does half the job. You'd still need to look for 2 consecutive 0's.