mark short notation deprecated?

[kroeker@…]

Short notation may be misinterpreted by the user, even if for the interpreter there is no ambiguity.

ring rng=0,(v,v5,w,vw),dp;
ideal I1 = vw;  // =vw   or =v*w   ?
ideal I2 = vwv; // =vw*v or =v*w*v ?
ideal I3 = v5;  // =v^5  or =v5    ?
ideal I4 = v55; // =v^55 or =v5^5  ?

Proposal: Step 1:

-mark short notation deprecated in the next version (print a warning)

-format output similar to Macaulay2:

5*x^5*y is printed like

  5
5x y

x*y is printed like

x*y

Step 2: disable short notation at some point in the future

comments?

[ren]

I like the short notation and being able to copy/paste the output of Singular right back into Singular. Makes it so much easier to use. :)

[Oleksandr]

maybe short could help you (see ​http://www.singular.uni-kl.de/Manual/3-1-6/sing_441.htm#SEC481)

[kroeker@…]

Replying to ren:

I like the short notation and being able to copy/paste the output of Singular right back into Singular. Makes it so much easier to use. :)

Ok, then I propose to disable short input/output format in case of potential ambiguities. That means, if ciphers are part of variable names or there is multiplication/variable name ambiguity

ring rng = 0,(a,b,ca,cb),dp; // ok for short format, no ambiguity possible
ring rng = 0,(a,b5,ca,cb),dp;  // not ok for short format, potential ambiguity
ring rng = 0,(a,b,ca,cb,c ),dp; // not ok for short format, potential ambiguity 

First approach: brute force check all variable name combinations up to length=2*maxNameLength-1

[kroeker@…]

Replying to motsak:

maybe short could help you (see www.singular.uni-kl.de/Manual/3-1-6/sing_441.htm#SEC481)

It is nice to know, how to switch the format.

Still, I propose that a ring should check if a misinterpretation is possible and in that case just disable the short format feature. As long as this is not done, I propose to change default setting for 'short' to 0.

In my opinion this will be sufficient for all practical applications.

[Oleksandr]

AFAIK short is 0 by default in SW... i.e.

> short;
0
> ring rng=0,(v,v5,w,vw),dp;
> short;
0
> ideal I4 = v55; I4;
I4[1]=v^55
> v5^5;
v5^5

[kroeker@…]

Replying to motsak:

AFAIK short is 0 by default in SW... i.e.

> short;
0
> ring rng=0,(v,v5,w,vw),dp;
> short;
0
> ideal I4 = v55; I4;
I4[1]=v^55
> v5^5;
v5^5

The short input

v55

is allowed, but should be forbidden (at least in this case), too ; That is what I mean with short=0.

Do you disagree?

[hannes]

One has to distinguish between input and output. Input: long format is always allowed, short format is allowed if it can be the output format Output: depends on the value of the (ring dependent) variable short: default: short==0 iff at least one variable name is longer than 1 character. Therefore ambiguities can only be introduced by the user (and its their fault)

[kroeker@…]

Replying to hannes:

One has to distinguish between input and output. Input: long format is always allowed, short format is allowed if it can be the output format Output: depends on the value of the (ring dependent) variable short: default: short==0 iff at least one variable name is longer than 1 character. Therefore ambiguities can only be introduced by the user (and its their fault)

Not sure if I understand it correctly:

Short input is not allowed if short output is not allowed. In the case above short output is not allowed(?), but short input (v55) was accepted =>bug?

[Oleksandr]

Therefore ambiguities can only be introduced by the user (and its their fault)

!

Short input is not allowed if short output is not allowed. In the case above short output is not allowed(?), but short input (v55) was accepted =>bug?

Nope: the user is responsible for shooting into user's own foot!

Please use long format whenever possible in order to avoid ambiguities.

[gorzel]

To cut this discussion short, see Chapter 6. Tricks and pitfalls

6.5 Identifier resolution

​http://www.singular.uni-kl.de/Manual/latest/sing_459.htm#SEC499

and 6.4 Miscellaneous oddities, 2. monomials and precedence

​http://www.singular.uni-kl.de/Manual/latest/sing_458.htm#SEC498

-----------------------------

The definition

ring rng=0,(v,v5,w,vw),dp;

is bad since it confuses the user.

Hence such declarations should, as the manual already states, be avoided.

Recommended variable namings are:

• use only single letter variable names, or

• indexed variables with an undescore v_1, or

• index variables names like v(1),v(2),...

This has the advantage that they can be adressed also in loops by int variables. This means

int i =2; v(i) = 1;

does work.

To recall and summarizing from above: If the basering contains an indexed variable name, or a variable name with more than one letter, the system variable 'short' is automatically set to 0. If the user reset it to short =1; then the input v55 is still interpreted as v ⁵⁵

and not as

v5 ^5.

This is due to the fact that Singular follows some priorities for the resolving of names.

So there is not really an ambiguity with the variables names.

I would vote for closing this ticket, ... but to add some more clarification an potential confusion note the following seemingly odd behaviour:

> ring r = 0,(x,y,v),dp;
> short;
1
> poly v = 5+x+y; 
> v5;
v5
> v^5;
x5+5x4y+10x3y2+10x2y3+5xy4+y5+25x4+100x3y+150x2y2+100xy3+25y4+250x3+750x2y+750xy2+250y3+1250x2+2500xy+1250y2+3125x+3125y+3125
> xv;
xv
> x*v;
x2+xy+5x

(As I said above, Singular follows certain priorities, which the user may experience.)

To avoid confusion (on the user side) with other objects of the same, you may use an @ in the definition, either of the poly or the ring variable.

[kroeker@…]

Replying to gorzel:

My concern of this ticket was and is, to get rid of this oddities, step by step, little by little, instead of being opportunistic and sinking deeper and deeper into that morass.

As you can see in the discussion I proposed a rigourous and short solution for the ambiguity issue of the short notation, (not for the name resolution issue) which was generously ignored until now, justified with the statements "its the users fault" or "there is no issue" until now.

The opportunistic approach does not only violate a basic engineering principle of conservative programming. A language with lot of oddities is vulnerable for unintended errors, has a steep learning curve and more important, the issues have a significant negative impact for productivity in the long run.

Therefore I vote to resolve oddities, as long as the advantages justifies the effort and suggest to start with this one.

Best,

Jakob

[ren]

Well, while it is certainly not wrong to get rid of oddities, the "user should know what she/he is doing" policy was probably adopted out of practical reasons, since we don't have an unlimited amount of manpower. :-/

It certainly would be nice if Singular had a "dau" mode, which would be turned on by default, checks all input for all possible types of correctness, and could be turned off (e.g. in libraries by default) to not slow down the code of the users who know what they are doing.

In the end, it just boils down to priorities. While I don't think we should dismiss the idea of checking all input for correctness, I don't see that this will be addressed anytime soon because of all the tasks that need to be done and that take priority beforehand.

[kroeker@…]

Well, while it is certainly not wrong to get rid of oddities, the "user should know what she/he is doing" policy was probably adopted out of practical reasons, since we don't have an unlimited amount of manpower.

<offtopic> @ren Procrastinating resolution of issues could haunt back with ampified force. And then better we have unlimited amount of manpower.

One example is the automatic variable renaming in Singular in case of a naming conflict. Meanwhile there about 500(!) locations in the library code which should be reviewed for potential bugs due to renaming as as demonstrated in the ticket 508, www.singular.uni-kl.de:8002/trac/ticket/508

In the end, it just boils down to priorities.

As usual, it is hard to find optimal priorisation :-/ </offtopic>