06-14-2009 10:35 AM
Cory K wrote:Why wouldnt you just append a constant of " "?
Well, I guess thats more colorful.
At bare minimum at least split the wire or use a tab lol
06-14-2009 11:26 AM - edited 06-14-2009 11:27 AM
Cory K wrote:Why wouldnt you just append a constant of " "?
Well, then it would not be Rube Goldberg code and would be offtopic in this thread. :o:D
(read my reply in the original thread (FYP_5MOD.vi). We can do all in one formatting operation without any string manipulation at all).
06-17-2009 08:54 AM
I was getting a "MechFactoryCWrap.cpp line 956" crash under LV 8.6 (CAR#174798) when trying to trasnfer an array of waveform data type via queue from one LVOOP based template to another. The following Rube Goldberg code stopped the crashing.
The code looked much better before.
Ben
06-17-2009 09:20 AM - edited 06-17-2009 09:24 AM
I was looking at some books on Google books, then I found this http://books.google.com/books?id=Ta_C5PWcw9kC&pg=PA135
I am not quite sure but is this not a very complex method?
06-17-2009 09:33 AM - edited 06-17-2009 09:39 AM
This one is mine.......
In relation to forcing the output type on a Dynamic Dispatch VI. (Not REALLY a Rube-Goldberg but coming mighty close.....)
In firness, it does actually do something (apart from breaking the Dynamic Dispatch idea).
Shane.
06-17-2009 11:01 PM
Coq rouge wrote:I was looking at some books on Google books, then I found this http://books.google.com/books?id=Ta_C5PWcw9kC&pg=PA135
I am not quite sure but is this not a very complex method?
In fairness, the text indicates that it was done for speed. It's not clear which version of LabVIEW this would apply to, though, and that usually affects this kind of situation. While the cover states the book has been revised for LV 8.0, the example may be old (and I suspect it is) .
06-17-2009 11:16 PM
smercurio_fc wrote:
Coq rouge wrote:I was looking at some books on Google books, then I found this http://books.google.com/books?id=Ta_C5PWcw9kC&pg=PA135
I am not quite sure but is this not a very complex method?
In fairness, the text indicates that it was done for speed. It's not clear which version of LabVIEW this would apply to, though, and that usually affects this kind of situation. While the cover states the book has been revised for LV 8.0, the example may be old (and I suspect it is) .
Me thinks Smercurio_FC doth protesteth too much. you edited the book didn't you?
06-18-2009 12:25 AM - edited 06-18-2009 12:27 AM
smercurio_fc wrote:In fairness, the text indicates that it was done for speed.
Doing a meaningful benchmark on this is very (very!) difficult, because we need to make sure to avoid constant folding.
Anyway, the code shown in the book is surprisingly efficient compared to some other ideas,
but a plain string operation is still about twice as fast (code at the bottom).
Here are four code alternatives and the relative execution time. As you can see, it's not the best, and in contradiction
to what is said in the book, there are many buffer allocations. To be fair, I am sure the buffer allocation display
was not available when this code was written, so the author probably had to guess.
Note: There are just some quick ideas for code alternatives. I am sure there are even better ones. 😉
It's puzzling how slow the bitwise operation is.
(Still, we probably don't need to worry about speed on four bytes of data ;))
06-18-2009 12:45 AM - edited 06-18-2009 12:46 AM
06-18-2009 09:42 AM
Jeff Bohrer wrote:Me thinks Smercurio_FC doth protesteth too much. you edited the book didn't you?
Huh?
All I'm trying to point out is that you can't jump to a conclusion regarding that code, especially given the explanation that was in the book (and shown in the screenshot). Memory management and allocations have changed dramatically over the years, so what was true once may no longer be true. So what may seem like a Rube Goldberg and something completely unnecessary today may have been a necessary evil way back in the "stone age".