# Certification

cancel
Showing results for
Did you mean:

Highlighted

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)

Message 1 of 12
(633 Views)
Highlighted

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.

Message 2 of 12
(605 Views)
Highlighted

@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.

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
Message 3 of 12
(554 Views)
Highlighted

Hi there,

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.

Message 4 of 12
(495 Views)
Highlighted

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.

Message 5 of 12
(418 Views)
Highlighted

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?

Message 6 of 12
(368 Views)
Highlighted

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.

Message 7 of 12
(354 Views)
Highlighted

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.

Message 8 of 12
(311 Views)
Highlighted

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.

Message 9 of 12
(298 Views)
Highlighted

@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.

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

Spoiler

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

Message 10 of 12
(251 Views)