Useless and costly code in ConvexPolygon ?

[veylonni]

Hi,

I was performing some profiling in my lib in order to speed it up, and I found that a lot of time is spent here :

https://github.com/codac-team/codac/blob/e8a9130ee8b4a95c52d0000a133dfda2f03004ef/src/core/geometry/codac_ConvexPolygon.cpp#L44

It seems to represent 72% of the computation time of my call to CtcDeriv::contract(Tube, Tube) !!!

I opened this issue because it seems that this time is lost because there is no need to call this line : m_v_floating_pts only contains the four corners of a 2D box (tdomain x codomain), so its already convex.

Am I wrong ?

Thanks in advance !!!

[SimonRohou]

Hi Nicolas,

Thanks for your feedback! This should be better: ec96fdb7d12a191d0ff79a436d85f85084eac9ee

However, your situation should appear only with unbounded derivative, according to this line. Is it the case in your application? This improvement is not valid for any situation then.

[veylonni]

Thanks Simon for your quick answer, as always :)

You're right, I didn't see the unbounded derivative, thanks ! I'll check that.

[veylonni]

I found two unbounded derivatives in my code that were not justified, but three other unbounded derivatives remain.

The problem is the dynamic constraint I apply in my code corresponds to a state transition model which includes a perfectly known control vector. The "workaround" I found is to append a control tube vector to the state tube vector in order to compute the derivative tube vector required by CtcDeriv. The drawback of this approach is that CtcDeriv tries to contract also the control tube vector because it's included in the state tube vector. In order to prevent any contraction of the control tube vector, I considered the derivatives to be infinite, hence the unbounded derivatives.

I suspect that it is not the better way to include a control vector to a state transition model, but it is the only way I found. Perhaps you have an idea on the proper way to do this.

[SimonRohou]

If I understand your problem: your are dealing with a system under the form xdot=f(x,u) where u is the input of the system described by the state x.

We are working on a dedicated contractor for dealing with these systems. But it is not ready/available at the moment.

In some examples, such as here, you can enclose your control in a tube [u](.) and use it without appending it to the state tube. Using for instance a CtcFunction contractor defined with something like: Function("v[4]", "x[4]", "u[2]", "...."), where v is the derivative of x: the output of f(x,u). Then the CtcDeriv is used with x and v as arguments, no more control.

If the input is analytically known, you can also define the Function so that its values appear in the expression.

With these solutions, there is not more unbounded derivatives. Hope this helps!

[veylonni]

I'll try that, thanks for the support! I close this issue.