DSP Robotics Support

Thanks Trog.....can see those error's very clearly now... cheers

trogluddite wrote:The real lesson is that you cannot compare the performance of two codes unless they are semantically the same - i.e. the same input conditions produce the same output conditions (with the same timing, if that is important).
And after all this Ruby talk, it's ironic that our biggest friend here would have been the old, faithful "Green Trigger Counter" - it would have shown that the two codes were doing different things very quickly!

Couldn't agree more.

And one more thing. There is no "millions of primitives". These green prims within schematic - are represented by similar pieces of code that you can find in ruby. Just imagine, a red prim, named "def", another named "end". So switching between millions of green prims and thousands of red codes just means, that you have the same amount of "pieces", just in different visual form. And to expand it a little bit - the "queue" and "stack" prims are not larger than others because they look bigger; it's one of the traps of visual programming.

tester wrote:There is no "millions of primitives"

Yeh..saw that one real clear after dropping 700,000 prims....and listening to result....

I would think that the choice between PRIMS and RUBY allow programming flexibility.

As to the difference ... I'll listen to the experts views, but I would reason that the PRIMs themselves would be fairly optimized within itself. That, considering that they may have extra functions available that may or not be used by the programmer.

As to relate to RUBY, it would seem reasonable that it could be coded to mirror a PRIM's function.

A important distinction would be how the code is written in RUBY. Writing 'optimized' code is a desired end-goal ... but my typical result is to get it to work first ! ... then consider optimizing. And oft times that means a complete rewrite of the entire concept. It takes knowledge and experience to write any kind of good code. Using PRIMS can be more of a function of 'signal logic and flow' ... but the pieces being used are mostly efficient to start.

This is all really obvious ... but, I see RUBY as a desired tool to learn and use because some programming concepts are easier for me to realize as a list of instructions, rather than a flowchart. I think it really depends on what you're wanting to accomplish, and the way you relate it to the FS environment.

The difficulty of getting over the initial Ruby hurdle seems to have the bigger challenge for me at least.

Just one example that I look to Ruby for are things like multiple IF's ... or when I can ... the CASE syntax. Trying to handle many conditionals in PRIMS can be visually tough ... where using CASE or IF's in Ruby is usually easier for me to put together, manage, and follow.

I'm not trying to lessen the importants of PRIMs ... if it wasn't for them, I'd not have gotten involved with any of this probably. The PRIMS also buy me time to learn more and get better at Ruby ... because at this moment ... I am the limiting factor.