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 )
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
Description: | modified (diff) |
---|
comment:2 Changed 12 years ago by
Interestingly, the same happens with 1/(1+1+1). I couldn't check further examples so far.
comment:3 Changed 12 years ago by
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?
comment:5 Changed 12 years ago by
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
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
Owner: | changed from somebody to hannes |
---|
comment:8 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
issues a warning:
// ** int division with `/`: use `div` instead in line >>1/(1+1); <<
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.