Documentation of degreeDecrease is incorrect

[dominik-mokris-mtu]

Describe the bug
The documentation of degreeDecrease states

/// Inverse of degreeIncrease.

However, since e60d9e7 degreeDecrease is only the left inverse of degreeIncrease.

To Reproduce
Run the following example.

#include <gismo.h>

using namespace gismo;

int main()
{
	gsKnotVector<> knots(0.0, 1.0, 4, 4);
	knots.insert(0.2, 2);
	gsInfo << "initial knots:   " << knots << std::endl;

	gsInfo << "First, we try to invert from left." << std::endl;

	knots.degreeIncrease();
	gsInfo << "increased knots: " << knots << std::endl;

	knots.degreeDecrease();
	gsInfo << "decreased knots: " << knots << std::endl;

	// knots is now the same as before, which is correct.

	gsInfo << "Now, we try to invert from right." << std::endl;

	knots.degreeDecrease();
	gsInfo << "decreased knots: " << knots << std::endl;

	knots.degreeIncrease();
	gsInfo << "increased knots: " << knots << std::endl;

	// knots is now different than in the beginning, which is a problem.

	return -1;
}

It yields

initial knots:   [ 0 0 0 0 0.2 0.2 0.2 0.4 0.6 0.8 1 1 1 1 ] (deg=3, size=14, minSpan=0.2, maxSpan=0.2)
First, we try to invert from left.
increased knots: [ 0 0 0 0 0 0.2 0.2 0.2 0.4 0.6 0.8 1 1 1 1 1 ] (deg=4, size=16, minSpan=0.2, maxSpan=0.2)
decreased knots: [ 0 0 0 0 0.2 0.2 0.2 0.4 0.6 0.8 1 1 1 1 ] (deg=3, size=14, minSpan=0.2, maxSpan=0.2)
Now, we try to invert from right.
decreased knots: [ 0 0 0 0.2 0.2 0.4 0.6 0.8 1 1 1 ] (deg=2, size=11, minSpan=0.2, maxSpan=0.2)
increased knots: [ 0 0 0 0 0.2 0.2 0.4 0.6 0.8 1 1 1 1 ] (deg=3, size=13, minSpan=0.2, maxSpan=0.2)

Expected behavior
The same as prior to e60d9e7:

initial knots:   [ 0 0 0 0 0.2 0.2 0.2 0.4 0.6 0.8 1 1 1 1 ] (deg=3, size=14, minSpan=0.2, maxSpan=0.2)
First, we try to invert from left.
increased knots: [ 0 0 0 0 0 0.2 0.2 0.2 0.4 0.6 0.8 1 1 1 1 1 ] (deg=4, size=16, minSpan=0.2, maxSpan=0.2)
decreased knots: [ 0 0 0 0 0.2 0.2 0.2 0.4 0.6 0.8 1 1 1 1 ] (deg=3, size=14, minSpan=0.2, maxSpan=0.2)
Now, we try to invert from right.
decreased knots: [ 0 0 0 0.2 0.2 0.2 0.4 0.6 0.8 1 1 1 ] (deg=2, size=12, minSpan=0.2, maxSpan=0.2)
increased knots: [ 0 0 0 0 0.2 0.2 0.2 0.4 0.6 0.8 1 1 1 1 ] (deg=3, size=14, minSpan=0.2, maxSpan=0.2)

(Note that the last knot vector is identical to the first one.)

Desktop (please complete the following information):

• OS: Linux
• Branch/fork used: stable

[filiatra]

Hi Dominik, thnx for this issue.
The reason that we changed this is to bound the multiplicity of the interior knots by the degree.. Indeed, multiplicity more than d in a degree d basis makes no sense...

Do you propose to update the documentation or you think that the previous behaviour may be needed ?

[dominik-mokris-mtu]

To be honest, I am struggling to understand where these two functions (degreeIncrease and degreeDecrease) can be useful at all. Are they in use? And if yes, how do we know that the change has not broken anything?

[dominik-mokris-mtu]

Indeed, multiplicity more than d in a degree d basis makes no sense...

I agree that multiplicity d sounds strange, although I could also imagine someone trying to model a discontinuous function this way (@weinmueller ?).

If we restrict ourselves to multiplicity strictly less than d, we should explicitly state it. Maybe in the documentation of the class..?

[filiatra]

It is used I think, maybe as much as the degreeElevate in fact !
@weinmueller let us know if this change impacts your codes

[weinmueller]

Hello all, I could find a workaround, this is not a problem :)

This is what I think:

• If someone is using degreeDecrease or degreeElevate, then this person knows in general how the knotvector looks. So maybe this imaginary, beautiful person is using degreeDecrease and then reduceMultiplicity or knotRemove or whatever (I know that there exist degreeReduce), then this sad person cannot use it anymore. I think that we are not responsible for checking everytime if the knotvector is valid or not. I also think that the checking part should be outside of the function.
• We have a loop over knotvectors which costs time (even if it is not much). But this is not necessary in most of the cases since the knotvector is known a priori.

That's why I would keep it as before or at least do the booleans option. That would be my opinion. And of course adapt the documentation :)