Re: FK and Jacobian calculation in RTT

On Mon, 20 Jan 2014, S Roderick wrote:

> On Jan 20, 2014, at 04:51 , Sylvain Joyeux <[email protected]> wrote:
>
>> On Sunday, January 19, 2014 07:58:29 PM Herman Bruyninckx wrote:
>>> RTT components are meant to put several functions (like KLD dynamics
>>> functions!) inside one and the same "process"/"thread"/"activity. It does
>>> not make sense to put individual KDL functions each in their own RTT
>>> component!
>> Why not?
>>
>> If the function is indeed costly *and* is reused (IK comes to mind), why
>> putting it in a single RTT component would be "bad" ?
>
> Agreed. It's comes down to the context of the system and the algorithms
> employed, rather than some generic set of rules that must apply.

Not agreed... It _is_ a generic rule that processes take up orders of
magnitude more resources than function calls, so the obvious _first_ thing
to think of is to reuse functionality as _functions_, not as
processes/activities. Assigning one single process to one single function
should be a well-motivated _exception_, and any (even implicit) suggestion
that "the context" is in general equally ready to accept either solution is
hard to motivate.

For example, in the context of IK/ID functionality: sharing the "costly"
_code_ of such a function is simple when deploying it as a function where
the different callers keep their own computational state of the function,
but reuse the executable code by just pointing to it; such decoupling of
computational state from the code of the algorithm does _in general_ not
require deployment in different processes (if the code is re-entrant).

About the cost of IK code: we are talking order of magnitude "kilobytes" of
binary executable code, so even using multiple copies of it is cheap,
compared to the "megabytes" of mainstream communication middleware and
software frameworks. Especially in an open source context, compiling in the
code in various "components" is not an issue (which is different in a
proprietary context, obviously, where deployment in a "DRM service" makes
sense, for the purpose of implementation hiding).

I am very open to be proven wrong, as always.

> S

Herman
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev