renaming conflicting variables during ring creation triggers a bug

[kroeker@…]

Renaming conflicting variables is critical as the following example shows.

Therefore I suggest always to trigger an error when a ring declaration contains duplicate variable names. In case a programmer wants to introduce new k variables I suggest to provide a system routine, which gets a list of already defined variables and returns new k variables which are not in conflict with existing ones.

Minimal failing example:

printlevel=15; TRACE=1; LIB("primdecint.lib");

ring rng = integer,(a,b,y(1),d),dp; ideal j = 2*d, d*d,y(1)*y(1) - y(1)*d, b*y(1) - 2*d, a*b + y(1)*d; radicalZ(j); # results in infinite loop; ( renaming takes place in primdec::zeroRad ) # primdec::zeroRad also introduces y(1), but at first place and then the existing variable is renamed instead of the new one

[hannes]

This is a bug in primdecint.lib: libraries should never rely on names of ring variables but use var(i)

[kroeker@…]

Replying to hannes:

This is a bug in primdecint.lib: libraries should never rely on names of ring variables but use var(i)

I'm with you that the bug is caused elswere (it is in primdec::zeroRad) ; a patch is in preparation.

BUT automatic variable renaming (in 'ipshell.cc') will shadow bugs or cause new ones. Therefore I insist on a change , namely that automatic renaming in ipshelll.cc will not be done any more.

Best,

Jakob

[boehm]

Should be changed in the library. Gerhard, koenntest Du das bitte in der Bibliothek anschauen.

[kroeker@…]

Submitted patch proposal for naming conflict in primdec::zeroRad for spielwiese:

​https://github.com/Singular/Sources/pull/382

while keeping 'ipshell.cc' unchanged till the discussion related to automatic renaming did not come to a conclusion.

[hannes]

fixed in primdecint.lib