misinterpretation of numbers as ints (at least over Q)

[seelisch]

I guess we do not want SINGULAR to work as illustrated below. --> need to change interpreter rules (or at least their order of application) for computing with numbers vs. ints.

$ Singular
                     SINGULAR                                 /
 A Computer Algebra System for Polynomial Computations       /   version 3-1-3
                                                           0<
 by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann     \   March 2011
FB Mathematik der Universitaet, D-67653 Kaiserslautern        \
> ring r = 0, dummy, dp;
> 1/2;   // division by number 2 in Q
1/2
> 1/(1+1);   // integer division by integer 2
0
> Auf Wiedersehen.

[dreyer]

This is what I mentioned earlier (for instance see: #307): Singular treats operations differently depending where the arguments are coming from. So you always have to assign intermediate results, no matter how trivial they are. (I had mentioned that in the second-to-last meeting within another context.)

In #307 we worked around that issue, but now it seems, that the problem occurs not only in funny corner cases.

[anonymous]

Interestingly, the same happens with 1/(1+1+1). I couldn't check further examples so far.

[hannes]

• operations depend on the type of the operands (and we do not want to change this)
• if an object does not have a type (i.e given as an untyped constant) the interpreter has to guess, and it guesses 'int' for 1 etc.(and we do not want to change this)
• and what is the int 1 divided by the int 3(in int): 0. But you can simply forbid / for int! This has nice consequences: 1/2 yields 1/2 or 16002 or an error message (DO WE REALLY WANT THIS?) and it would break a lot of the libraries.
• Or introduce a default field outside of polynomial coefficient just for printing 1/2 ? And what type should have the result?

[anonymous]

ring r = 0, dummy, dp; 2 == 1+1;

1

Do we really want this?

[gorzel]

Similar to the following (well) known issue:

> 2^38;
// ** int overflow(^), result may be wrong
0
> bigint(2)^38;
274877906944

To cope with it, use syntactically an explicit cast to number.

> ring r0 =0,x,dp;
> 1/(1+1);
0
> number(1)/(1+1);
1/2
> 1/number(1+1);
1/2

Be aware that the here described behaviour also involves computation with variables:

> int n=2;
> 1/(n+1);
0
> number(1)/(n+1);
1/3
> 1/number(n+1);
1/3
> n/3;
0
> number(n)/3;
2/3

In case this will be discussed further or if there is some intention to change it, consider to distinguish strictly between "/" and "/ " which stands for integer division.

[seelisch]

See the (German) meeting minutes of May 04, 2011 for how to proceed with this issue:

1) goal for near future release: forbid "int/int"; use "/" for numbers only; for int's use "int div int" instead 2) include warning in current source code when calling "int/int" (with info that "int div int" is be used instead) 3) long term goal (not addressing this ticket's issue but resulting from discussion in the SINGULAR team): incorporate ring-independent type "rational" (e.g. for returning coefficients of Hilbert polynomials regardless of current ring)

[hannes]

issues a warning:

// ** int division with `/`: use `div` instead in line >>1/(1+1); <<