Ticket #1196 (closed enhancement: fixed)
[with patch] inefficiency and inconsistency in calculus numerical conversion
|Reported by:||was||Owned by:||was|
> David Harvey did mention to > me that getting a numerical approximation of sqrt(2) called maxima, so That's not exactly true, since "Exiting Maxima..." is not printed out below: sage: float(sqrt(2)) 1.4142135623730951 sage: quit Exiting SAGE (CPU time 0m0.01s, Wall time 0m5.91s). What happens is that if one requests a numerical *float* approximation to sqrt(2), then first a float approximation to 2 is computed, then the math.sqrt method is called on it. Unfortunately, evidently right now if one requests a high-precision numerical approximation Sage currently does end up calling Maxima: sage: RealField(100) ( sqrt(2) ) 1.4142135623730950488016887242 sage: Exiting spawned Maxima process. I consider this a mistake in implementation, which should be optimized. Notice that sage: sqrt( RealField(100)(2) ) 1.4142135623730950488016887242 does not call Maxima anywhere. I just investigated, and n(sqrt(2), 100) calls maxima only to simplify sqrt(2) before even beginning to do any numerical approximation. This isn't consistent with how the other coercions (e.g., to float) work. So I've posted a patch that changes this behavior. After applying this patch: sage: RealField(100) ( sqrt(2) ) 1.4142135623730950488016887242 sage: quit (no "exiting maxima")
NOTE: I've attached two patches. The first implements the change described above. The second fixes some resulting doctest failures, and also optimizes computation of sec, csc, and cot for mpfr elements.
- Summary changed from inefficiency and inconsistency in calculus numerical conversion to [with patch] inefficiency and inconsistency in calculus numerical conversion