Type Cast from I32 to I32?

[MikaelH]

Does anybody know why in some Point By Point functions there is a Type Cast from I32 to I32 in the code.
E.g.
Sort 1D Array PtByPt.vi
Array Max & Min PtByPt.vi

 

[infinitenothing]

I wonder if that's an old school "always copy". Maybe a copy paste from other code where there wasn't a type specified in any of the cases?

Edited November 21, 2016 by infinitenothing

[ned]

I've had to do this on occasion to force a shift register to the correct data type. I suspect that if you take it out, that shift register will become a floating point, since that's usually the default for a numeric function and there's nothing else in the code to force it to a particular numeric type.

[infinitenothing]

I checked that VI and removing the type cast does not change it to a floating point because one of the other cases sets the index to a typed integer.

[Rolf Kalbermatter]

11 hours ago, infinitenothing said:

I checked that VI and removing the type cast does not change it to a floating point because one of the other cases sets the index to a typed integer.

That might be true in the current version of that VI, but at some point that was probably not the case and then the typecast can be necessary. Although recent versions of LabVIEW don't automatically turn into floating point if you remove any explicit type specification in the path of a shift register, they still will turn to that whenever you edit something that causes LabVIEW to have to decide between incompatible datatypes. An explicit typecast somewhere makes sure the code will be forced to that type and cause a broken arrow if something gets incompatible with it. The alternative is to have a case like initialize or similar where you explicitly set the shift register to a certain default value through a constant.

[MikaelH]

What they should have done, is to convert the U32 to U64 inside the node, so it handles the date correctly, but maybe it's not that easy

[Rolf Kalbermatter]

That would seem to me to be posted to the wrong thread. You probably meant to reply to the thread about the Timestring function and yes that is not as easy as changing the datatype. The manager functions are documented and can't simply change at will. Anything that was documented officially in any manual has to stay the same typewise or CIN or DLL compiled with an older version of the LabVIEW manager functions will suddenly start to misbehave when run from within a LabVIEW version with the new changed datatype and vice versa!!

The only allowable change would be to create a new function

CStr DateCStringU64(uInt64 secs, ConstCStr fmt);

implement it and test it to do the right thing and then use it from the DateTime node. However a timestamp in LabVIEW 7 and newer is not a U64 but in fact more like a fixed point 64,64 bit value with a 64 bit signed integer that indicates the seconds and a 64 bit unsigned integer indicating the fractional seconds. So This function would better be using that datatype then.

But the whole DateCString and friends function is from very old LabVIEW days. The fact that it does return a CStr rather than a LStrHandle is already an indication. And to make things even worse to make such a function actually work with the date beyond 2040 one really has to rewrite it in large parts and there is no good way to guarantee that such a rewritten function would actually really produce exactly the same string in every possible situation.

That sounds to me like a lot of work to provide functionality with little to now real benefit, especially if you consider that the newer formatting functions actually do work with a much larger calendar range already, although they do not work for the entire theoretically possible range of the 128 bit LabVIEW timestamp. In fact that timestamp can cover the range of +- 8'000'000'000'000'000'000 seconds relative to January 1, 1904 GMT (something like +-250'000'000'000 years, which is way beyond the expected lifetime of our universe) with a resolution of 2^-64 or ~10^-19 seconds which is less than a tenth of an atto second. However I do believe that the least significant 32 bits of the fractional part are not used by LabVIEW at all, which still makes it having a resolution of 2^-32 or less than 10^-9 seconds or about 0.25 nano seconds. 

Edited November 22, 2016 by rolfk