Re: [sage-devel] Re: Why does - (x > 100) return -x > -100 ?
On Mon, 17 Dec 2012 18:15:57 -0800 Benjamin Jones wrote: > > It's hard to tell from the implementation if this behavior is > > intentional, unintentional, or a bug. The implementation is just > > that multiplication maps over relational operators like ==, <, <=, > > etc. But I think it's not possible in the current framework to make > > multiplication preserve the truth of a statement, e.g. > > > > if y > 0 is true, > > is x*(y > 0) true or false? > > > > You can't decide unless you know more about x. If you want to make > > multiplying by elements in SR preserve truth of a statement you > > have to decide this. > > > Sorry for the noise.. I meant to say (at the top) that from the > implementation (of sage.symbolic.expression.Expression._mul_) it's > pretty clear that this behavior *is* intentional, not a bug, but > that's not to say it's desirable in all situations. This was indeed intentional at the time. When writing the "new symbolics" code based on pynac, William and I thought that this behavior was the one that led to least confusion. Working with expression trees that involve relational objects can be confusing: > f = x < y; x -5*f; -5*(x sin(-5*f) + x^2; x^2+sin(-5*(xhttp://trac.sagemath.org/sage_trac/ticket/7660 It should just be a matter of removing the block starting with if is_a_relational(left._gobj): in the _mul_, _add_, etc. methods of sage.symbolic.expression.Expression. Patches are welcome. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Improve the autotools spkg (#13557) needs review
Could somebody please review this optional package? I think it's a useful improvement over the old autotools spkg. On 2012-10-03 21:27, Jeroen Demeyer wrote: > I have made a lot of fixes to my autotools spkg, essentially improving > it from a "proof of concept" to a "real" spkg. For this reason, I would > like to move the package from experimental to optional. > > The main change is that the package now ships an auto-generated Makefile > to build the various different versions of autotools, with correct > dependencies (e.g. autoconf-2.62 depends on automake-1.10). This made > the packaging process a lot more involved, but the spkg-install is much > simplified (it essentially just executes make). > > I added Texinfo to the package, since that's a prerequisite and it's > also often used for bootstrapping packages, so it fits with the theme. > > There are also a lot of small fixes to make the package more portable, > it no longer requires GNU-specific tools. Indeed, it now builds on all > buildbot systems that I tried (sage, rosemary, iras, bsd, moufang, mark, > hawk). > > Please review this *optional* package: > http://trac.sagemath.org/sage_trac/ticket/13557 > > Thanks, > Jeroen. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Apparent inconsistency between doctoring and behavior of module-related functions
Hi all, There seems to be an inconsistency between the docstrings and the actual behavior of some module-related methods. For instance, I am surprised by the behavior of the coordinates() method : sage: A = ZZ^3 sage: A.coordinates? … Definition: A.coordinates(self, v, check=True) Docstring: Write v in terms of the basis for self. …. "check" - bool (default: True); if True, also verify that v is really in self. …. If v is not in self, raises an "ArithmeticError" exception. sage: v = vector( [1/2, 1/3, 1/4] ) sage: v in A False sage: A.coordinates( v ) [1/2, 1/3, 1/4] # BIZARRE Shouldn't this raise the ArithmeticError exception, as advertised ? Looking at the code of this method reveals that it does: return self.coordinate_vector(v, check=check).list() A.coordinate_vector is presumably doing: Write v in terms of the standard basis for self and return the resulting coefficients in a vector over the fraction field of the base ring. ... If v is not in self, raises an ArithmeticError exception. And, presumably, it does not really implement this specification. Unless I am missing something, of course. Cheers, --- Charles Bouillaguet http://www.lifl.fr/~bouillaguet/ -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] How to update prereq spkg/script
The Cygwin port is being resurrected, and there is good work afoot. What we now need is (among other things) an update to the prereq spkg so that we can think about closing #6743. We need to somehow check for the following things on Cygwin: * `file` * `patch` * `liblapack`, `liblapack0`, `liblapack-devel` * `libiconv`, `openssl`, `openssl-devel` * `libgc-devel` * `zlib-devel` * `libncurses-devel` * `make`, `perl`, `m4` * `gcc4-x.y.z` and `g++-x.y.z`, `fortran`; the versions '''must''' match A lot! But how does one go about doing this? I assume that it should happen in `prereq-1.x-install` and not the configure, but I don't know a lot about these things. Is it sufficient to do if [ -a "/standard/path/to/Cygwin/lib/or/program.dll" ] ; then with a whole bunch of "ands"? Or is there some better way to do this? I'm already imagining regex horrors for making sure the compiler versions match... and it does seem like an awful lot to do in the prereq script, but maybe that's better than elsewhere. Thanks! Contributions welcome at #6743. - kcrisman -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Apparent inconsistency between doctoring and behavior of module-related functions
On 12/19/2012 12:28 AM, Charles Bouillaguet wrote: Hi all, There seems to be an inconsistency between the docstrings and the actual behavior of some module-related methods. For instance, I am surprised by the behavior of the coordinates() method : sage: A = ZZ^3 sage: A.coordinates? … Definition: A.coordinates(self, v, check=True) Docstring: Write v in terms of the basis for self. …. "check" - bool (default: True); if True, also verify that v is really in self. …. If v is not in self, raises an "ArithmeticError" exception. sage: v = vector( [1/2, 1/3, 1/4] ) sage: v in A False sage: A.coordinates( v ) [1/2, 1/3, 1/4] # BIZARRE Shouldn't this raise the ArithmeticError exception, as advertised ? Looking at the code of this method reveals that it does: return self.coordinate_vector(v, check=check).list() A.coordinate_vector is presumably doing: Write v in terms of the standard basis for self and return the resulting coefficients in a vector over the fraction field of the base ring. ... If v is not in self, raises an ArithmeticError exception. And, presumably, it does not really implement this specification. Unless I am missing something, of course. Cheers, --- Charles Bouillaguet http://www.lifl.fr/~bouillaguet/ It is consistent with whatever A.ambient_vector_space() is doing. There is even a doctest: sage: M = ZZ^3; sage: V = M.ambient_vector_space(); V Vector space of dimension 3 over Rational Field Since the "ambient vector space" is the Rational field, A.coordinates returns the rational numbers. I don't know what is meant by the term "ambient vector space" in this context. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] math.sx ad
See http://ask.sagemath.org/question/2079/a-place-to-advertise-sage?answer=2986#2986 Feel free to comment if you like it! -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
