Jump to content

ArjanWiskerke

Members
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

0

About ArjanWiskerke

  • Rank
    LAVA groupie

LabVIEW Information

  • Version
    LabVIEW 2012
  • Since
    2000

Recent Profile Visitors

499 profile views
  1. Somewhere in my code I wanted to restart a procedure using an empty array with the same type as the data that is wired in.
    Earlier, I used "create constant" in the editor. The disadvantage is that when I change the type of the constant I will have to edit 
    the constant again. 
    This construction I use to create an empty array with the appropriate type using the delete from array or array subset t
    using 0 for the length.
    This way it acts as automatic type deduction.
    Are there performance issues regarding this construction?

    I think there might even be a standard "empty array.vi" that I overlooked.

    array type deduction.png

    type deduction.vi

  2. By the way, You can use a Lookup table / Karnaugh diagram if you start with Byte's instead of Boolean's. Still slower than the logic (0.027 versus 0.022) .
  3. I am still surprised the option {build array; convert to Byte} does so bad because I think of those nodes as primitive labVIEW operations. Convert to Byte is not a frequently used node, maybe It is not a very basic operation after all. I am also a bit disappointed because I like the idea of editing a truth table. Of course, performance wins from beauty!
  4. OK, Here is the code I used for testing. There is disabled code to generate random Boolean array's. I ran that code and copied the data into the array constants. before testing the alternative solutions. I had to empty the arrays again to reduce the file size. testShortCutEvaluation.vi
  5. I tested the "case structure" solution again. In contrast to my previous results, there was a speed improvement. I have put the case structure back into my code, and since the logic is more complicated, the case statement really improves the speed.
  6. Thank you for your replies on the "short cut evaluation". I already tried the construction of crossrulz, Unfortunately, it turned out that the case statement itself slows down the speed. Also I tested the speed applying true or false to a. No difference was detected, of course because the ^-node needs input from the v-node as is pointed out by Craig. Does it mean that short cut evaluation is fundamentally impossible? LabVIEW in the end generates C code. The c compiler, I would think, takes care of the short-circuit evaluation.
  7. For most programming languages, when a logical expression is evaluate, like " d = a AND ( b OR c )" the operation is terminated when "a" is false and the expression "b OR c" will not be processed. I think the LabVIEW compiler does something similar. Does anyone know? Problem in LabVIEW is the processing order is not defined.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.