BreakPoint

cancel
Showing results for 
Search instead for 
Did you mean: 

Rube Goldberg Code

One of the problems is that there are 5 digit decimal numbers that exceed the U16 range, so we need to make sure the input is clean. If not, we need more bits. 😉

We also need to assume that the length is divisible by five.

 

Here's what I would probably have done (B) (or maybe a reshape before the loop followed by autoindexing on the 2D array*). I have not done any benchmarking though. Either could win.

 

ProcessString.png

 

I also strongly object to constantly resize the string in the shift register. We could just move the index based on [i], eliminating one subset operation and the shift register entirely.

 

ProcessString2.png

 

*Version with reshape array:

 

ProcessString3.png

 

 

Also, the chart terminal in the original code definitely belongs after the loop and if we show the digital display of the chart, we can also eliminate the other blue indicator.

0 Kudos
Message 2091 of 2,565
(10,293 Views)

@altenbach wrote:

One of the problems is that there are 5 digit decimal numbers that exceed the U16 range, so we need to make sure the input is clean. If not, we need more bits. 😉

I did realize that looking at the code and changed the indicator and chart to a U32 instead.  There were so many coercion dots in the code that I assumed that the OP really had no clue about numeric representations.

 

 

I also strongly object to constantly resize the string in the shift register. We could just move the index based on [i], eliminating one subset operation and the shift register entirely.

 

I'm curious about that comment.  Of course I'm familiar with the issues with growing string or arrays where there are slowdowns and eventually a potential out of memory error as things need to be moved around finding ever larger runs of free memory.  But what would be the issue where the data is shrinking in size?  I would think as parts of the string are eliminated, the part that stays in memory would be shrinking.  And the memory space it occupies would happen to have the no longer used bytes grow at the beginning.  That you wouldn't need to move data around or find larger blocks of memory.

 


 

0 Kudos
Message 2092 of 2,565
(10,261 Views)

@RavensFan wrote:
But what would be the issue where the data is shrinking in size?  I would think as parts of the string are eliminated, the part that stays in memory would be shrinking.  And the memory space it occupies would happen to have the no longer used bytes grow at the beginning.  That you wouldn't need to move data around or find larger blocks of memory.

Well, the memory has already been used and I doubt that it''ll free up these small fragmented spaces for anything. Typically LabVIEW holds on to memory because it will be needed again with the next call. I have the feeling that having to update the valid string size with each iteration is more expensive than just moving the read position along the existing string. I have not done any benchmarking, feel free to try. 😉

 

It's irrelevant for such cheap code anyway, but reducing the number of "string subset" operations from 2 to 1 and eliminating the shift register makes the code easier to read and simpler to understand..

Message 2093 of 2,565
(10,240 Views)

I appreciate the comment as I know you are someone who has a better understanding of behind the scenes stuff in programming and always set the gold standard for benchmarking.

 

I wasn't thrilled with the string manipulation either, but mostly I was pointing out code that had so many unnecessary constructs with the manual incrementing of the indices and the ASCII table manipulation to get digit values and the multiplication to combine digits.  The fact is that message thread had far more problems with a completely messed up communication protocol far exceeding the level of Rube Goldberg that was applied to try to decipher it.

Message 2094 of 2,565
(10,221 Views)

 


@RavensFan wrote:
But what would be the issue where the data is shrinking in size?  I would think as parts of the string are eliminated, the part that stays in memory would be shrinking.  And the memory space it occupies would happen to have the no longer used bytes grow at the beginning.  That you wouldn't need to move data around or find larger blocks of memory.


Don't have LabVIEW here at the moment, but for a good example of the opposite what you described look at the JKI State Machine, specifically the parse states VI. Or you can see this link

 

mcduff

0 Kudos
Message 2095 of 2,565
(10,159 Views)

Wow-just-wow!!!

 

(Seen here)

 

Problem: "I want to convert a decimal number (from -32768 to 32767) into a 16 bits Binary two's complement."

 

Solution: 😮

 

Bits16Rube.png

 

(Not even showing the TRUE case. (Hint: it's mostly indentical code on the right half!).

 

Yes this was labeled as "Here is a simpler version of what I did so far." ! I hate to even guess how the original looked like! 😮

 

My gut feeling tells me that there should be an easier way 😄

0 Kudos
Message 2096 of 2,565
(10,085 Views)

Your response showed the binary representation with the decimal in parenthesis,  how do you do that?

Matt J | National Instruments | CLA
0 Kudos
Message 2097 of 2,565
(10,068 Views)

multiple format strings in one indicatormultiple format strings in one indicator

Display format in advanced editing mode has multiple format strings for the one indicator.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
Message 2098 of 2,565
(10,061 Views)

I recently learned you can also do this:

Example_VI.png

formatting.png

More useful displays might include adding units, or labeling your indicators 'inline' (obviously for display only). (Maybe you can actually get the text representation and then do something?)

Example_VI.png

 


GCentral
Message 2099 of 2,565
(10,050 Views)

@Jacobson-ni wrote:

Your response showed the binary representation with the decimal in parenthesis,  how do you do that?


Well, you are excused because you joined the forum five years after our 2007 post. 😮

Still all true, so take some time to read and study it. 😄

 

 

Message 2100 of 2,565
(10,038 Views)