BreakPoint
Rube Goldberg Code
@paulmw wrote:
@JÞB wrote:
@altenbach wrote:
Well, to be fair, your code is not equivalent, because it omits the error handling. 😮
Nor does it remove all whitespace characters
missed that the first time myself
That will probably become a big bug for someone to discover in the future. "Why can't I insert a 32, it keeps chaning to 0!" (unless that is intended...)
That is not intended. It should properly handle any number of the range 1 - 100 (that's from a check outside this SubVI). Apparently this VI comes from a copy of another that does the same thing... only with a Uint32. Just take the unbundle and rebundle part near the end and expand those down to 4 indexes and more horizontal lines across.
As for the error handling. It happens again external to this subVI. "Just to be sure!"
@altenbach wrote:
Do some hex formatting.... (Seen here)
Also notice that the while loop will iterate two extra times (should be i+1 >= array size for the stop condition).
@crossrulz wrote:
Also notice that the while loop will iterate two extra times (should be i+1 >= array size for the stop condition).
Yes, I did not worry about commenting on the loop code. Since the number of iterations is known before the loop starts, a FOR loop would be correcter anyway.
@ThiCop wrote:
Hmmm, this coercion dot is annoying here.
Luckily it's already CARred.
That coercion dot is a bit more than annoying. If I remember correctly it blows up the [U8] into a [U64] or [I64]. This is one of those rare moments when a G implementation can outperform a primitive, albeit a botched primitive.
This is much faster than the primitive for [U8], simply by avoiding the wasteful coercion. Not all red dots are created equal, this is one of the worst offenders. At least the default conversion is not [CEXT].
@Darin.K wrote:
@ThiCop wrote:
Hmmm, this coercion dot is annoying here.
Luckily it's already CARred.That coercion dot is a bit more than annoying. If I remember correctly it blows up the [U8] into a [U64] or [I64]. This is one of those rare moments when a G implementation can outperform a primitive, albeit a botched primitive.
This is much faster than the primitive for [U8], simply by avoiding the wasteful coercion. Not all red dots are created equal, this is one of the worst offenders. At least the default conversion is not [CEXT].
Like it!
I wonder if you couldn't eek a bit more performance autoindexing out (probably with 'Auto-Concatenating' turned on, LV2012+) and parallelizing? Ostensibly, the compiler could be able to handle the pre-allocation without all the explicit prims, since output size could be constrained through static analysis of that snippet.
