Certification

cancel
Showing results for 
Search instead for 
Did you mean: 

clad preparation

Greetings,

 

Attached for your reference the prep guide I think most of you have using.

 

Under Labview programming fundamentals:

Q4: which VI will generate the output shown in the graph. The answer guide says answer D is correct. Answer D generates the graph shown but

the (simpler) code in answer B also generates that same graph. I'm not seeing why the more complex code in D is supposedly the correct/better answer

 

Q7: Numeric control is set to 2.5. Which case executes. For a value of 2.5 case 2 executes. For a value of 2.51 case 3 executes. It seems that 2.5 is rounded(?)

to 2. The convention is to round 2.5 to 3. Why does Labview deviate from the widely used convention 2.5 -> 3, 2.49 ->2.4 (or 2 if the answer needs to be an integer)

 

0 Kudos
Message 1 of 12
(4,746 Views)

Ok. I guess I found the answer to question Q7: apparently the arbitrary rule is to round xx.5 to the nearest even number. In that case 2.5 rounds to 2. Rounding anything.5 down is completely new to me and I have been on the science side of things for a long time. Just tried it in Python, print(round(2.5)) indeed outputs 2.

But round(2.5) in Matlab outputs the value 3. So it seems completely arbitrary but I guess what matters is what Labview does here......very confusing.

0 Kudos
Message 2 of 12
(4,718 Views)

@ArneB wrote:

Ok. I guess I found the answer to question Q7: apparently the arbitrary rule is to round xx.5 to the nearest even number. In that case 2.5 rounds to 2. Rounding anything.5 down is completely new to me and I have been on the science side of things for a long time. Just tried it in Python, print(round(2.5)) indeed outputs 2.

But round(2.5) in Matlab outputs the value 3. So it seems completely arbitrary but I guess what matters is what Labview does here......very confusing.


It shouldn't be so arbitrary.  The IEEE Standard (IEEE-754) states to use "Banker's Rounding" (round to nearest even integer) by default because it eliminates statistical biasing.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 12
(4,667 Views)

Hi there,

 

Thanks for replying.

Rounding half to even by might be the default method but it is also stated that round half up, the only one I have ever used or seen, is widely used.

The fact alone that the IEEE standard defines five different rounding rules (and apparently there are more) with none of them being 'wrong' makes this

look pretty arbitrary to me. Rounding half to odd also eliminates biasing. But in any case, as I mentioned, considering the topic at hand all that matters is what

Labview does rounding wise. Although I can see a potential for a problem if Labview is used in conjunction with a language that rounds in a different way.

0 Kudos
Message 4 of 12
(4,608 Views)

crossrulz said it all, but here are some more details about the reason LabVIEW uses bankers rounding.

 

Different rounding may have its advantages in different situations, and maybe that is the reason different languages have different "default" rounding, but since bankers rounding is the best way to round data used for statistical analysis, I think LabVIEW has got it right.

 

I stumbled upon a discussion about it with some examples.cdf1O

 

Certified LabVIEW Architect
0 Kudos
Message 5 of 12
(4,531 Views)

Thanks everyone for the replies on the rounding part. I think I understand why Labview does it the way it does it now. Never meant to imply it was wrong. Just wasn't familiar with the various ways to round I guess.

 

That said, if anyone can give me some insight on that Q4 that would be great. Both pieces of code result in the same graph, why is the more complicated code the better choice?

0 Kudos
Message 6 of 12
(4,481 Views)

Q4: No,  the question was not which was the better code. There is only one correct answer. Look at the output side by side and you will see. Or create an indicator of both outputs and see the difference. Then see if you can understand why that happens.

Certified LabVIEW Architect
0 Kudos
Message 7 of 12
(4,467 Views)

Sorry, for the life of me I see no difference between the output of answer B vs D. And technically neither output exactly matches the output given.

 

ArneB_0-1598676373985.png

 

0 Kudos
Message 8 of 12
(4,424 Views)

Sorry, my bad. I mixed up B and C, I read to fast (thought the answer was below the letter and not mostly above). 

 

You are right that the output of B and D matches exactly. So now I don't know what to say. Maybe to trust that you know what is right now and can take the exam :). Or can there be multiple correct answers? Maybe, I don't remember.

 

 

Certified LabVIEW Architect
0 Kudos
Message 9 of 12
(4,411 Views)

@ArneB wrote:

Sorry, for the life of me I see no difference between the output of answer B vs D. And technically neither output exactly matches the output given.

 

ArneB_0-1598676373985.png

 


Look closer at the "Build Array" function in option B in the guide (not in the code you wrote).

Spoiler
CLAD_LVProg_Q4_B_JoB.PNG

The output of B is a 1D array, not a 2D array. This is because the "Build Array" function has "Concatenate Inputs" checked (right-click "Build Array" to look at/change it).

 

If the "Build Array" function didn't have "Concatenate Inputs" checked (like in the code you wrote), its output would be a 2D array, and it would be a *much* better answer than D (at least in my opinion). But as written, option B is just wrong.

 

I hope that helps!

-joeorbob

 

P.S. Here's a look at what you coded and what is in the question side-by-side:

Spoiler
CLAD_LVProg_Q4_B_explanation_JoB.PNG

 

Message 10 of 12
(4,364 Views)