Hi there,
this is the contents of lines 1411-1414 of Polyhedron.cc.
#if 0 //#ifdef BE_LAZY // FIXME: this has to be checked carefully // for correctness and/or efficiency.
Can someone explain what is happening here? Ciao,
Roberto
Hi there,
this is the contents of lines 1411-1414 of Polyhedron.cc.
#if 0 //#ifdef BE_LAZY // FIXME: this has to be checked carefully // for correctness and/or efficiency.
Can someone explain what is happening here?
It _was_ happening that I (maybe together with Elisa) was looking for places where we could have been lazier than we are now. Unfortunately, then I got busy with other stuff, so that the "#ifdef BE_LAZY" is still in its place, commented out and wrong.
In that particular case, I noted that we were using the procedure Matrix::merge_rows_assign which takes as argument a reference to a _const_ Matrix. Therefore, this procedure _copies_ rows from its argument.
However, when we call this procedure in add_constraints, our actual parameter is not required to be const, so that we could have avoided this copy and swap constraints instead. I then realized that swap of constraints could not be done if the space dimensions were different. Still, instead of copying, we could have swapped the coefficient of the constraints, therefore achieving some improvement when dealing with big numbers. Now, don't ask me why in the commented code we were still using assignment instead of swaps ... as I said, I had to stop working on it, commented it out and then plainly forgot about this improvement.
Maybe Elisa remembers something more ...
Enea.
Enea Zaffanella wrote:
Hi there,
this is the contents of lines 1411-1414 of Polyhedron.cc.
#if 0 //#ifdef BE_LAZY // FIXME: this has to be checked carefully // for correctness and/or efficiency.
Can someone explain what is happening here?
It _was_ happening that I (maybe together with Elisa) was looking for places where we could have been lazier than we are now. Unfortunately, then I got busy with other stuff, so that the "#ifdef BE_LAZY" is still in its place, commented out and wrong.
In that particular case, I noted that we were using the procedure Matrix::merge_rows_assign which takes as argument a reference to a _const_ Matrix. Therefore, this procedure _copies_ rows from its argument.
However, when we call this procedure in add_constraints, our actual parameter is not required to be const, so that we could have avoided this copy and swap constraints instead. I then realized that swap of constraints could not be done if the space dimensions were different. Still, instead of copying, we could have swapped the coefficient of the constraints, therefore achieving some improvement when dealing with big numbers. Now, don't ask me why in the commented code we were still using assignment instead of swaps ... as I said, I had to stop working on it, commented it out and then plainly forgot about this improvement.
Maybe Elisa remembers something more ...
Enea.
PPL-devel mailing list PPL-devel@cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/ppl-devel
I only remember that Enea added this part of code to prove adding rows without using Matrix::merge_rows_assign. This was done before the function Matrix::merge_... resizes the system that we want to add.
Ciao, Elisa
participants (3)
-
Elisa Ricci -
Enea Zaffanella -
Roberto Bagnara