Opened 12 years ago

Closed 9 years ago

#337 closed proposed feature (fixed)

misinterpretation of numbers as ints (at least over Q)

Reported by: seelisch Owned by: hannes
Priority: minor Milestone: 3-1-4 and higher
Component: singular-kernel Version: 3-1-3
Keywords: interpreter number int Cc:

Description (last modified by dreyer)

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.

Change History (8)

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: bugproposed 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
Status: newclosed

issues a warning:

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