Ask Your Question

ShreevatsaR's profile - activity

2022-03-31 10:31:33 +0100 received badge  Famous Question (source)
2021-11-04 20:32:48 +0100 received badge  Notable Question (source)
2021-01-14 22:19:16 +0100 received badge  Popular Question (source)
2020-09-24 14:21:23 +0100 commented answer Incorrect result for comparison (precision issues?)

I guess it may be impossible to handle the case when a is actually equal to b, but we can raise an exception: see

2020-09-23 22:48:23 +0100 commented answer Incorrect results for comparison expression

For some reason, (x-1/47749).is_zero()gives True for me… (Sage 8.3 which is a couple of years old, but also tried it on CoCalc Instant SageWorksheet linked from

2020-09-23 21:31:39 +0100 commented answer Incorrect results for comparison expression

Doesn't bool(1/47749 <= -5564456128*e + 15125759978) satisfy your recommendation to "stay exact as long as possible"? The question is how to perform the comparison in a way that gives a correct answer.

2020-09-23 21:30:23 +0100 commented answer Incorrect results for comparison expression

Here's the earlier question: — I can't post it as a link from the account that asked the question, it's a new account with not enough karma, and I can't find a way to merge the accounts.

2019-11-16 02:07:12 +0100 commented question Different results with for loop and while loop
2019-11-15 23:38:34 +0100 answered a question Different results with for loop and while loop

Figured out the the reason as well: with

for w in range(1, N):

the type of w is int, and so is the type of h inside the inner loop in fill. So something like w/(w+h) uses integer division (on ints), giving 0.

On the other hand, with

w = 1
while w < N:
    w += 1

the type of w is Integer, so w/(w+h) results in a proper fraction and not 0.

2019-11-15 23:35:56 +0100 asked a question Different results with for loop and while loop

While writing a Sage script, I ran into a strange case where code worked correctly with specific constants, but when I looped over them in a for loop, it no longer worked. After trying this and that, I found that a while loop did not have this problem! As this felt very strange, recording the question here as a possible "gotcha".

Here's the code:

from collections import defaultdict
p = defaultdict(dict)

N = 30
for h in range(N): p[0][h] = z**h

def fill(w):
    for h in range(N - w):
        p[w][h] = w/(w+h)*p[w-1][h+1] + h/(w+h)*(p[w][h-1] if h>=1 else 0)

## This doesn't work:
# for w in range(1, N): fill(w)
## Instead we need the below:
w = 1
while w < N:
    w += 1

In short, the problem is that for w in range(1, N): ... results in all zero polynomials, while w = 1; while w < N: ... does not.

2016-02-17 19:30:11 +0100 received badge  Famous Question (source)
2016-01-31 03:27:23 +0100 received badge  Notable Question (source)
2016-01-30 00:56:06 +0100 received badge  Popular Question (source)
2016-01-29 17:46:21 +0100 received badge  Scholar (source)
2016-01-29 17:46:17 +0100 commented answer Incorrect result for comparison (precision issues?)

I also tried this (82553493450 * log(RIF(1024), base=10))._cmp_(248510777753) and got TypeError: Cannot convert sage.rings.integer.Integer to sage.rings.real_mpfi.RealIntervalFieldElement: now I understand thanks to your comment, that a RealIntervalField is one with a certain fixed precision (though you can vary the precision and get different RealIntervalFields); it is not a single field with arbitrary intervals of variable precision. If that existed, then any integer could be trivially converted to a RealIntervalFieldElement because it's just an interval of size 0 around that integer, which can be represented exactly. Thanks again!

2016-01-29 17:20:49 +0100 commented answer Incorrect result for comparison (precision issues?)

Very useful; thank you very much! I'll use this (will also mark this answer as accepted). But I'm wondering why log(RIF(1024), base=10) (or log(RLF(1024), base=10)), which is printed as 3.010299956639812?, does not automatically expand its precision when asked to be compared with 248510777753 / 82553493450 (which is about 3.0102999566398119521…). I do notice now (thanks to you) that with RIF it returns False for both < and > comparison (whereas with RLF it returns True for ==)… I would have expected Sage to have a true exact real arithmetic type (going by the title at but it seems we need to write our own wrapper for this.

2016-01-29 14:59:36 +0100 received badge  Student (source)
2016-01-29 08:24:29 +0100 commented question Incorrect result for comparison (precision issues?)

This is extremely odd:

sage: (log(1024)/log(10) * 82553493450 - 248510777753).n()

but the correct value is (with = 25) positive, not negative:

sage: mpmath.log10(1024) * 82553493450 - 248510777753

But the odd part is that if I try log(1024)/log(10) * 82553493450 - 248510777753 > 0*+82553493450+-+248510777753+%3E+0 (on Wolfram Alpha) it correctly says True, but shows the approximate form of the difference as exactly the same wrong value: -0.0000610352 !! How are both Sage and Wolfram Alpha getting to the same wrong answer?

2016-01-29 08:10:23 +0100 commented question Incorrect result for comparison (precision issues?)

Trying "arbitrary precision" doesn't help either:

RIF(10).log() * 248510777753 < RIF(1024).log() * 82553493450


log(RLF(1024), base=10) * 82553493450 > 248510777753

both return False, versus

mpmath.log(1024, b=10) * 82553493450 > 248510777753

which correctly returns True. It's beginning to look like a bug in Sage's log function?

2016-01-29 07:05:28 +0100 asked a question Incorrect result for comparison (precision issues?)

Consider this session:

sage: if log(10) * 248510777753 < log(1024) * 82553493450:
....:     print 'Less'
....: else:
....:     print 'Not less'
Not less

or more simply:

sage: bool(log(10)*248510777753 < log(1024)*82553493450)

But this is wrong, as we can see with higher-precision arithmetic:

sage: import mpmath
sage: = 22 # or anything greater
sage: bool(mpmath.log(10)*248510777753 < mpmath.log(1024)*82553493450)

I guess this is happening because Sage is computing to some finite precision. But when writing some bigger program, it's scary that a condition involving variables, like say,

if m * q < n * p:

can without warning give the wrong result and take the wrong path. Is there a way to prevent this from happening, i.e. to make sure that in the program, comparisons are done using as many bits of precision as are necessary to evaluate them correctly, without us having to pre-specify a precision (which may be both too large and wasteful, or too small and give incorrect results)?

2014-01-23 02:12:21 +0100 received badge  Supporter (source)