Dear Fredrik, One technical question: I thought that your ca_t implementation used multivariate polynomials. This is what Magma does but not what sage does. The latter uses expression trees and take union fields anytime there is an exactification to be done. Is it a misconception of mine?
For "real world" problems 1) algebraic solutions of zero dimensional varieties defined over QQ sage: R.<x,y,z> = QQ[] sage: A = x^4 + y^4 + z^3 - 1 sage: B = x^2*z + 2*y^2*x - x*y*z + 5 sage: C = y*z^2 - 2*(x+y+z) + 2 sage: %time solutions = R.ideal([A,B,C]).variety(QQbar) CPU times: user 24.3 s, sys: 23.3 ms, total: 24.3 s Wall time: 24.4 s Though here is the bottleneck is Groebner basis computation of multivariate polynomials and not really QQbar (21s over the 24s). 2) Two examples somehow similar to your huge_expr sage: a = sum(AA(p).sqrt() for p in prime_range(18)) sage: %time a.exactify() CPU times: user 30.7 s, sys: 13.3 ms, total: 30.8 s Wall time: 30.8 s sage: a.degree() # does not terminates In the above situation, the problem is that sage is representing the number a as a complicated element in a rather complicated number field. Computing the minpoly involves apparently too complicated linear algebra (?). However, if instead of exactifying in that way but using the minimal polynomial (which looks reasonable in this range of degrees) the latter would be very quick. sage: b = sum(QQbar.zeta(n) for n in range(1,8)) sage: b.exactify() # does not terminate Here sage is stuck at building union fields. Would be nice to have calcium used in sage! Best Vincent Le 25/04/2021 à 15:07, Fredrik Johansson a écrit :
Hi all, I'm looking for benchmark problems for QQbar/AA arithmetic. Ideally such a problem will: * Be reducible to a short program that, apart from using QQbar/AA operations, is reasonably self-contained. * Reflect real-world use, i.e. originate from using Sage to solve an actual mathematical problem, with QQbar/AA arithmetic being a significant ingredient. I'm interested in such benchmark problems to evaluate how well Calcium ( https://fredrikj.net/calcium/) would work to implement the field of algebraic numbers. As such, I'd like to identify any situations where Calcium is slower than Sage's QQbar or where functionality missing. There are actually two independent types that may serve to implement the field of algebraic numbers: qqbar_t and ca_t. A Calcium qqbar_t uses an "absolute" representation (minimal polynomial), which is nice since results are kept reduced and canonical, but can be slow for field arithmetic. A Calcium ca_t uses a "relative" representation involving symbolic expressions and number fields, somewhat similar to Sage's QQbar or Magma's algebraically closed field. The ca_t type should give the best performance in most cases, but qqbar_t may be better in some circumstances. Some benchmark problems I've collected so far: huge_expr (https://ask.sagemath.org/question/52653/) ==================================================== sage qqbar: ~forever (hours) calcium qqbar: 8.5 s calcium ca: 8.1 s heptadecagon (sage/rings/qqbar.py) ==================================================== sage qqbar: ~forever (hours) calcium qqbar: 2.11 s calcium ca: 0.011 s heptadecagon2 (sage/rings/qqbar.py) ==================================================== sage qqbar: 0.060 s calcium qqbar: 2.11 s calcium ca: 0.0031 s symbench_R1 (https://wiki.sagemath.org/symbench) ==================================================== sage qqbar (numerical answer): 0.0041 s sage qqbar (exactify): 0.049 s calcium qqbar: 0.095 s calcium ca (numerical answer): 0.0010 s calcium ca (qqbar output) 0.057 s Fredrik
-- 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/695302b4-4699-b346-2298-7413f20c90b0%40gmail.com.
