LabVIEW Equivilant to excel functions?

[billko]

For anyone who is interested in using what I call "conventional rounding," where everything greater than 0.5 is rounded up (statistically less accurate, but sometimes insisted upon by non-techies (i.e. management), here's some code I ripped from someplace here and put it in a drop-in replacement for the "Round to Nearest."  Whoever wrote this please come forward to take credit.

 

[Alain_S]

---

billko wrote:

For anyone who is interested in using what I call "conventional rounding," where everything greater than 0.5 is rounded up (statistically less accurate, but sometimes insisted upon by non-techies (i.e. management), here's some code I ripped from someplace here and put it in a drop-in replacement for the "Round to Nearest."  Whoever wrote this please come forward to take credit.

 

---

What is it that you don't like at the "Round to Nearest" vi?

Because your code reacts just the same as that one!

x.000 to x.5000 result in x

x.50001 to x.99999 result in x+1

So I'm

[Cory_K]

---

Alain S wrote:

---

billko wrote:

For anyone who is interested in using what I call "conventional rounding," where everything greater than 0.5 is rounded up (statistically less accurate, but sometimes insisted upon by non-techies (i.e. management), here's some code I ripped from someplace here and put it in a drop-in replacement for the "Round to Nearest."  Whoever wrote this please come forward to take credit.

 

---

What is it that you don't like at the "Round to Nearest" vi?

Because your code reacts just the same as that one!

x.000 to x.5000 result in x

x.50001 to x.99999 result in x+1

So I'm

---

Technically.... and I mean very technically there is a slight difference.

His example rounds either up or down depending if it is > or < than 0.5

Round to nearest will round to the nearest even integer.

So 13.5 will round up to 14

But 12.5 will round down to 12.

But of course, 13.2 will round to 13 even if it is odd.

It only applies if the decimal is exactly 0.5

I believe this is the accepted method is statistics.

Message Edited by Cory K on 08-13-2009 12:59 PM

[billko]

Oh, no - not THIS again.  Yes, it is not as statistically accurate as LabVIEW's rounding (called "banker's rounding," among other things), and I have indicated as much.  I *like* LabVIEW's rounding better, but some people (management, mostly) insist on using the old way because that's what they're used to so I made the little VI to appease the management gods...  😉

[Cory_K]

---

billko wrote:
Oh, no - not THIS again.  Yes, it is not as statistically accurate as LabVIEW's rounding (called "banker's rounding," among other things), and I have indicated as much.  I *like* LabVIEW's rounding better, but some people (management, mostly) insist on using the old way because that's what they're used to so I made the little VI to appease the management gods...  😉

---

Yes, I agree that there are uses for both cases.
I was simply pointing out that there was a difference.

I also agree that you never want to upset your boss

... dont bite the hand that feeds

[RER]

Ha Ha! The first time I ever encounterred this issue I speculated that it was a bug. Its seem that no matter where you were schooled, we were all taught to "round up" to the nearest high number  (unless you are rounding a -ve number obviously).

The rounding standard that LabVIEW uses adheres to the IEEE 754 standard. There is loads of information on the web regarding the standard, but here is a link to the wiki article.

http://en.wikipedia.org/wiki/IEEE_754-2008#Roundings_to_nearest

Best wishes,

[JÞB]

---

Jeff Bohrer wrote:

---

So Round(x,d) will impement as I missed the negate of d on the first shot

Message Edited by Jeff Bohrer on 08-13-2009 11:01 AM

---

Of course, the representation of control X should be DBL not I32!   or the function will be "pointless"