BreakPoint
Rube Goldberg Code
wiebe@CARYA wrote:
This would be faster than both the not and the add on the variable input.
The not on the constant will be constant folded...
You assume that "Not(X OR Y)" is an atomic operation. Is it?
@altenbach wrote:
wiebe@CARYA wrote:
This would be faster than both the not and the add on the variable input.
The not on the constant will be constant folded...
You assume that "Not(X OR Y)" is an atomic operation. Is it?
I can't tell for sure. Studying the DIFR and LLVM was 'inconclusive' (I soon gave up).
If it isn't an atomic operation, I'd put my bet on 2 LabVIEW nodes to be being slower.
Yet again, (if it isn't an atomic operation,) there is a change (with debugging off) LLVM will optimize the code to pretty much the same (a not\or vs or\not).
Either solution will be orders of magnitude faster than the 2 divides and the rest of the original mess.
The real CPU and memory hog is that each box sets the pen, even if the pen doesn't change. If you're drawing (an array of) boxes with the same pen, make a rect function without the pen, and set the pen once. Most picture control functions do this (set the pen every time), and it's horribly slow. The state of the pen will be kept, so you can draw boxes, lines, polylines, etc. with the same pen set just once.
Search LabVIEW like a graph! 
We are really getting into esoteric landscape here. An NOT OR could be a more complex execution than a simple AND so there is that! How that may or may not differ on a certain CPU architecture under a certain predicting branch execution, with a certain out of order pipeline execution, etc. etc. is an entire study in itself (and generally very irrelevant).
@rolfk wrote:
(and generally very irrelevant).
Yes, especially in this context.
Building those strings will be so much slower, probably even compared to the original code.
Makes me think about Ernst Heinrich Weber (Wikipedia). You start with RG, and won't bother with the tiny details. But when all the RG is gone, every tiny detail seems to make a relevant change (but doesn't).
wiebe@CARYA wrote:
Since performance differences are irrelevant, I would always go with more readable code. I argue that mine (top) is easier to comprehend by just looking at it while that double negative (bottom) is somewhat of a brain twister and is more likely to need a diagram comment. 😄
Of course in the example above (draw rectangle), there is more code around it to generate the four output values from six inputs raising the possibility of more global optimizations. I could think of eliminating the case structure because the FALSE case is identical to the TRUE case in half of all possible scenarios! I always prefer flat code where nothing is hidden in other cases of case structures! 🙂
@altenbach wrote:
I always prefer flat code where nothing is hidden in other cases of case structures!
Here's how that could look like... 😄 (Yes, performance considerations are irrelevant :D)
Or even....
Who needs data wires when we can do everything (everything!!!) with reference wires??? no need to connect any controls or indicators, we just declare them on the left as "variables".
Lets have a look at this youtube example.... (mentioned here earlier)
(Well, the front panel looks nice and it seems to work...)
I'd assume a lot of those controls should be in clusters on the front panel, so you'd only get 1 reference.
But if you want to go that route (it is more or less the only way to get re-useable user interface code), why use clusters?
If you put those references in classes, you can relate the front panel 'objects' with their methods and properties, and then it starts to look like a design method.
If you really (really!) like converting to dynamic data and back, here's what you should do (seen here)
Especially that NOOP going from 1D array to dynamic data and back immediately to the same(?) 1D array. Of course we cannot really tell from the picture, because the conversion configuration could be unusual... 😄 )
