[sage-devel] Bug with vars()?
Dear all, My Sage 6.6 install quits after printing a depreciation warning message when I issue: sage: vars() Same is true for at least globals(). Any clue on what's going on? Best, JP -- 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/d/optout.
[sage-devel] Re: Please review ticket #18128 -- Face truncation of polyhedron
Hi again, The ticket is again ready for review! http://trac.sagemath.org/ticket/18128 Thanks!! JP -- 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/d/optout.
Re: [sage-devel] Re: Please review ticket #18128 -- Face truncation of polyhedron
On 2015-05-06 11:04, jplab wrote: Hi again, The ticket is again ready for review! ... just like 225 other tickets. -- 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/d/optout.
[sage-devel] Re: Bug with vars()?
There were some changes to how globals() are handled. Did you run make, can you show us the output, debugger, ... On Wednesday, May 6, 2015 at 10:51:27 AM UTC+2, Jean-Pierre Flori wrote: Dear all, My Sage 6.6 install quits after printing a depreciation warning message when I issue: sage: vars() Same is true for at least globals(). Any clue on what's going on? Best, JP -- 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/d/optout.
[sage-devel] Re: Bug with vars()?
Jean-Pierre Flori wrote: My Sage 6.6 install quits after printing a depreciation warning message when I issue: sage: vars() Works for me: ... 'zeta': zeta, 'zeta__exact': function zeta__exact at 0x7fa3b8c84b90, 'zeta_symmetric': function zeta_symmetric at 0x7fa3bac2f9b0, 'zeta_zeros': function zeta_zeros at 0x7fa273519aa0, 'zetaderiv': zetaderiv} --- TypeError Traceback (most recent call last) ipython-input-1-ef3ed5b882d8 in module() 1 vars() /data/Sage/release/stable/sage-6.6-gcc-4.9.2-default/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc in __call__(self, result) 230 self.start_displayhook() 231 self.write_output_prompt() -- 232 format_dict, md_dict = self.compute_format_data(result) 233 self.update_user_ns(result) 234 self.fill_exec_result(result) TypeError: 'NoneType' object is not iterable sage: (Same in 4.7.beta4, FWIW. globals() doesn't throw.) Same is true for at least globals(). Any clue on what's going on? No. :-) -leif -- 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/d/optout.
Re: [sage-devel] CategoryObject vs. Parent
In the same vein, shouldn't base_ring be removed from Parent as well ? sage: Set([1,2,3]).base_ring() The return value is None, which is arguably correct, for a generic set has no base ring, but it might be surprising when using tab completion to discover functionalities to see that a base_ring() method exists for such objects. +1 to that. Many other methods of Parent should be moved somewhere else (is_exact, inject_variables,gens_dict* Moreover, many method names shoulf be changed (made longer, more explicit): while the meaning of Parent.a_method can be clear, it is at times very difficult, when listing the methods of a more specific object, to understand what the same method does. Because then it is not obvious at all that a_method refers to the object 'understood as a Parent'. When you have a poset or a group in yours hands, your think of it as a group, and not necessarily as a parent. Nathann -- 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/d/optout.
Re: [sage-devel] Re: Bug with vars()?
I also have a 6.6 install which quites badly when I give (as the first command) vars(). The output is hunderds of lines long and ends with TypeError Traceback (most recent call last) ipython-input-1-ef3ed5b882d8 in module() 1 vars() /usr/local/sage/sage-2/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc in __call__ (self, result) 230 self.start_displayhook() 231 self.write_output_prompt() -- 232 format_dict, md_dict = self.compute_format_data(result) 233 self.update_user_ns(result) 234 self.fill_exec_result(result) TypeError: 'NoneType' object is not iterable On 6 May 2015 at 11:26, Volker Braun vbraun.n...@gmail.com wrote: There were some changes to how globals() are handled. Did you run make, can you show us the output, debugger, ... On Wednesday, May 6, 2015 at 10:51:27 AM UTC+2, Jean-Pierre Flori wrote: Dear all, My Sage 6.6 install quits after printing a depreciation warning message when I issue: sage: vars() Same is true for at least globals(). Any clue on what's going on? Best, JP -- 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/d/optout. -- 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/d/optout.
Re: [sage-devel] Re: Bug with vars()?
On 6 May 2015 at 12:49, Volker Braun vbraun.n...@gmail.com wrote: vars() works as documented. Its a good test whether every object that we define can actually print That sounds like a good thing, but I still do not understand why an error is raised. John itself. That caughs up plenty of deprecation warnings and fails for sage: notebook sagenb.notebook.notebook_object.NotebookObject instance at 0x7fbf8537e758 --- TypeError Traceback (most recent call last) ipython-input-1-608e12875613 in module() 1 notebook /mnt/disk/home/release/Sage/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc in __call__(self, result) 230 self.start_displayhook() 231 self.write_output_prompt() -- 232 format_dict, md_dict = self.compute_format_data(result) 233 self.update_user_ns(result) 234 self.fill_exec_result(result) TypeError: 'NoneType' object is not iterable On Wednesday, May 6, 2015 at 1:16:49 PM UTC+2, John Cremona wrote: I also have a 6.6 install which quites badly when I give (as the first command) vars(). The output is hunderds of lines long and ends with TypeError Traceback (most recent call last) ipython-input-1-ef3ed5b882d8 in module() 1 vars() /usr/local/sage/sage-2/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc in __call__ (self, result) 230 self.start_displayhook() 231 self.write_output_prompt() -- 232 format_dict, md_dict = self.compute_format_data(result) 233 self.update_user_ns(result) 234 self.fill_exec_result(result) TypeError: 'NoneType' object is not iterable On 6 May 2015 at 11:26, Volker Braun vbrau...@gmail.com wrote: There were some changes to how globals() are handled. Did you run make, can you show us the output, debugger, ... On Wednesday, May 6, 2015 at 10:51:27 AM UTC+2, Jean-Pierre Flori wrote: Dear all, My Sage 6.6 install quits after printing a depreciation warning message when I issue: sage: vars() Same is true for at least globals(). Any clue on what's going on? Best, JP -- 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+...@googlegroups.com. To post to this group, send email to sage-...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout. -- 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/d/optout.
Re: [sage-devel] Re: Bug with vars()?
Technically its because * notebook is a lazy import, * printing notebook causes sagenb to be imported * which changes the displayhook to the SageNB displayhook which causes various problems. On Wednesday, May 6, 2015 at 1:58:45 PM UTC+2, John Cremona wrote: On 6 May 2015 at 12:49, Volker Braun vbrau...@gmail.com javascript: wrote: vars() works as documented. Its a good test whether every object that we define can actually print That sounds like a good thing, but I still do not understand why an error is raised. John itself. That caughs up plenty of deprecation warnings and fails for sage: notebook sagenb.notebook.notebook_object.NotebookObject instance at 0x7fbf8537e758 --- TypeError Traceback (most recent call last) ipython-input-1-608e12875613 in module() 1 notebook /mnt/disk/home/release/Sage/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc in __call__(self, result) 230 self.start_displayhook() 231 self.write_output_prompt() -- 232 format_dict, md_dict = self.compute_format_data(result) 233 self.update_user_ns(result) 234 self.fill_exec_result(result) TypeError: 'NoneType' object is not iterable On Wednesday, May 6, 2015 at 1:16:49 PM UTC+2, John Cremona wrote: I also have a 6.6 install which quites badly when I give (as the first command) vars(). The output is hunderds of lines long and ends with TypeError Traceback (most recent call last) ipython-input-1-ef3ed5b882d8 in module() 1 vars() /usr/local/sage/sage-2/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc in __call__ (self, result) 230 self.start_displayhook() 231 self.write_output_prompt() -- 232 format_dict, md_dict = self.compute_format_data(result) 233 self.update_user_ns(result) 234 self.fill_exec_result(result) TypeError: 'NoneType' object is not iterable On 6 May 2015 at 11:26, Volker Braun vbrau...@gmail.com wrote: There were some changes to how globals() are handled. Did you run make, can you show us the output, debugger, ... On Wednesday, May 6, 2015 at 10:51:27 AM UTC+2, Jean-Pierre Flori wrote: Dear all, My Sage 6.6 install quits after printing a depreciation warning message when I issue: sage: vars() Same is true for at least globals(). Any clue on what's going on? Best, JP -- 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+...@googlegroups.com. To post to this group, send email to sage-...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- 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+...@googlegroups.com javascript:. To post to this group, send email to sage-...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout.
[sage-devel] Checking if a set is gcd closed
It is of course just about oneliner to check if a set is gcd closed or not. But would it be useful to have is_gcd_closed() as a Sage built-in function? -- Jori Mäntysalo
Re: [sage-devel] Re: Bug with vars()?
vars() works as documented. Its a good test whether every object that we define can actually print itself. That caughs up plenty of deprecation warnings and fails for sage: notebook sagenb.notebook.notebook_object.NotebookObject instance at 0x7fbf8537e758 --- TypeError Traceback (most recent call last) ipython-input-1-608e12875613 in module() 1 notebook /mnt/disk/home/release/Sage/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc in __call__(self, result) 230 self.start_displayhook() 231 self.write_output_prompt() -- 232 format_dict, md_dict = self.compute_format_data(result) 233 self.update_user_ns(result) 234 self.fill_exec_result(result) TypeError: 'NoneType' object is not iterable On Wednesday, May 6, 2015 at 1:16:49 PM UTC+2, John Cremona wrote: I also have a 6.6 install which quites badly when I give (as the first command) vars(). The output is hunderds of lines long and ends with TypeError Traceback (most recent call last) ipython-input-1-ef3ed5b882d8 in module() 1 vars() /usr/local/sage/sage-2/local/lib/python2.7/site-packages/IPython/core/displayhook.pyc in __call__ (self, result) 230 self.start_displayhook() 231 self.write_output_prompt() -- 232 format_dict, md_dict = self.compute_format_data(result) 233 self.update_user_ns(result) 234 self.fill_exec_result(result) TypeError: 'NoneType' object is not iterable On 6 May 2015 at 11:26, Volker Braun vbrau...@gmail.com javascript: wrote: There were some changes to how globals() are handled. Did you run make, can you show us the output, debugger, ... On Wednesday, May 6, 2015 at 10:51:27 AM UTC+2, Jean-Pierre Flori wrote: Dear all, My Sage 6.6 install quits after printing a depreciation warning message when I issue: sage: vars() Same is true for at least globals(). Any clue on what's going on? Best, JP -- 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+...@googlegroups.com javascript:. To post to this group, send email to sage-...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout.
[sage-devel] timeit in the cloud vs terminal
Hi!
Compare the following code in the command line and the cloud:
In the terminal:
sage: t=timeit('factor(ZZ.random_element(10^40))', seconds=True)
sage: t
0.019134044647216797
sage: type(t)
type 'float'
In the cloud:
sage: t=timeit('factor(ZZ.random_element(10^40))', seconds=True)
0.0210275173187
sage: type(t)
type 'NoneType'
Is that normal that the timeit in the file sage_salvus.py does not return a
float when the keyword seconds is set to True?
Thank you very much!
--
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/d/optout.
Re: [sage-devel] Checking if a set is gcd closed
On Wed, 6 May 2015, John Cremona wrote: But would it be useful to have is_gcd_closed() as a Sage built-in function? I have not come across this function before (and I am a number theorist!). I am guessing on what it means: applied to a set of integers (?) or positive integers, it checks whether the gcd of any two is also in the set? Yep. There was for example a hypothesis -- Bourque-Ligh conjecture -- that the lcm matrix of a gcd closed set of integers is always invertible (which is false in general, but true when the set has at most 7 elements). One problem I see is that you would want it to be a global function, rather than a member function of some class (which class?), which is rather a negative for a specialised function. I hope you do not mind me calling it that since I have never needed such a function in around 40 years of number-theoretic computations! Yes, the problem of global namespace is a problem. So I will forget this. -- Jori Mäntysalo
Re: [sage-devel] timeit in the cloud vs terminal
On Wed, May 6, 2015 at 7:03 AM, jplab jeanphilippela...@gmail.com wrote:
Hi!
Compare the following code in the command line and the cloud:
In the terminal:
sage: t=timeit('factor(ZZ.random_element(10^40))', seconds=True)
sage: t
0.019134044647216797
sage: type(t)
type 'float'
In the cloud:
sage: t=timeit('factor(ZZ.random_element(10^40))', seconds=True)
0.0210275173187
sage: type(t)
type 'NoneType'
Is that normal that the timeit in the file sage_salvus.py does not return a
float when the keyword seconds is set to True?
Thank you very much!
Thanks -- this is definitely a bug in SageMathCloud.
William
--
William (http://wstein.org)
--
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/d/optout.
Re: [sage-devel] Checking if a set is gcd closed
On 6 May 2015 at 13:32, Jori Mäntysalo jori.mantys...@uta.fi wrote: It is of course just about oneliner to check if a set is gcd closed or not. But would it be useful to have is_gcd_closed() as a Sage built-in function? I have not come across this function before (and I am a number theorist!). I am guessing on what it means: applied to a set of integers (?) or positive integers, it checks whether the gcd of any two is also in the set? One problem I see is that you would want it to be a global function, rather than a member function of some class (which class?), which is rather a negative for a specialised function. I hope you do not mind me calling it that since I have never needed such a function in around 40 years of number-theoretic computations! John -- Jori Mäntysalo -- 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/d/optout.
Re: [sage-devel] Re: Bug with vars()?
I unpacked the sage 6.6 tarball and ran make. I'll have some trouble posting the exact output here as the machine is not connected to the network, but basically: * I'm on an amd64 Ubuntu 14.04.2 LTS. * I launch: sage * I type at Sage's prompt: vars() * I get: /blablabla/pretty_print.py:147: DepreciationWarning: this is being removed from the global namespace. Use crystals.tab instead See http://trac.sagemath.org/15882 for details. ok = representation(obj, self, cycle) * I'm back at my shell. I'll have to build gdb to get further info. With 6.2 and 6.3 and 6.5, it works but before everything gets printed I see lots of this warning with slight variations in the line causing it. With 6.1.1 no warning, I guess 15882 was merged later. Anyway, it was a false alarm. I deleted my .sage directory and now it works: I get an error as others do. -- 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/d/optout.
Re: [sage-devel] Re: Bug with vars()?
On 2015-05-06 14:09, Volker Braun wrote: Technically its because * notebook is a lazy import, * printing notebook causes sagenb to be imported * which changes the displayhook to the SageNB displayhook which causes various problems. I guess that's a bug. Simply *importing* sagenb should not change the displayhook. -- 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/d/optout.
Re: [sage-devel] build sage-6.6 R fail
Hi,
Thanks for the feedback.I decided to (1) use sage-6.7.beta4, and
(2) upgrade to Ubuntu-15.04. The Sage build has gone perfectly with
this combination.
-- William
On Wed, May 6, 2015 at 8:32 AM, John Foster jfoster81...@gmail.com wrote:
Just a suggestion:
Try a different make, as you know there are several. I see at the bottom
there is a core dump but no justification. Could be a memory addressing
issue. best wishes.
On 05/04/2015 01:43 AM, William Stein wrote:
Hi,
I'm trying to build Sage-6.6 on the latest Ubuntu 14.10
(SageMathCloud). The first problem was with libgd, which another
patch somebody posted May 1 got past. Now there is some mysterious
error/crash when building R which means nothing to me. See attached
log. I'm building with MAKE not set and a very high RAM/cpu quota...
gcc -std=gnu99 -shared -L../../../../lib
-L/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/lib/
-o tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o
http.o gramLatex.o gramRd.o -L../../../../lib -lR
make[9]: Entering directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools/src'
mkdir -p -- ../../../../library/tools/libs
make[9]: Leaving directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools/src'
make[8]: Leaving directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools/src'
make[7]: Leaving directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools'
/bin/bash: line 1: 11246 Doneecho
tools:::.install_package_description('.',
'../../../library/tools')
11247 Aborted (core dumped) |
R_DEFAULT_PACKAGES=NULL ../../../bin/R --vanilla --slave /dev/null
Makefile:30: recipe for target 'all' failed
--
John Foster
JW Foster Associates
--
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/d/optout.
--
William (http://wstein.org)
--
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/d/optout.
[sage-devel] Re: Catalog of algebras: the definition of an algebra
Hello, Travis Scrimshaw wrote: On #15635, we are trying to decide whether we want non-associative algebras to be included in the catalog of algebras. For a general mathematical software system such as Sage, I think it is overly restrictive to impose the rule that algebras are associative. There are too many interesting non-associative algebras (such as Lie algebras), or non-unital algebras (such as certain Hecke algebras) to make associativity part of the definition of an algebra. Moreover, it is in my opinion an unfortunate choice of terminology if non-associative algebras are not in general algebras. The argument against including them is most people think of algebras as being associative (and maybe even unital), and as such, might surprise people when they come across the non-associativity in their computations. Anyone has the right to think of algebras as being associative, just like many people think of vector spaces as being finite-dimensional, say. This is a bit like books or papers using the convention that all the algebras that one considers are assumed to be associative (or that vector spaces are assumed to be finite-dimensional, etc.) However, it feels wrong to elevate such conventions to definitions. However, the community was at one point considering renaming magmatic algebras into algebras and having to specify the associative axiom explicitly. I would be in favour of this. When finite-dimensional algebras over a field were implemented in #12141, we explicitly included non-associative algebras. In case the user already knows that his algebra is associative, he can pass a flag assume_associative (default: False) to avoid a lengthy computation to check this. Peter -- 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/d/optout.
[sage-devel] Problem while compiling
Hello, I have tried to compile sage from sources but it does not work. Attached is a log of the last part of the compiling output. My OS is a Linux Mint 17 64 bits. Thanks in advance for any help. Christophe -- 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/d/optout. /bin/bash ./libtool --tag=CC --mode=link /home/christophe/math/sage-6.6/local/var/tmp/sage/build/gcc-4.9.2.p1/gcc-build/./gcc/xgcc -B/home/christophe/math/sage-6.6/local/var/tmp/sage/build/gcc-4.9.2.p1/gcc-build/./gcc/ -B/home/christophe/math/sage-6.6/local/x86_64-unknown-linux-gnu/bin/ -B/home/christophe/math/sage-6.6/local/x86_64-unknown-linux-gnu/lib/ -isystem /home/christophe/math/sage-6.6/local/x86_64-unknown-linux-gnu/include -isystem /home/christophe/math/sage-6.6/local/x86_64-unknown-linux-gnu/sys-include -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -o libcaf_single.la -static -rpath /home/christophe/math/sage-6.6/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2 single.lo -lm libtool: link: ar rc .libs/libcaf_single.a single.o libtool: link: ranlib .libs/libcaf_single.a libtool: link: ( cd .libs rm -f libcaf_single.la ln -s ../libcaf_single.la libcaf_single.la ) /bin/bash ./libtool --tag=CC --mode=compile /home/christophe/math/sage-6.6/local/var/tmp/sage/build/gcc-4.9.2.p1/gcc-build/./gcc/xgcc -B/home/christophe/math/sage-6.6/local/var/tmp/sage/build/gcc-4.9.2.p1/gcc-build/./gcc/ -B/home/christophe/math/sage-6.6/local/x86_64-unknown-linux-gnu/bin/ -B/home/christophe/math/sage-6.6/local/x86_64-unknown-linux-gnu/lib/ -isystem /home/christophe/math/sage-6.6/local/x86_64-unknown-linux-gnu/include -isystem /home/christophe/math/sage-6.6/local/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libgfortran -iquote../../../src/libgfortran/io -I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config -I../../../src/libgfortran/../libquadmath -I../.././gcc -I../../../src/libgfortran/../libgcc -I../libgcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT fmain.lo -MD -MP -MF .deps/fmain.Tpo -c -o fmain.lo ../../../src/libgfortran/fmain.c libtool: compile: /home/christophe/math/sage-6.6/local/var/tmp/sage/build/gcc-4.9.2.p1/gcc-build/./gcc/xgcc -B/home/christophe/math/sage-6.6/local/var/tmp/sage/build/gcc-4.9.2.p1/gcc-build/./gcc/ -B/home/christophe/math/sage-6.6/local/x86_64-unknown-linux-gnu/bin/ -B/home/christophe/math/sage-6.6/local/x86_64-unknown-linux-gnu/lib/ -isystem /home/christophe/math/sage-6.6/local/x86_64-unknown-linux-gnu/include -isystem /home/christophe/math/sage-6.6/local/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libgfortran -iquote../../../src/libgfortran/io -I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config -I../../../src/libgfortran/../libquadmath -I../.././gcc -I../../../src/libgfortran/../libgcc -I../libgcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT fmain.lo -MD -MP -MF .deps/fmain.Tpo -c ../../../src/libgfortran/fmain.c -fPIC -DPIC -o .libs/fmain.o In file included from ./kinds.h:75:0, from ../../../src/libgfortran/libgfortran.h:243, from ../../../src/libgfortran/fmain.c:4: ../../../src/libgfortran/kinds-override.h:40:5: error: #error Where has __float128 gone? # error Where has __float128 gone? ^ make[6]: *** [fmain.lo] Error 1 make[6]: Leaving directory `/home/christophe/math/sage-6.6/local/var/tmp/sage/build/gcc-4.9.2.p1/gcc-build/x86_64-unknown-linux-gnu/libgfortran' make[5]: *** [all] Error 2 make[5]: Leaving directory `/home/christophe/math/sage-6.6/local/var/tmp/sage/build/gcc-4.9.2.p1/gcc-build/x86_64-unknown-linux-gnu/libgfortran' make[4]: *** [all-target-libgfortran] Error 2 make[4]: Leaving directory `/home/christophe/math/sage-6.6/local/var/tmp/sage/build/gcc-4.9.2.p1/gcc-build' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/christophe/math/sage-6.6/local/var/tmp/sage/build/gcc-4.9.2.p1/gcc-build' real67m42.626s user61m56.874s sys 5m47.686s Error installing package gcc-4.9.2.p1 Please email sage-devel
Re: [sage-devel] Catalog of algebras: the definition of an algebra
Forward to sage-algebra? John On 6 May 2015 at 20:08, Travis Scrimshaw tsc...@ucdavis.edu wrote: On #15635, we are trying to decide whether we want non-associative algebras to be included in the catalog of algebras. The argument against including them is most people think of algebras as being associative (and maybe even unital), and as such, might surprise people when they come across the non-associativity in their computations. However, the community was at one point considering renaming magmatic algebras into algebras and having to specify the associative axiom explicitly. There is also a counterpoint to the argument for not including non-associative algebras in the catalog in that the naming is clear, it gives a uniform entry point and easily discoverable, and usually when someone doesn't know what a particular object is, they look at the documentation. We would like to hear your thoughts on the matter, Travis -- 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/d/optout. -- 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/d/optout.
Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow
On 2015-05-06 20:00, Clemens Heuberger wrote: I'm happy to switch to closed when I merge it, and not only when it tests ok. The downside is that you'll get more emails as I'll inevitably have to reopen tickets, but merging/unmerging is scripted anyways. Eventually the merge will be done by a script, so ideally tickets will only stay for seconds in the positive_review state then. Essentially, we'll get rid of positive_review state and any opportunity to make changes. Which ends up being the same as just agreeing not to make changes to positive_review tickets right now. We can also enforce this (require trac admin permissions for changing away from positive_review) if you don't trust others... This thread did not get any more answers for ~ two weeks now. I have the impression that this proposal here did not get negative reactions. Fine, I'll give a negative reaction: I don't like that there is no window of time to adjust a branch after positive_review. It can easily happen that some trivial issue is found after positive_review, it can also happen that a ticket got set to positive_review by accident. And it just feels like an unneeded restriction that tickets shouldn't be changed after positive_review: there is no fundamental reason why positive_review should be final. Jeroen. -- 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/d/optout.
Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow
On Wednesday, May 6, 2015 at 8:07:08 PM UTC+2, Jeroen Demeyer wrote: And it just feels like an unneeded restriction that tickets shouldn't be changed after positive_review: there is no fundamental reason why positive_review should be final. There is no reason that closed should be final, until the new branch is published we *can* always back. That doesn't mean that you *should* dump a pile of extra bookkeeping on me. -- 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/d/optout.
[sage-devel] Re: dimension() broken for ideals?
This is now ticket #18374
El miércoles, 6 de mayo de 2015, 17:47:54 (UTC+2), Jakob Kroeker escribió:
It is definitely a bug in the dimension method.
could you open a ticket and post the link here?
Am Sonntag, 3. Mai 2015 15:25:13 UTC+2 schrieb mmarco:
It is definitely a bug in the dimension method.
If singular can handle the ring, sage asks singular to compute the
dimension, which does correctly (the -1 is the singular convention for
empty varieties).
The problem is that when the field is not supported by singular (which
happens with QQbar or finite fields of characteristic bigger than 2^31) ,
then sage falls back to its own toy implementation. In that case, it
appears that the empty case is not treated separatedly than the zero
dimensional case.
El viernes, 1 de mayo de 2015, 21:18:55 (UTC+2), gjorgen...@my.fit.edu
escribió:
Hi,
For the following ideal, dimension() returns 0,
{{{
R.s0,s1=QQbar[]
I=R.ideal([ s0 + 1, s0*s1 + s0 + s1 + 1, (-2)*s0 + 1, (-10)*s1 + 5,
5*s0^2 + 10*s0*s1 ])
I.dimension()
}}}
but its variety is empty.
Also for any other ring, dimension() returns -1 for this ideal. Is this
a bug with dimension()? The documentation for dimension() doesn't seem to
mention the -1 case.
It provides the following example,
{{{
R.x,y = PolynomialRing(GF(2147483659),order='lex')
I = R.ideal([x*y,x*y+1])
I.dimension()
}}}
which yields dimension 0 for the ideal, yet the corresponding variety is
empty.
What is the expected behavior for dimension()? When the variety of the
ideal in question has no points is dimension() always supposed to return -1?
--
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/d/optout.
Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow
Am 2015-05-06 um 20:07 schrieb Jeroen Demeyer: On 2015-05-06 20:00, Clemens Heuberger wrote: I'm happy to switch to closed when I merge it, and not only when it tests ok. The downside is that you'll get more emails as I'll inevitably have to reopen tickets, but merging/unmerging is scripted anyways. Eventually the merge will be done by a script, so ideally tickets will only stay for seconds in the positive_review state then. Essentially, we'll get rid of positive_review state and any opportunity to make changes. Which ends up being the same as just agreeing not to make changes to positive_review tickets right now. We can also enforce this (require trac admin permissions for changing away from positive_review) if you don't trust others... This thread did not get any more answers for ~ two weeks now. I have the impression that this proposal here did not get negative reactions. Fine, I'll give a negative reaction: I don't like that there is no window of time to adjust a branch after positive_review. It can easily happen that some trivial issue is found after positive_review, it can also happen that a ticket got set to positive_review by accident. And it just feels like an unneeded restriction that tickets shouldn't be changed after positive_review: there is no fundamental reason why positive_review should be final. I think that the proposal consisted of two parts, my previous post was too unprecise in that respect. 1) When the release manager starts to work on a ticket, he sets it to closed in order to avoid further modification. This might lead to reopening closed tickets when a problem arises in the merge. 2) The second part was about the automatic merge. I did not see opposition to 1. There was some opposition to 2, which, IMHO, is something which might (or not) occur in the future, but without immediate consequences. If I understand it correctly, Jeroen's negative reaction is against 2, not against closing a ticket in order to avoid the race conflicts. Regards, CH -- 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/d/optout.
[sage-devel] Catalog of algebras: the definition of an algebra
On #15635 http://trac.sagemath.org/ticket/15635, we are trying to decide whether we want non-associative algebras to be included in the catalog of algebras. The argument against including them is most people think of algebras as being associative (and maybe even unital), and as such, might surprise people when they come across the non-associativity in their computations. However, the community was at one point considering renaming magmatic algebras into algebras and having to specify the associative axiom explicitly. There is also a counterpoint to the argument for not including non-associative algebras in the catalog in that the naming is clear, it gives a uniform entry point and easily discoverable, and usually when someone doesn't know what a particular object is, they look at the documentation. We would like to hear your thoughts on the matter, Travis -- 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/d/optout.
[sage-devel] Re: Unicode in Sage Worksheets
There are some unicode typesetting enhancements coming down the road:
#18357: Unicode Art
#18270: Print matrices using unicode large delimiters (on demand)
On Wednesday, May 6, 2015 at 7:03:23 PM UTC+2, Bill Page wrote:
Perhaps this is more specifically related to Sage. Anyone have any
suggestions or comments? Has the issue of sending unicode to external
programs been discussed before?
Is there a better way to implement this without having to modify a
common python site package?
Is there a good way to make this specific to just those interfaces
that can support unicode?
-- Forwarded message --
From: Bill Page bill...@newsynthesis.org javascript:
Date: 5 May 2015 at 23:02
Subject: Re: Unicode in Sage Worksheets
To: sage-...@googlegroups.com javascript:
As suggested here:
http://sourceforge.net/p/pexpect/bugs/28/
the following patch to the sage python site package pexpect.py
~$ diff -au
/usr/local/sage/sage-6.5/local/lib/python2.7/site-packages/pexpect.py
pexpectu.py
--- /usr/local/sage/sage-6.5/local/lib/python2.7/site-packages/pexpect.py
2015-02-23 23:01:50.0 +
+++ pexpectu.py 2015-05-06 02:26:19.798935537 +
@@ -666,7 +666,7 @@
if self.logfile != None:
self.logfile.write (str)
self.logfile.flush()
-c = os.write(self.child_fd, str)
+c = os.write(self.child_fd, str.encode(utf-8))
return c
def sendline(self, str=''):
--
and calling it from sage 'expect.py' like this:
~$ diff -au expect.py.orig expect.py
--- expect.py.orig 2015-05-06 02:53:17.150953375 +
+++ expect.py 2015-05-06 02:50:25.410955076 +
@@ -55,8 +55,8 @@
# For reasons I don't understand, pexpect2.1 is much
# worse than pexpect 2.0 for everything Sage does.
-import pexpect
-from pexpect import ExceptionPexpect
+import pexpectu as pexpect
+from pexpectu import ExceptionPexpect
from sage.interfaces.interface import Interface, InterfaceElement,
InterfaceFunction, InterfaceFunctionElement, AsciiArtString
from sage.structure.element import RingElement
--
enables sending unicode characters to FriCAS from a Sage worksheet as
shown here:
https://cloud.sagemath.com/projects/4bc39013-7b65-4a65-9d3d-bec4a4ce4d5a/files/fricas-CR%20Examples.sagews
Does anyone have a suggestion for how to package this for Sage and or
Sage Math Cloud? Is
str.encode(utf-8)
likely to cause errors in interfaces to other programs?
Bill Page.
On 5 May 2015 at 17:40, Bill Page bill...@newsynthesis.org javascript:
wrote:
I tried to use a unicode character in the following worksheet:
https://cloud.sagemath.com/projects/4bc39013-7b65-4a65-9d3d-bec4a4ce4d5a/files/fricas-CR%20Examples.sagews
The cell input is
axialratio(expr,z)==(1-Abs(μ(expr,z)))/(1+Abs(μ(expr,z)))
i.e. containing the Greek letter \mu
This is being sent to FriCAS to execute. FriCAS support the use of
unicode like this and in fact I can use it in a SMC terminal with
FriCAS. But in a Sage Worksheet in SMC I get the following error:
Error in lines 1-1
Traceback (most recent call last):
File
/projects/4bc39013-7b65-4a65-9d3d-bec4a4ce4d5a/.sagemathcloud/sage_server.py,
line 879, in execute
exec compile(block+'\n', '', 'single') in namespace, locals
File , line 1, in module
File
/projects/4bc39013-7b65-4a65-9d3d-bec4a4ce4d5a/.sagemathcloud/sage_server.py,
line 920, in execute_with_code_decorators
code = code_decorator(code)
File , line 3, in fricas_md
File ./expect.py, line 1224, in eval
for L in code.split('\n') if L != ''])
File ./axiom.py, line 440, in _eval_line
E.sendline(line)
File
/usr/local/sage/sage-6.5/local/lib/python2.7/site-packages/pexpect.py,
line 676, in sendline
n = self.send(str)
File
/usr/local/sage/sage-6.5/local/lib/python2.7/site-packages/pexpect.py,
line 669, in send
c = os.write(self.child_fd, str)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u03bc' in
position 27: ordinal not in range(128)
--
Is this a limitation of the pexpect interface? Is there some way around
this?
Bill.
--
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/d/optout.
Re: [sage-devel] Re: sage 6.6 pyopenssl
Am 2015-05-04 um 12:46 schrieb Volker Braun: It didn't work, there is no deprecation period for removing bugs. I see. Sorry, that was not clear to me, neither here nor on the ticket. Regards, CH On Monday, May 4, 2015 at 11:14:43 AM UTC+2, Clemens Heuberger wrote: On 2015-05-04 10:55, Volker Braun wrote: We intentionally deleted the pyopenssl spkg. If it can be found on a mirror then that is only because it hasn't been updated. This is http://trac.sagemath.org/ticket/18261 http://trac.sagemath.org/ticket/18261 I am not too happy that the instructions in the documentation of the _current_ _stable_ release lead to a link to a no longer existing file. Shouldn't there be some analogy to our deprecation policy? Or, alternatively, a new stable release fixing the documentation issue? What is the policy for removing spkgs, also in relation to reproduceability of old research? I can probably compile old sage versions if needed for some old non-polished code, but if the corresponding parts of sage-as-a-distribution are no longer available? (Granted, pyopenssl is probably not about research, just about infrastructure).e Regards, CH -- 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/d/optout.
[sage-devel] Fwd: Unicode in Sage Worksheets
Perhaps this is more specifically related to Sage. Anyone have any
suggestions or comments? Has the issue of sending unicode to external
programs been discussed before?
Is there a better way to implement this without having to modify a
common python site package?
Is there a good way to make this specific to just those interfaces
that can support unicode?
-- Forwarded message --
From: Bill Page bill.p...@newsynthesis.org
Date: 5 May 2015 at 23:02
Subject: Re: Unicode in Sage Worksheets
To: sage-cl...@googlegroups.com
As suggested here:
http://sourceforge.net/p/pexpect/bugs/28/
the following patch to the sage python site package pexpect.py
~$ diff -au
/usr/local/sage/sage-6.5/local/lib/python2.7/site-packages/pexpect.py
pexpectu.py
--- /usr/local/sage/sage-6.5/local/lib/python2.7/site-packages/pexpect.py
2015-02-23 23:01:50.0 +
+++ pexpectu.py 2015-05-06 02:26:19.798935537 +
@@ -666,7 +666,7 @@
if self.logfile != None:
self.logfile.write (str)
self.logfile.flush()
-c = os.write(self.child_fd, str)
+c = os.write(self.child_fd, str.encode(utf-8))
return c
def sendline(self, str=''):
--
and calling it from sage 'expect.py' like this:
~$ diff -au expect.py.orig expect.py
--- expect.py.orig 2015-05-06 02:53:17.150953375 +
+++ expect.py 2015-05-06 02:50:25.410955076 +
@@ -55,8 +55,8 @@
# For reasons I don't understand, pexpect2.1 is much
# worse than pexpect 2.0 for everything Sage does.
-import pexpect
-from pexpect import ExceptionPexpect
+import pexpectu as pexpect
+from pexpectu import ExceptionPexpect
from sage.interfaces.interface import Interface, InterfaceElement,
InterfaceFunction, InterfaceFunctionElement, AsciiArtString
from sage.structure.element import RingElement
--
enables sending unicode characters to FriCAS from a Sage worksheet as
shown here:
https://cloud.sagemath.com/projects/4bc39013-7b65-4a65-9d3d-bec4a4ce4d5a/files/fricas-CR%20Examples.sagews
Does anyone have a suggestion for how to package this for Sage and or
Sage Math Cloud? Is
str.encode(utf-8)
likely to cause errors in interfaces to other programs?
Bill Page.
On 5 May 2015 at 17:40, Bill Page bill.p...@newsynthesis.org wrote:
I tried to use a unicode character in the following worksheet:
https://cloud.sagemath.com/projects/4bc39013-7b65-4a65-9d3d-bec4a4ce4d5a/files/fricas-CR%20Examples.sagews
The cell input is
axialratio(expr,z)==(1-Abs(μ(expr,z)))/(1+Abs(μ(expr,z)))
i.e. containing the Greek letter \mu
This is being sent to FriCAS to execute. FriCAS support the use of
unicode like this and in fact I can use it in a SMC terminal with
FriCAS. But in a Sage Worksheet in SMC I get the following error:
Error in lines 1-1
Traceback (most recent call last):
File
/projects/4bc39013-7b65-4a65-9d3d-bec4a4ce4d5a/.sagemathcloud/sage_server.py,
line 879, in execute
exec compile(block+'\n', '', 'single') in namespace, locals
File , line 1, in module
File
/projects/4bc39013-7b65-4a65-9d3d-bec4a4ce4d5a/.sagemathcloud/sage_server.py,
line 920, in execute_with_code_decorators
code = code_decorator(code)
File , line 3, in fricas_md
File ./expect.py, line 1224, in eval
for L in code.split('\n') if L != ''])
File ./axiom.py, line 440, in _eval_line
E.sendline(line)
File
/usr/local/sage/sage-6.5/local/lib/python2.7/site-packages/pexpect.py,
line 676, in sendline
n = self.send(str)
File
/usr/local/sage/sage-6.5/local/lib/python2.7/site-packages/pexpect.py,
line 669, in send
c = os.write(self.child_fd, str)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u03bc' in
position 27: ordinal not in range(128)
--
Is this a limitation of the pexpect interface? Is there some way around this?
Bill.
--
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/d/optout.
[sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow
Am 2015-04-19 um 01:10 schrieb Volker Braun: On Saturday, April 18, 2015 at 4:47:05 AM UTC-4, Clemens Heuberger wrote: Freezing tickets once release manager starts merging them - change status to closed - some new status) I'm happy to switch to closed when I merge it, and not only when it tests ok. The downside is that you'll get more emails as I'll inevitably have to reopen tickets, but merging/unmerging is scripted anyways. Eventually the merge will be done by a script, so ideally tickets will only stay for seconds in the positive_review state then. Essentially, we'll get rid of positive_review state and any opportunity to make changes. Which ends up being the same as just agreeing not to make changes to positive_review tickets right now. We can also enforce this (require trac admin permissions for changing away from positive_review) if you don't trust others... This thread did not get any more answers for ~ two weeks now. I have the impression that this proposal here did not get negative reactions. So: is this the new work flow? In that case, I'd set #18228 to won't fix/invalid/duplicate etc. Regards, CH -- 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/d/optout.
[sage-devel] Re: build sage-6.6 R fail
John Foster wrote:
Just a suggestion:
Try a different make, as you know there are several.
You mean a different 'make' program?
There's nothing wrong with 'make' here; the R binary crashed:
$ printf '#includestdlib.h\nint main(){abort();}' | gcc -o dump_core
-x c -
$ printf 'all:\n\t@echo | ./dump_core' | make -f - SHELL=/bin/bash
/bin/bash: line 1: 25600 Doneecho
25601 Aborted | ./dump_core
make: *** [all] Error 134
$ ulimit -c unlimited
$ printf 'all:\n\t@echo | ./dump_core' | make -f - SHELL=/bin/bash
/bin/bash: line 1: 25607 Doneecho
25608 Aborted (core dumped) | ./dump_core
make: *** [all] Error 134
I see at the bottom
there is a core dump but no justification. Could be a memory addressing
issue. best wishes.
Memory addressing errors usually give SIGSEGV. The justification for
dumping a core file is SIGABRT, since that's the default action for it.
-leif
On 05/04/2015 01:43 AM, William Stein wrote:
Hi,
I'm trying to build Sage-6.6 on the latest Ubuntu 14.10
(SageMathCloud). The first problem was with libgd, which another
patch somebody posted May 1 got past. Now there is some mysterious
error/crash when building R which means nothing to me. See attached
log. I'm building with MAKE not set and a very high RAM/cpu quota...
gcc -std=gnu99 -shared -L../../../../lib
-L/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/lib/
-o tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o
http.o gramLatex.o gramRd.o -L../../../../lib -lR
make[9]: Entering directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools/src'
mkdir -p -- ../../../../library/tools/libs
make[9]: Leaving directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools/src'
make[8]: Leaving directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools/src'
make[7]: Leaving directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools'
/bin/bash: line 1: 11246 Doneecho
tools:::.install_package_description('.',
'../../../library/tools')
11247 Aborted (core dumped) |
R_DEFAULT_PACKAGES=NULL ../../../bin/R --vanilla --slave /dev/null
Makefile:30: recipe for target 'all' failed
--
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/d/optout.
Re: [sage-devel] Re: Unicode in Sage Worksheets
After reading the docs: http://pexpect.readthedocs.org/en/latest/index.html It seems that version 3 and later are supposed to handler unicode properly. Version 3.3 requires Python 2.6 or later. Since Sage is already at Python 2.7 is there a good reason why Sage is still using an older version of pexpect? On 6 May 2015 at 15:27, Volker Braun vbraun.n...@gmail.com wrote: There are some unicode typesetting enhancements coming down the road: #18357: Unicode Art #18270: Print matrices using unicode large delimiters (on demand) This is interesting but I suppose that neither of these directly affect external programs like %fricas. -- 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/d/optout.
Re: [sage-devel] Re: Unicode in Sage Worksheets
Is there a possibility of creating an experimental package to install pexpect 3.3 ? I see references to doctests failing but no details. It would be good to make this easier to test. On 6 May 2015 at 22:41, leif not.rea...@online.de wrote: Bill Page wrote: After reading the docs: http://pexpect.readthedocs.org/en/latest/index.html It seems that version 3 and later are supposed to handler unicode properly. Version 3.3 requires Python 2.6 or later. Since Sage is already at Python 2.7 is there a good reason why Sage is still using an older version of pexpect? http://trac.sagemath.org/ticket/502 (!) http://trac.sagemath.org/ticket/10295 -- 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/d/optout.
Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow
Am 2015-05-07 um 03:42 schrieb leif: I might be wrong, but isn't it trivial to check whether the branch of a ticket changed (after you merged it into some preliminary release)? It is easy to check. But what if it did change? This might lead to an infinite cycle, as outlined before. Regards, CH -- 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/d/optout.
Re: [sage-devel] build sage-6.6 R fail
On Wed, May 6, 2015 at 4:54 PM, William Stein wst...@gmail.com wrote:
Hi,
Thanks for the feedback.I decided to (1) use sage-6.7.beta4, and
(2) upgrade to Ubuntu-15.04. The Sage build has gone perfectly with
this combination.
This worked and all long tests passed.
William
-- William
On Wed, May 6, 2015 at 8:32 AM, John Foster jfoster81...@gmail.com wrote:
Just a suggestion:
Try a different make, as you know there are several. I see at the bottom
there is a core dump but no justification. Could be a memory addressing
issue. best wishes.
On 05/04/2015 01:43 AM, William Stein wrote:
Hi,
I'm trying to build Sage-6.6 on the latest Ubuntu 14.10
(SageMathCloud). The first problem was with libgd, which another
patch somebody posted May 1 got past. Now there is some mysterious
error/crash when building R which means nothing to me. See attached
log. I'm building with MAKE not set and a very high RAM/cpu quota...
gcc -std=gnu99 -shared -L../../../../lib
-L/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/lib/
-o tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o
http.o gramLatex.o gramRd.o -L../../../../lib -lR
make[9]: Entering directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools/src'
mkdir -p -- ../../../../library/tools/libs
make[9]: Leaving directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools/src'
make[8]: Leaving directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools/src'
make[7]: Leaving directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools'
/bin/bash: line 1: 11246 Doneecho
tools:::.install_package_description('.',
'../../../library/tools')
11247 Aborted (core dumped) |
R_DEFAULT_PACKAGES=NULL ../../../bin/R --vanilla --slave /dev/null
Makefile:30: recipe for target 'all' failed
--
John Foster
JW Foster Associates
--
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/d/optout.
--
William (http://wstein.org)
--
William (http://wstein.org)
--
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/d/optout.
Re: [sage-devel] Unicode in Sage Worksheets
Haven’t checked recently but the notebook has been broken each time someone has tried to update pexpect. There is a pexpect upgrade ticket where there should be more details. François On 7/05/2015, at 13:55, Bill Page bill.p...@newsynthesis.org wrote: After reading the docs: http://pexpect.readthedocs.org/en/latest/index.html It seems that version 3 and later are supposed to handler unicode properly. Version 3.3 requires Python 2.6 or later. Since Sage is already at Python 2.7 is there a good reason why Sage is still using an older version of pexpect? On 6 May 2015 at 15:27, Volker Braun vbraun.n...@gmail.com wrote: There are some unicode typesetting enhancements coming down the road: #18357: Unicode Art #18270: Print matrices using unicode large delimiters (on demand) This is interesting but I suppose that neither of these directly affect external programs like %fricas. -- 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/d/optout. -- 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/d/optout.
[sage-devel] Re: Unicode in Sage Worksheets
Bill Page wrote: After reading the docs: http://pexpect.readthedocs.org/en/latest/index.html It seems that version 3 and later are supposed to handler unicode properly. Version 3.3 requires Python 2.6 or later. Since Sage is already at Python 2.7 is there a good reason why Sage is still using an older version of pexpect? http://trac.sagemath.org/ticket/502 (!) http://trac.sagemath.org/ticket/10295 -leif -- 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/d/optout.
[sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow
Volker Braun wrote: On Wednesday, May 6, 2015 at 8:07:08 PM UTC+2, Jeroen Demeyer wrote: And it just feels like an unneeded restriction that tickets shouldn't be changed after positive_review: there is no fundamental reason why positive_review should be final. +1 Especially when changing refers to the ticket's *status*, i.e., setting it back to needs work. (I agree that one shouldn't update/change the *branch* while a ticket is in positive review state, but it typically should last in that state for a while before getting closed / merged, unless it is really urgent.) There is no reason that closed should be final, until the new branch is published we *can* always back. That doesn't mean that you *should* dump a pile of extra bookkeeping on me. Well, * only the release manager is allowed to reopen a ticket * the release manager *tests* tickets, but doesn't have to *review* them * you said Eventually the merge will be done by a script, so ideally tickets will only stay for seconds in the positive_review state then., which means positive review *is* or will be final (from the reviewers' perspective), because of the above. I might be wrong, but isn't it trivial to check whether the branch of a ticket changed (after you merged it into some preliminary release)? Likewise, the ticket's status, in case you leave it open until you've successfully tested it? And there's still the option to fill the Merged in field to indicate testing while leaving the ticket open, in positive review state, only closing it when it finally got merged (i.e., when you're happy with it). -leif -- 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/d/optout.
Re: [sage-devel] Unicode in Sage Worksheets
http://trac.sagemath.org/ticket/10295 Looks like no one is interested any more. On 6 May 2015 at 22:03, Francois Bissey francois.bis...@canterbury.ac.nz wrote: Haven’t checked recently but the notebook has been broken each time someone has tried to update pexpect. There is a pexpect upgrade ticket where there should be more details. François On 7/05/2015, at 13:55, Bill Page bill.p...@newsynthesis.org wrote: After reading the docs: http://pexpect.readthedocs.org/en/latest/index.html It seems that version 3 and later are supposed to handler unicode properly. Version 3.3 requires Python 2.6 or later. Since Sage is already at Python 2.7 is there a good reason why Sage is still using an older version of pexpect? On 6 May 2015 at 15:27, Volker Braun vbraun.n...@gmail.com wrote: There are some unicode typesetting enhancements coming down the road: #18357: Unicode Art #18270: Print matrices using unicode large delimiters (on demand) This is interesting but I suppose that neither of these directly affect external programs like %fricas. -- 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/d/optout. -- 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/d/optout. -- 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/d/optout.
[sage-devel] Re: Unicode in Sage Worksheets
Bill Page wrote: Is there a possibility of creating an experimental package to install pexpect 3.3 ? mkdir foo-1.0 echo 'print Installing foo..' foo-1.0/setup.py tar czf foo-1.0.spkg foo-1.0/ ./sage -i foo-1.0.spkg -leif I see references to doctests failing but no details. It would be good to make this easier to test. On 6 May 2015 at 22:41, leif not.rea...@online.de wrote: Bill Page wrote: After reading the docs: http://pexpect.readthedocs.org/en/latest/index.html It seems that version 3 and later are supposed to handler unicode properly. Version 3.3 requires Python 2.6 or later. Since Sage is already at Python 2.7 is there a good reason why Sage is still using an older version of pexpect? http://trac.sagemath.org/ticket/502 (!) http://trac.sagemath.org/ticket/10295 -- 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/d/optout.
Re: [sage-devel] build sage-6.6 R fail
Just a suggestion:
Try a different make, as you know there are several. I see at the bottom
there is a core dump but no justification. Could be a memory addressing
issue. best wishes.
On 05/04/2015 01:43 AM, William Stein wrote:
Hi,
I'm trying to build Sage-6.6 on the latest Ubuntu 14.10
(SageMathCloud). The first problem was with libgd, which another
patch somebody posted May 1 got past. Now there is some mysterious
error/crash when building R which means nothing to me. See attached
log. I'm building with MAKE not set and a very high RAM/cpu quota...
gcc -std=gnu99 -shared -L../../../../lib
-L/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/lib/
-o tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o
http.o gramLatex.o gramRd.o -L../../../../lib -lR
make[9]: Entering directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools/src'
mkdir -p -- ../../../../library/tools/libs
make[9]: Leaving directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools/src'
make[8]: Leaving directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools/src'
make[7]: Leaving directory
'/projects/8111fd7e-e470-49ed-996d-8bba01a6cd3e/sage-6.6/local/var/tmp/sage/build/r-3.1.2.p0/src/src/library/tools'
/bin/bash: line 1: 11246 Doneecho
tools:::.install_package_description('.',
'../../../library/tools')
11247 Aborted (core dumped) |
R_DEFAULT_PACKAGES=NULL ../../../bin/R --vanilla --slave /dev/null
Makefile:30: recipe for target 'all' failed
--
John Foster
JW Foster Associates
--
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/d/optout.
[sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow
Clemens Heuberger wrote: Am 2015-05-07 um 03:42 schrieb leif: I might be wrong, but isn't it trivial to check whether the branch of a ticket changed (after you merged it into some preliminary release)? It is easy to check. But what if it did change? This might lead to an infinite cycle, as outlined before. Well, this simply should not happen [by accident], or will happen very rarely, provided the authors and reviewers are aware it is currently subject to testing/inclusion. If the branch got updated, or simply the ticket's status changed (to needs review or needs work), the ticket gets dropped from the list of tickets for inclusion until it has positive review again. Almost the same as what happens when the *release manager* decides to not include / unmerge the ticket, e.g. because of build or doctest errors. The only difference being that *someone else* came to the conclusion it isn't yet ready to get merged. -leif -- 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/d/optout.
Re: [sage-devel] Re: Unicode in Sage Worksheets
On 6 May 2015 at 23:28, leif not.rea...@online.de wrote: Bill Page wrote: Is there a possibility of creating an experimental package to install pexpect 3.3 ? mkdir foo-1.0 echo 'print Installing foo..' foo-1.0/setup.py tar czf foo-1.0.spkg foo-1.0/ ./sage -i foo-1.0.spkg OK but I was bit worried about a package that actually replaces part of Sage itself. Here is an example of a Sage worksheet that does it dynamically using reload(): https://cloud.sagemath.com/projects/4bc39013-7b65-4a65-9d3d-bec4a4ce4d5a/files/Sage%20Worksheets/pexpect.sagews This shows proof in principle at least that replacing pexpect with the new version 3.3 does not negatively impact the fricas interface and that it does solve the problem with unicode. -- 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/d/optout.
[sage-devel] Re: dimension() broken for ideals?
It is definitely a bug in the dimension method.
could you open a ticket and post the link here?
Am Sonntag, 3. Mai 2015 15:25:13 UTC+2 schrieb mmarco:
It is definitely a bug in the dimension method.
If singular can handle the ring, sage asks singular to compute the
dimension, which does correctly (the -1 is the singular convention for
empty varieties).
The problem is that when the field is not supported by singular (which
happens with QQbar or finite fields of characteristic bigger than 2^31) ,
then sage falls back to its own toy implementation. In that case, it
appears that the empty case is not treated separatedly than the zero
dimensional case.
El viernes, 1 de mayo de 2015, 21:18:55 (UTC+2), gjorgen...@my.fit.edu
escribió:
Hi,
For the following ideal, dimension() returns 0,
{{{
R.s0,s1=QQbar[]
I=R.ideal([ s0 + 1, s0*s1 + s0 + s1 + 1, (-2)*s0 + 1, (-10)*s1 + 5,
5*s0^2 + 10*s0*s1 ])
I.dimension()
}}}
but its variety is empty.
Also for any other ring, dimension() returns -1 for this ideal. Is this a
bug with dimension()? The documentation for dimension() doesn't seem to
mention the -1 case.
It provides the following example,
{{{
R.x,y = PolynomialRing(GF(2147483659),order='lex')
I = R.ideal([x*y,x*y+1])
I.dimension()
}}}
which yields dimension 0 for the ideal, yet the corresponding variety is
empty.
What is the expected behavior for dimension()? When the variety of the
ideal in question has no points is dimension() always supposed to return -1?
--
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/d/optout.
