LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serious bug in LabView 8.5 Formula Node

Hello,
 
Thought I would warn my fellow LabView programmers about a serious error in the Formula Node:
 
The problem may be encountered by anyone running a non-us LabView installation:
 
I am located in Norway, and over here we use the comma (,) as the separator in floating point numbers: So, the use 3.14 is written like 3,14.
 
The problem is that the Formula Node accepts both formats, but only the US Notation is interpreted correctly !
Example:
 
float64 x1, x2;
 
x1 = 3.14;    // Interpreted Correctly !
 
x2 = 3,14;     // Interpreted as 3: One might say this leads to problems.......
 
 
 
 
 
 


Message Edited by geirove on 06-13-2008 06:23 AM
Geir Ove
0 Kudos
Message 1 of 13
(4,099 Views)

Hi Geir,

It is not a bug.  Here is what Labview Help says about the decimal point:

"Note  The Formula Node accepts only the period (.) as a decimal separator. The node does not recognize localized decimal separators."

I realize it may be annoying, but you may need to convert the comma to decimal point before using the Formula Node.

You may do a product suggestion to add localized decimal seperators. 

RayR



Message Edited by JoeLabView on 06-13-2008 08:03 AM
0 Kudos
Message 2 of 13
(4,079 Views)


JoeLabView wrote:

Hi Geir,

It is not a bug.  ............

 The node does not recognize localized decimal separators."



Of course it is a Bug:  **Any** code that **any** compiler does not recognize, should be flagged with an error message ! I have written my share of compilers myself, and they all flag down code that is not accepted as an error.
 
Failing to do so may cause serious, expensive and very hard to trace errors.
 
Sorry, but I would expect that the NI team in their 20. year of LabView development is capable of better than this.
 
 

 
Geir Ove
0 Kudos
Message 3 of 13
(4,068 Views)
At least it is a "documented bug" !
0 Kudos
Message 4 of 13
(4,057 Views)


@geirove wrote:


@JoeLabView wrote:

Hi Geir,

It is not a bug.  ............

 The node does not recognize localized decimal separators."



Of course it is a Bug:  **Any** code that **any** compiler does not recognize, should be flagged with an error message ! I have written my share of compilers myself, and they all flag down code that is not accepted as an error.
 
Failing to do so may cause serious, expensive and very hard to trace errors.
 
Sorry, but I would expect that the NI team in their 20. year of LabView development is capable of better than this.
 

Sorry to disappoint you! It's not a bug since that statement is absolutely valid albeit useless in that context.

The Formula Node since LabVIEW 7 supports C syntax except some advanced features such as pointers. In C the comma in expressions is the sequence operator meaning it separates expressions that will be executed from left to right and the last one will actually be the result of the entire sequence expression. This is often used for the initilizer expression inside the for statement, to initilize several variables to a start value.

And the NI team really is a lot better than you think. The online help may be a bit short about the reasons why the comma is not supported as decimal point but there have been many people thinking about this before it was made like that. It was either C syntax support without localized decimal point or some homegrown syntax with localized decimal point and they went for the first.

Rolf Kalbermatter
Rolf Kalbermatter
My Blog
Message 5 of 13
(4,036 Views)

hi there

try to compile

int main()
{
 double x1, x2;
 
  x1 = 3.14;    // Interpreted Correctly !
  x2 = 3,14;     // Interpreted as 3: One might say this leads to problems.......
 
  printf("%f", x1);
  printf("%f", x2);
 
  return 0;
}
 
with MS CV++, BCC, gcc and you'll get no error message (in MS VC++ not even a warning). It's not a bug, it's c syntax support (like rolfk said)
Best regards
chris

CL(A)Dly bending G-Force with LabVIEW

famous last words: "oh my god, it is full of stars!"
Message 6 of 13
(4,006 Views)

rolfk said: Sorry to disappoint you! It's not a bug since that statement is absolutely valid albeit useless in that context.

That's right: as others have noted, the comma is the C comma or sequence operator. I'm just chiming in to note that "14" is valid because C is an expression-oriented language and "14" is an expression. Det goar!

If I were NI and had to implement C-like syntax for formula nodes, I'd make the implementation as close to C as possible.

--Marty

0 Kudos
Message 7 of 13
(3,992 Views)


chrisger wrote:
...............
with MS CV++, BCC, gcc and you'll get no error message (in MS VC++ not even a warning). It's not a bug, it's c syntax support (like rolfk said)


I understand this: But this is Labview: Who said they have to follow the same buggy path as C++ when they implemented the Formula Node Syntax?
 
They could use Java Syntax or any other syntax sensible enough to flag Errors when apropriate.
 
I have so far crated one error myself, and seen several errors in other peoples code due to this ambiguity.
 

 
Geir Ove
0 Kudos
Message 8 of 13
(3,972 Views)
geirove:
I understand this: But this is Labview: Who said they have to follow the same buggy path as C++ when they implemented the Formula Node Syntax?
 
One reason LabVIEW provides formula nodes, no doubt, is so that legacy C or C++ code can be pasted in and run with few changes needed (wiring inputs and outputs). In the instrumentation world I think legacy code will much more likely be C than anything else.  It will hardly ever be Java.  So my guess is that NI made the decision to make life as easy as possible for legacy-C-code-pasters.  They don't want to have to debug something in a formula node that's known to work in a C environment.
 
I once worked on a system where an analyst had written what was essentially C code to implement a DSP algorithm.  The algorithm had to be part of a LabVIEW application.  What a mess; not only that, the C code didn't quite work, not because the algorithm was wrong but because of programming errors.  I had to rewrite in Visual C++ for clarity and maintainability.  I kept it to the "C subset" of C++ for various reasons, which helped by accident, because a college student working with us for the summer was able to implement it in LabVIEW, using formula nodes, very quickly.  (I didn't use any comma operators, which I sometimes used to find myself doing in a fit of perversity.)
 
--Marty
0 Kudos
Message 9 of 13
(3,959 Views)


@geirove wrote:
I understand this: But this is Labview: Who said they have to follow the same buggy path as C++ when they implemented the Formula Node Syntax?



What about the sequence operator is buggy? It's a valid expression syntax element in C and used quite often althoug not so much in assignment expressions as much more in initialization expressions such as in a for loop. But in C an expression is an expression no matter if it's an initializer expression or simple the assignment part of an assignment expression.

The formula node used to have a very limited (and by far non C like syntax in the old LabVIEW days). This was a major complain by many users so they finally implemented the C like syntax in the Formula Node. But as we all know it's not possible to do it right for everybody.

In fact there is a bug here since C syntax states that the sequence expression is evaluated from left to right and the last result is the result of the entire expression. LabVIEW does use the first result as result of the entire expression which is not according to the C syntax.

The only other improvement I could see here would be if LabVIEW would issue a warning for sequence expressions in an assignment expression. But who does enable the Show Warnings option in the Error dialog???? (I know I do but most users don't even know it is there).

Rolf Kalbermatter


Message Edited by rolfk on 06-13-2008 09:09 PM
Rolf Kalbermatter
My Blog
0 Kudos
Message 10 of 13
(3,943 Views)