08-09-2010 10:20 AM
The "Decimal String To Number.vi" seems to be converting the input data into type int32 internally even when the input data type to the vi is extended floating point (no coersion dot). This is causing me grief. See attached vi
Is this bug still present in LabVIEW 2010?
Thanks,
Richard Ballantyne
Solved! Go to Solution.
08-09-2010 10:33 AM
There is no bug. You are using the wrong function (read the help) if you want a floating point output. Use Fract/Exp String to Number.
08-09-2010 10:41 AM - edited 08-09-2010 10:45 AM
@Dennis Knutson wrote:
There is no bug. You are using the wrong function (read the help) if you want a floating point output. Use Fract/Exp String to Number.
I thought that too at first.
But the string is nothing but a series of integer digits. The string has no fractional portion to it.
You actually could reduce the VI that demonstrates this down to this:
08-09-2010 11:04 AM
In my opinion this is both a bug and an inappropriate use of the Decimal String to Number Function. If you insist on using it, you can always wire an I64 or U64 constant to the default value and coerce the output to EXT. I won't ask why.
08-09-2010 11:14 AM
In my particular case, I didn't care about the fractional component. Since the Decimal String To Number.vi was already on my block diagram for something else, it was easier for me to just copy/paste it than to go lookup and select the Fractional String To Number.vi. Since the Decimal String To Number.vi didn't complain (no coersion dot) when I wired in an Extended data type, I had no reason to believe that it wouldn't work.
So I still think this is a bug. For now I'm just going to use the Fractional String To Number vi instead.
08-09-2010 11:16 AM - edited 08-09-2010 11:19 AM
Richard,
You marked Dennis' reply as the solution. Are you saying you agree with him that it is not a bug and that you are using the wrong function?
I agree with Darin that the example you posted would be an inappropriate use of the decimal string to number function. But I also do believe you may have found a bug and that the Decimal String to number function is not working correctly and the example you posted demonstrates that.
Actually, I think the example I posted demonstrates it a little more clearly as it eliminates all the calculations going on at the front end, and also compares the decimal string function to the fractional string function, and for a string that contains no fractional portion (numbers after the decimal point) they should have the same result, yet they don't.
EDIT: Race condition, you seemed to have already answered my questions while I was in the middle of typing them.
08-09-2010 11:32 AM
Did not notice the problem with the '-' before and I agree that the use of EXT is wrong but this is a new bug. If it is not supposed to work with EXT and only integers, we should not be allowed to wire an EXT to the default data type input.
08-09-2010 11:55 AM
09-10-2010 03:49 PM
FYI - This was reported to R&D (CAR # 248609) for further investigation.
09-26-2016 04:17 PM
This is not a bug, you use the default on i32 reresentation, if you use i64 constant inthe default in (decimal string to number) you can resolv this problem.