> > ... This model has the advantage that (sqrt(1+t)^2 -1)/t == 1 returns > true, as one would expect mathematically. (insisting equality up to the > default precision would have to lead to false, because the arithmetic on > the LHS leads to precision loss) >
Your example is convincing and I'm not going to mistrust the ball design. The truth is that we can't say whether O(t) is zero or not. But since the answer is a boolean we have to make a decision (giving an "exact" answer for an "inexact" question). Independend on how this decision is made cases of irritations will be left. For example, if a user defines R.<t>=PowerSeriesRing(ZZ, default_prec=100) and types in p + O(21) with some polynomial p of degree 20 than he would not expect `p + O(21) == p` to be True since that looks as if we have lost something (similar as in Bill Harts example). Indeed, but I think the actual bug there is: Power series rings over > non-exact base rings don't work properly. This is a problem that you should > expect: algebra algorithms normally designed to work with exact base rings > will have problems with non-exact ones, and usually for the reason you see > here: to work properly with power series over exact rings, you eliminate > (exact) zeros, but the inexact zeros that you encounter in power series > rings should probably be kept for precision tracking reasons (also the ones > up to default precision!). But keeping them around indiscriminately would > lead to impractical results very quickly. Special care is needed. You might > try working with ZZ[['t','u']] instead. > So, what should we do than? Print a warning if somebody tries to define them (and suggest to use multivariate power series in cases that would lead to an alternative)? On Thursday, January 16, 2020 at 12:09:13 AM UTC+1, Nils Bruin wrote: > > > On Wednesday, January 15, 2020 at 12:45:10 PM UTC-8, Sebastian Oehms wrote: >> >> My expectation is that two power series are considered to be equal if >> there polynomials agree, but also their individual precisions as long as >> one of them is below the default precision of the ring. Accordingly the >> `is_zero` method should not return True if the individual precision is >> below the default precision. >> > > The default precision is just that: a default. It's used to get a finitely > presented result in cases where a computation could normally lead to a > non-finite one. The setting of the default doesn't affect the mathematical > properties of the elements. In particular, whether elements are equal or > not is determined by their direct properties, not by the default set in the > parent ring. Therefore, your expectation is not compatible with the design > (as you discovered). But perhaps by seeing how it was designed and why, > you'll warm to the design decisions made :-). > > The arithmetic model used is basically one of "interval" or "ball" > arithmetic: In terms of actual power series rings, an element like > 1+t+O(t^2) stands for the set of all power series with initial part 1+t. In > that model, "equality" gets translated to "have non-empty intersection". > > This model has the advantage that (sqrt(1+t)^2 -1)/t == 1 returns true, as > one would expect mathematically. > > (insisting equality up to the default precision would have to lead to > false, because the arithmetic on the LHS leads to precision loss) > > >> >> But this doesn't help for the following irritating answer (which was the >> original issue pointed out to me by Bill Hart): >> >> sage: R.<t>=PowerSeriesRing(ZZ) >> sage: S.<u>=PowerSeriesRing(R) >> sage: 0 + O(t) + O(u) >> O(u^1) >> >> >> > Indeed, but I think the actual bug there is: Power series rings over > non-exact base rings don't work properly. This is a problem that you should > expect: algebra algorithms normally designed to work with exact base rings > will have problems with non-exact ones, and usually for the reason you see > here: to work properly with power series over exact rings, you eliminate > (exact) zeros, but the inexact zeros that you encounter in power series > rings should probably be kept for precision tracking reasons (also the ones > up to default precision!). But keeping them around indiscriminately would > lead to impractical results very quickly. Special care is needed. You might > try working with ZZ[['t','u']] instead. > > (and indeed, power series rings with p-adic coefficients need a whole set > of extra care too -- and usually convergence properties on the coefficients > anyway to make meaningful arithmetic possible) > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/bb9e4728-e20e-467f-bd21-28e69befef11%40googlegroups.com.
