Opened 12 years ago

Closed 9 years ago

# misinterpretation of numbers as ints (at least over Q)

Reported by: Owned by: seelisch hannes minor 3-1-4 and higher singular-kernel 3-1-3 interpreter number int

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.
```

### comment:1 Changed 12 years ago by dreyer

Description: modified (diff)

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.

### comment:2 Changed 12 years ago by anonymous

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

### comment:3 Changed 12 years ago by hannes

Type: bug → proposed feature
• 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?

Last edited 12 years ago by hannes (previous) (diff)

### comment:4 Changed 12 years ago by anonymous

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

1

Do we really want this?

### comment:5 Changed 12 years ago by 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.

### comment:6 Changed 12 years ago by 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)

### comment:7 Changed 12 years ago by Oleksandr

Owner: changed from somebody to hannes

### comment:8 Changed 9 years ago by hannes

Resolution: → fixed new → closed

issues a warning:

```// ** int division with `/`: use `div` instead in line >>1/(1+1); <<
```
Note: See TracTickets for help on using tickets.