Odd behavior with Error In for Scan From String function

[Dave_Thomson]

I'm probably just missing something simple, but this behavior suprised me.

I'm using LV 2013 32 bit on W7, 64bit.

The attached VI shows the problem, and is shown in the image as well:

First run the program, with some value (such as 5.43) in the string and NO error.  Then check the Error Boolean, and finally while it all is still running, change the string value.  (In the screen shot I changed it to 56.22.)  The error in to the Scan From String function prevents it from analyzing the string, as I would expect.  But the "output 1" retains the previous value of 5.43!  I would expect it to go to the default value of 0.  I see no mechanism for how Scan From String can be remembering its previous value.  Does anyone understand why it behaves this way?

I tried wiring the "default value 1" input with a 0, and then it behaves as expected.  When there is an error input, I get the default value I specified.  Makes sense.

By why does it remember a previous value when there IS an error in?  I would expect it to use the "default" default, which is 0.

Thanks,

   DaveT

[Darin.K]

I have reported a similar issue involving errors generated inside the node as opposed to fed into the node.  Either way the result is that the location in memory pointed to by the output terminal is not being updated in this case.  Since that location is reused nicely by the compiler inside your loop you will see that last value which successfully made it there.  Otherwise you would probably see garbage.  In my case, I had a default value wired, it was still ignored when an error occurred.

The response to my report to date is "That is interesting".  I managed to get them to fix similar wonkiness with Unflatten From String, hopefully this will eventually be resolved as well.

[WillMck]

Darin.K, 

I've attempted to reproduce the issue referenced here using LabVIEW 2014 SP1. When wiring a default value to the Scan From String Function and after the error executes, the function does return the value that is wired to the default input. So along those lines, I have not been able to reproduce that specific error. However, when the default input is not wired to the input of the Scan From String function, I was able to view the behavior described in the first post. When the error occurs, the scan from string function doesn't actually execute and the default value of 0 isn't actually processed. Thus, the indicator retains the previous value. 

Regards, 

[Dave_Thomson]

Will,

    Thanks for duplicating this.  Sorry if it was unclear, but I intended to convey that only when the default is NOT wired and an error goes into the function does the function output the previous value, unrelated to its current execution.  So you did indeed fully replicate the issue as I saw it.

Regards,

    DaveT

[Darin.K]

For example, in LV2014SP1: error out but not default out.  Same issue as DaveT.

[AristosQueue (NI)]

a) We are fixing the bug so that any time the node returns an error then the outputs will be the default values. Even though this also could introduce runtime issues to existing code, it is in a case where the error is already set and most code on error skips downstream work based on the scan, so we believe the risk of breaking user code is smaller.

The change was made in LabVIEW 2015 SP1 and will be in LV 2016.

b) We are not changing the correct behavior when scanning the string "2+2" and parsing a complex number. The request was that "2+2" should to parse as "2+0i" and leave "+2" as the remaining characters. This is not a bug in our opinion. LabVIEW uses the same scan priority rules as several other programming language libraries, and these do not include precedence order for operators -- it is a simple greedy algorithm so that results of the scan are predictable to users reading the string (even if those results are not what the user would have preferred to occur).  If "2+2" can parse as "2+0i" and leave "+2" unscanned, then "2+2i" could parse as one value "2+2i" or two values "2+0i" and "0+2i"; there are numerous other ambiguous cases.

[Darin.K]

---

@AristosQueue (NI) wrote:

b) We are not changing the correct behavior when scanning the string "2+2" and parsing a complex number. The request was that "2+2" should to parse as "2+0i" and leave "+2" as the remaining characters. This is not a bug in our opinion. LabVIEW uses the same scan priority rules as several other programming language libraries, and these do not include precedence order for operators -- it is a simple greedy algorithm so that results of the scan are predictable to users reading the string (even if those results are not what the user would have preferred to occur).  If "2+2" can parse as "2+0i" and leave "+2" unscanned, then "2+2i" could parse as one value "2+2i" or two values "2+0i" and "0+2i"; there are numerous other ambiguous cases.

---

So by this logic since 3. can parse to 3 and 14159 can parse to 14159 it is ambiguous to scan '3.14159' to a DBL value since it is abiguous.  You could have 3. followed by 14159 or 3 followed by .14159.  This is no more or no less 'ambiguous' than the complex case as far as lexical analysis is concerned, you gave the answer in your post, however:

You specifically call the method 'greedy' yet your example for an ambiguous result in the complex case is a result of a lazy match.  The same simple greedy algorithm that handles floats can handle complex values just as easily with the right specs.  You choose '#.#' over '#' or '#.', likewise you choose '#+#i' over '#'.

Perhaps you are using 'greedy' in the sense that no backtracking is allowed.  If that were the case then it would indeed be a problem.  If there is no going back once you've eaten the +/- between the real and imaginary parts that would be a problem  But, this would also be a problem for floats since you could likewise start an exponent but not finish, say '1E+'.  This does not cause any problem, '1' matches and the remainder is 'E+'.  Therefore I conclude that backtracking is permitted.  In this case there is no problem to match complex values.

I would totally buy that NI has better things to fix than this, and that what seems simple to me is complicated by the fact that the actual code to handle complex values is a band-aid and not a first-class citizen of a well-written library.  I will also buy that NI is happy to be no more incorrect than some unspecified number of unnamed libraries.  What I have trouble accepting is that the current behavior is correct, or consistent with how other data types are handled.  I do not see a similar example for floats:  when can string1 be an acceptable match yet string1+string2 fail?  (For complex '2' is fine '2+2' is bad, when is this the case for any other numeric type)?

[Bob_Schor]

Darin,

     I never had a formal course on Compiler Theory, but I think the idea is that one can define a float as <optional sign><0 or more digits><optional fractional part> where <optional fractional part> is <.><0 or more digits>.  With this, 3.14159 is unambiguously nearly Pi, while 3. 14159 or 3 .14159 parse as two numbers (both have 3, but 14159 >> .14159).  The parsing rules for complex numbers are a little more complicated and may have to involve "giving back", as it's the appearance of the imaginary "unit" that distinguishes 2 + 2i from 2 + 2.  You also have to contend with 2i + 2, I suppose (and how about 2 i + 2?  Glad I don't write parsers ...).

Bob Schor

[Darin.K]

This is not really parsing, it is step 0 of parsing which is lexical analysis or tokenizing.  What you have are rules which make up what we would call a 'context free grammar'.  Like most jargon, there is an important element, in this case context (or lack thereof).   As soon as you call '3.14159' Pi you are using context, all we are allowed to have is a simple set of rules to describe a language.

Take an overly simple set of rules for a float:

float = <digit>*.?<digit>*  translation (0 or more digits, 0 or 1 radix point, 0 or more digits)

point this at '3.14159' and you get multiple matches.  (3, 3.,3.1,3.14....).  How do you resolve this?  Of course you add another rule, you always choose the longest match.

With just a simple change I can add a second rule building off of this one:

complex = <float><+|-><float><i> | <float><i> | <float> translation (a+bi or ai or a)

You can add ai+b if you want, no problem (I wouldn't).  Again, with the selection of the longest match there is no ambiguity.

This is all interesting, but really misses the crux of my argument.  Regardless of what is being matched, ie. let's be truly context free and forget about numbers and +/- and all that:  if 'x' is a match then any string that starts with 'x' must be a match.   If your "simple greedy algorithm" is returning a zero-length match when a match of length 1 demonstrably exists, the algorithm is wrong.  If '2' is a match, '2+2' must also be a match of at least length one, that is the very definition of greedy.  This is not a matter of opinion it is a matter of fact.  You could argue that '2' should not be a match, that is opinion.   You could argue that nobody cares, also opinion and one I share even if it saddens me a little.  But I can not see how a "simple greedy algorithm" can be deemed correct when it fails to return the longest match.

[natasftw]

Does anyone want to clarify how Error In impacting a scan using or ignoring a default value is the "same issue" as a disagreement over how complex numbers should be parsed?