Re: [sage-combinat-devel] sage 5.10 queue fail
Hi Travis, On Mon, Jul 01, 2013 at 02:38:18PM -0700, Travis Scrimshaw wrote: I think the first one is due to me import the latest version of the iet move patch #8386; thus should be a simple rebase (and I don't think anyone has touched that in a while). The second one is likely due to our work (Arthur and me) on #14772 and/or #14101 and is likely trivial. Trivial but annoying. With the current workflow, it is your responsibility to test that the whole queue applies (if needed by disabling stuff that need rebase and letting the author know) before pushing stuff. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Skew tableaux
On Monday, 1 July 2013 21:06:46 UTC+2, darijgrinberg wrote: This isn't the only thing missing, and it seems that skew_tableau.py never got the love that tableau.py received during development. One many things that skew tableaux (and skew partitions) are currently missing is a latex method. As part of a review of Travis huge categorification patch for partitons I updated sage.combinat.output.py so that the routines there now work for skew tableaux (and diagrams of skew partitions) but we didn't add the corresponding methods to skew tableaux. If any one wants these, I think that it is enough to simply copy the corresponding routines across from the non-skew classes, although there will be some trickery due to the global option classes...I'm fairly snowed under at the minute, but if there is sufficient demand I could look in to this. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Installing combinat queue
Thank Travis. I am compiling from source of course. The problem might be
that bash install function I wrote uses make all rarher than just make,
which is what I used to do by handaccorrding to the makefile these
should be equivalent but it is the only difference I can see. Will test
when I have access to a proper internet connection again.
A.
On Friday, 28 June 2013 13:55:38 UTC+2, Travis Scrimshaw wrote:
Hey Andrew,
Are you compiling it from source code or using the prebuilt? Because I
believe building the doc is built during the compilation. As for the
prebuilts, since sage now copies over the doc (previously it just rebuilt
it) and it may not be included in; so look in your sage/doc/output... to
see if there is doc already built. If not, then I guess you'll have to
build the doc first (or at least put a temp folder) and we'll need to make
a ticket on this (likely a blocker).
Best,
Travis
On Friday, June 28, 2013 11:03:26 AM UTC+2, Andrew Mathas wrote:
Hi All,
Whenever I try installing the combinat queue on top of a new verion tehse
days I run into an error like this:
MacAndrew-528-(sage-5.10)-combinat: sage -combinat install
Creating sage-combinat branch:
/usr/local/src/sage/sage-5.10/sage -b main
--
sage: Building and installing modified Sage library files.
Installing c_lib
/usr/local/src/sage/sage-5.10/devel/sage/c_lib
g++ -o libcsage.dylib -single_module -flat_namespace -undefined
dynamic_lookup -dynamiclib src/convert.os src/interrupt.os src/memory.os
src/mpn_pylong.os src/mpz_pylong.os src/mpz_longlong.os src/stdsage.os
src/gmp_globals.os src/ZZ_pylong.os src/ntl_wrap.os
-L/usr/local/src/sage/sage-5.10/local/lib
-L/usr/local/src/sage/sage-5.10/local/lib/python2.7/config -lntl -lpari
-lgmp -lpython2.7
Updating Cython code
Compiling sage/libs/lrcalc/lrcalc.pyx because it changed.
Cythonizing sage/libs/lrcalc/lrcalc.pyx
Finished compiling Cython code (time = 10.7281630039 seconds)
running install
running build
running build_py
running build_ext
building 'sage.libs.lrcalc.lrcalc' extension
Executing 1 command (using 1 thread)
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-I/usr/local/src/sage/sage-5.10/local/include/lrcalc/
-I/usr/local/src/sage/sage-5.10/local/include
-I/usr/local/src/sage/sage-5.10/local/include/csage
-I/usr/local/src/sage/sage-5.10/devel/sage
-I/usr/local/src/sage/sage-5.10/devel/sage/sage/ext
-I/usr/local/src/sage/sage-5.10/local/include
-I/usr/local/src/sage/sage-5.10/local/include/csage
-I/usr/local/src/sage/sage-5.10/devel/sage
-I/usr/local/src/sage/sage-5.10/devel/sage/sage/ext
-I/usr/local/src/sage/sage-5.10/local/include/python2.7 -c
sage/libs/lrcalc/lrcalc.c -o
build/temp.macosx-10.7-x86_64-2.7/sage/libs/lrcalc/lrcalc.o -w
gcc -bundle -undefined dynamic_lookup
-L/usr/local/src/sage/sage-5.10/local/lib
build/temp.macosx-10.7-x86_64-2.7/sage/libs/lrcalc/lrcalc.o
-L/usr/local/src/sage/sage-5.10/local/lib -lcsage -llrcalc -lstdc++ -lntl
-o build/lib.macosx-10.7-x86_64-2.7/sage/libs/lrcalc/lrcalc.so
Time to execute 1 command: 2.87031507492 seconds
Total time spent compiling C/C++ extensions: 3.05725002289 seconds.
running install_lib
copying build/lib.macosx-10.7-x86_64-2.7/sage/libs/lrcalc/lrcalc.so -
/usr/local/src/sage/sage-5.10/local/lib/python2.7/site-packages/sage/libs/lrcalc
running install_egg_info
Removing
/usr/local/src/sage/sage-5.10/local/lib/python2.7/site-packages/sage-0.0.0-py2.7.egg-info
Writing
/usr/local/src/sage/sage-5.10/local/lib/python2.7/site-packages/sage-0.0.0-py2.7.egg-info
real 21.433user 6.020sys 1.829pcpu 36.61
/usr/local/src/sage/sage-5.10/sage -clone combinat
Now cloning the current Sage library branch...
hg clone sage sage-combinat
updating to branch default
2973 files updated, 0 files merged, 0 files removed, 0 files unresolved
Copying over all Cython auto-generated .c, .cpp and .h files...
Copying over hidden Cython version file...
Copying over build directory...
Copying over all auto-generated reference manual .rst files...
Copying over documentation output...
Traceback (most recent call last):
File /usr/local/src/sage/sage-5.10/local/bin/sage-clone, line 101, in
module
shutil.copytree('sage/doc/output', branch + '/doc/output',
symlinks=True)
File /usr/local/src/sage/sage-5.10/local/lib/python/shutil.py, line
171, in copytree
names = os.listdir(src)
OSError: [Errno 2] No such file or directory: 'sage/doc/output'
real 47.575user 5.615sys 3.598pcpu 19.36
Abort
Does this mean that I need to build the documentation before installing
the combinat queue or am I doing something else wrong?
Andrew
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
Re: [sage-devel] Re: Sqrt simplification
Le mardi 2 juillet 2013 02:38:44 UTC+2, rjf a écrit : What you've written is just a hack. Of course it's a hack; this is why I did not submit it as a patch for Sage. As far as one restricts oneself to the REAL DOMAIN, I think it works. Please show me a counter-example. Again, let me insist: it is elementary mathematics that sqrt: R+ -- R+, x |-- sqrt(x) is a ONE-TO-ONE map, the reverse of which is R+ -- R+, x |-- x^2 I think everybody agrees that when working only with real variables, this is the standard meaning of the sqrt function. Then it must obey sqrt(x^2) = abs(x) and the above hack simply ensures this. This is why I called it 'simplify_sqrt_real' to insist that it is valid only for REAL-valued expressions of REAL variables. -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: (abs(sin(x))^2).simplify_full()
Hi Michael,
Thanks for your message. I'm still a little confused about the way Sage
handles assumptions, can you maybe shine your light on this?
On Monday, July 1, 2013 8:55:43 PM UTC+1, Michael Orlitzky wrote:
sage: u = var('u')
sage: assume(u, 'real')
This makes an assumption in Maxima, where most of the symbolic algebra
takes place.
As far as I can tell, setting domain to complex in maxima has the effect
that sin, cos, etc are now seen as de facto complex-valued functions, even
when the input x is assumed to be real. This is probably why maxima refuses
to simplify abs(cos(x))^2 + abs(sin(x))^2 to 1.
sage: u = var('u', domain='real')
This sets a flag in pynac, which does nothing as far as I can tell.
But the example in my original message works -- this really confuses me.
Clearly, simplify_trig invokes maxima to do the simplification, so why does
setting this flag in pynac make it work? Are functions of real variables
treated differently from functions taking a complex argument?
Thanks!
Joris
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: (abs(sin(x))^2).simplify_full()
But the example in my original message works -- this really confuses me. Clearly, simplify_trig invokes maxima to do the simplification, so why does setting this flag in pynac make it work? Are functions of real variables treated differently from functions taking a complex argument? OK, I understand this now -- when defining a function of a real argument the abs is simply not taken into account because of the square following it, so that the trig simplification can take its course as before. I still think it would be a good idea to have the simplify_* methods take into account the domain of definition to avoid problems like this. Presumably I'm missing a whole lot of context here, feel free to point me to tickets where the opposite point has been made. J. -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Changes in Maxima behavior
On 2013-07-01, Joris Vankerschaver joris.vankerscha...@gmail.com wrote:
sage: u, v = var('u, v', domain='real')
sage: sqrt(-1/(u^2+v^2-1)).simplify_radical() # This will hang
This is a bug in Maxima:
(%i2) radcan (sqrt (-1 / (u^2 + v^2 - 1))), domain=complex;
It waits apparently forever here -- but it is actually looping over
*ALPHA (not sure why) which is a large prime number (8388593).
(%i3) :lisp (setq *alpha 17)
17
(%i3) radcan(sqrt(-1/(u^2+v^2-1))), domain=complex;
(%o3) 1/sqrt(-v^2-u^2+1)
I've reported this as bug # 2605.
best
Robert Dodier
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: problems installing TOPCOM for triangulations?
On 7/1/2013 8:42 PM, Volker Braun wrote: You need to restart the notebook since the test output is cached... Yes, that seems to have solved the problem. You might want to add a note to this effect in the documentation for Triangulations of a point configuration. --Ursula. -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: problems installing TOPCOM for triangulations?
I agree that this is a usability wart... though really I think the whole idea of installing further components while Sage is running is a bad design choice. For example, if you end up modifying shared libraries that are currently mmaped then bad things will happen. On Tuesday, July 2, 2013 2:26:03 PM UTC-4, Ursula wrote: On 7/1/2013 8:42 PM, Volker Braun wrote: You need to restart the notebook since the test output is cached... Yes, that seems to have solved the problem. You might want to add a note to this effect in the documentation for Triangulations of a point configuration. --Ursula. -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Sqrt simplification
On Tuesday, July 2, 2013 4:48:54 AM UTC-7, Eric Gourgoulhon wrote: Le mardi 2 juillet 2013 02:38:44 UTC+2, rjf a écrit : What you've written is just a hack. Of course it's a hack; this is why I did not submit it as a patch for Sage. As far as one restricts oneself to the REAL DOMAIN, I think it works. Please show me a counter-example. Again, let me insist: it is elementary mathematics that sqrt: R+ -- R+, x |-- sqrt(x) is a ONE-TO-ONE map, the reverse of which is R+ -- R+, x |-- x^2 I think everybody agrees that when working only with real variables, this is the standard meaning of the sqrt function. Then it must obey sqrt(x^2) = abs(x) and the above hack simply ensures this. This is why I called it 'simplify_sqrt_real' to insist that it is valid only for REAL-valued expressions of REAL variables. If you called the function in question real positive branch of the square root of a positive number rather than sqrt, maybe you might get agreement. Let's call that RPBSRPN. Your statement then translates to RPBSRPN(x^2) = abs(x) . But then if it ir R+--R+, the abs() is unnecessary, and RPBSRPN(x^2) = x. Surely you don't believe that sqrt of positive numbers are always positive. (for the movie clip from Airplane -- Surely you can't be serious -- see http://www.ign.com/top/movie-moments/88 ) For example you can then derive the quadratic formula and show that a quadratic equation has only one root. (Or only has a single root if b^2-4ac 0, your constraint. As I suggested, you are free to come up with some other function, perhaps absqrt() with your specified behavior, but I would expect it to be of limited use. -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
