> >> Maybe someone who knows Maxima better could point us in the right
> >> direction?
>
> > d2 is defined in the testsuite for the Zeilberger algorithm. It is not
> > necessary to load the tests, in share/contrib/Zeilberger/
> > zeilberger.mac remove the last line which loads them.
>
> > Andrej
>
> Wow, that's pretty annoying. So we have:
>
> sage: d2 = var('d2')
> sage: d2.simplify()
> factorial(k + 3*n - 1)/factorial(2*k + 6*n)
>
> and even worse things like:
>
> sage: factorial = var('factorial')
> sage: factorial^3 + factorial/7 - 1
> factorial^3 + 1/7*factorial - 1
> sage: (factorial^3 + factorial/7 - 1).simplify()
> BOOM!
>
> --
>
> This could all be avoided if before changing a variable to maxima we
> prepended it with _sage_var_ (say), and stripped those off when moving
> from maxima back to Sage. This is worth considering...
Yeah, we might have to. See the following:
----------------------------------------------------------------------
| Sage Version 4.3.1.alpha2, Release Date: 2010-01-13 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
**********************************************************************
* *
* Warning: this is a prerelease version, and it may be unstable. *
* *
**********************************************************************
sage: from sage.calculus.calculus import maxima
sage: maxima.eval('values')
'[messlrats2,fullratsubstflag,dir,nonverbose,summary,very_verbose,extra,NO_HYP,HYP,PROOF_SILENT,PROOF_LOW,PROOF_MEDIUM,PROOF_HIGH,big_primes,max_ord,simplified_output,linear_solver,mod_test,modular_linear_solver,ev_point,mod_big_prime,mod_threshold,warnings,Gosper_in_Zeilberger,trivial_solutions,gs_prove_detail,zb_prove_detail,g1,g2,g3,g4,g5,g6,g7,f1,f2,f3,f4,f5,f6,f7,f8,f9,f10,h1,h2,h3,h4,h5,h6,h6b,h7,h8,h9,h10,h11,h12,h13,d1,d2,GOSPER_TEST,EASY_TEST,HARD_TEST,EXTREME_TEST,FULL_TEST,solve_rec_warn,simplify_products,normalize_products,distribute_products,simplify_products_deg,product_use_gamma,use_hyper,use_ratsol,hyper_factor_solve,hyper_all_solutions,hyper_to_product,solve_rec_method,shift_op,
%n,%f,%m,%l,%j,%k,%x,%u,
%z,zeilberger_check,sum_min,use_simpsum,use_harmonic,use_integral,use_gosper,use_ratfun,use_zeilberger,use_hgfred,simplify_sum_depth,simplify_sum_max_depth,verbose_level,harmonic_number_expand,sum_by_integral_transforms,sage0]'
Yikes - so g1-7, f1-10, h1-13, and d1, d2 are all pre-defined, not to
mention several other % guys.
These are the most likely candidates, so if Minh's fix gets rid of all
of them, that would be ideal and we might not have to do this.
Although 'extra' and 'big_primes' also seems like variables one might
actually use.
As to Craig's point, yes you can make another Maxima session, but in
general all internal Maxima use either uses _maxima_(), which calls
the "calculus" copy, or directly uses the "calculus" copy of Maxima.
For instance for assumptions we really want to only be using one
Maxima session.
Maybe Nils has a comment on whether library use of Maxima would make
it easier to work around this problem? I know he's hoping to do
something with this at the Bug Days.
- kcrisman
>
> Basically, right now, any time that one makes a symbolic variables
> that just *happens* to be the same as the name of a function defined
> in maxima's large global namespace, any symbolic calls to maxima
> involving that variable break. One could imagine e.g., writing code
> that works and uses an innocent sounding variable like x2 (say),
> upgrading maxima in a few months, and finding that the code suddenly
> doesn't work in arbitrarily confusing ways (since x2 could be defined
> in Maxima to be something entirely weird/crazy like "factorial(k + 3*n
> - 1)/factorial(2*k + 6*n)").
>
> Thoughts?
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
