Re: [sage-devel] Re: Interactive plots for Sage Notebook
Hi Nathan, > On Saturday, February 22, 2014 2:33:19 AM UTC+11, vdelecroix wrote: >> >> * the matplotlib widgets: Sage right now uses matplotlib for main >> graphics capabilities. matplpotlib comes with a very complete and >> useful library for making interactive graphics in native windows (with >> cursors and all kind of things you may imagine). Note that I was not >> able to make it work within Sage... 2014-03-09 5:10 UTC+01:00, Nathan Dunfield : > > Late to this party, but I thought I would mention that I have successfully > used some of the matplotlib interactive widgets from within Sage on both OS > X and Linux. Specifically, I have used the Tk variant on both platforms; > you do have to recompile matplotlib since by default Sage chooses not to > compile any of the GUI backends. Check out > > http://dunfield.info/temp/tkplot.py > > for a complete example, including precisely what one needs to do to > recompile matplotlib for this to work. > > Probably the other GUI backends could be made to work (they all look pretty > > much the same, actually), but the Tk one is the one I needed at the time > and so the only one I tried. This is great and works as well for me ! Does anybody knows why matplotlib is built without GUI support by default ? Does it make sense to enable it (if dependencies are satisfied) ? Vincent -- 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: Re: RFC: draft PEP for adding @ as a matrix multiplication operator to Python
William Stein wrote: >> IIRC Maple used to have something like *& to denote matrix >> multiplication, don't know if this is still the case, > > Hey, you're right-ish: > > http://kb.iu.edu/data/afbm.html > > They don't use * either, they use "." (like in Mathematica). They > deprecated *&. Actually Maple has no real matrix multiplication operator. They use "*" to denote "commutative multiplication", and "." for "non-commutative multiplication" (and "*~" for elementwise multiplication, "@" for composition, "&*" for user-defined multiplication). Both "*" and "." can be used as part of symbolic expressions (a*b-b*a is immediately simplified to 0, while a.b-b.a is not), and are interpreted as multiplication of more concrete objects where it makes sense. -- Marc -- 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: sage-6.x git-motivated re-organization seriously breaks system-wide sage
On Sun, Mar 9, 2014 at 9:39 PM, William Stein wrote:
> On Sun, Mar 9, 2014 at 8:53 PM, R. Andrew Ohana
> wrote:
> > This doesn't at least look to be a regression, so much as a long term
> bug.
>
> Do you mean it isn't a regression *resulting from the git
> reorganization*?
I mean it doesn't look like it should be a regression. If it is, it is some
magic foo going on. In particular between 5.13 and 6.0, the source code for
sage.interfaces was only touched by trac #15440 (some maxima funkiness),
and SAGE_EXTCODE wasn't touched (it hasn't been changed for over a year by
this point).
Or do you mean that you think this has always been
> broken?
>
Looking at the code, it should have been.
> Install Sage as one user, then run it as another. In sage-5.10,11,12,
> I think the following worked, but in sage-6.2.beta it doesn't:
>
> octave.eval('rand(4)')
>
> Anyway, I guess I'll try to fix this someday...
>
A work-around (not a proper fix) is to mimic the standard interfaces
initialization, i.e.
-octave = Octave(script_subdirectory='user')
+octave = Octave(script_subdirectory=None)
and similarly for the other optional interfaces that seem to get very
little attention.
> -- William
>
>
> >
> >
> > On Sun, Mar 9, 2014 at 1:09 PM, William Stein wrote:
> >>
> >> Hi,
> >>
> >>
> >> I install sage-6.x systemwide for https://cloud.sagemath.com. Now it
> >> seems impossible for a normal user to use the octave interface (and
> >> probably many others), which is a _major_ regression:
> >>
> >>
> >> sage: octave.eval('rand(2)')
> >> Traceback (most recent call last):
> >> File
> >>
> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/expect.py",
> >> line 1208, in eval
> >> for L in code.split('\n') if L != ''])
> >> File
> >>
> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/expect.py",
> >> line 813, in _eval_line
> >> self._start()
> >> File
> >>
> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/octave.py",
> >> line 285, in _start
> >> Expect._start(self)
> >> File
> >>
> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/expect.py",
> >> line 389, in _start
> >> sage_makedirs(dir)
> >> File
> >>
> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/misc/misc.py",
> >> line 73, in sage_makedirs
> >> os.makedirs(dir)
> >> File "/usr/local/sage/sage-6.2/local/lib/python/os.py", line 150, in
> >> makedirs
> >> makedirs(head, mode)
> >> File "/usr/local/sage/sage-6.2/local/lib/python/os.py", line 157, in
> >> makedirs
> >> mkdir(name, mode)
> >> OSError: [Errno 13] Permission denied:
> >> '/usr/local/sage/sage-6.2/local/share/sage/ext/octave'
> >>
> >>
> >> I was able to get things to work by doing
> >>
> >>mkdir -p /usr/local/sage/sage-6.2/local/share/sage/ext/octave/user
> >>chown a+rwx /usr/local/sage/sage-6.2/local/share/sage/ext/octave/user
> >>
> >> I particularly *HATE* the second chown -- yes, you must give write to
> >> everybody.
> >> This of means any user could just fill up that directory and bring down
> >> the
> >> system.
> >>
> >> Anyway, what happened?
> >>
> >>
> >> -- William
> >
> >
> >
> >
> > --
> > Andrew
>
>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
>
--
Andrew
--
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: sage-6.x git-motivated re-organization seriously breaks system-wide sage
On Sun, Mar 9, 2014 at 8:53 PM, R. Andrew Ohana wrote:
> This doesn't at least look to be a regression, so much as a long term bug.
Do you mean it isn't a regression *resulting from the git
reorganization*? Or do you mean that you think this has always been
broken?
Install Sage as one user, then run it as another. In sage-5.10,11,12,
I think the following worked, but in sage-6.2.beta it doesn't:
octave.eval('rand(4)')
Anyway, I guess I'll try to fix this someday...
-- William
>
>
> On Sun, Mar 9, 2014 at 1:09 PM, William Stein wrote:
>>
>> Hi,
>>
>>
>> I install sage-6.x systemwide for https://cloud.sagemath.com. Now it
>> seems impossible for a normal user to use the octave interface (and
>> probably many others), which is a _major_ regression:
>>
>>
>> sage: octave.eval('rand(2)')
>> Traceback (most recent call last):
>> File
>> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/expect.py",
>> line 1208, in eval
>> for L in code.split('\n') if L != ''])
>> File
>> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/expect.py",
>> line 813, in _eval_line
>> self._start()
>> File
>> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/octave.py",
>> line 285, in _start
>> Expect._start(self)
>> File
>> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/expect.py",
>> line 389, in _start
>> sage_makedirs(dir)
>> File
>> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/misc/misc.py",
>> line 73, in sage_makedirs
>> os.makedirs(dir)
>> File "/usr/local/sage/sage-6.2/local/lib/python/os.py", line 150, in
>> makedirs
>> makedirs(head, mode)
>> File "/usr/local/sage/sage-6.2/local/lib/python/os.py", line 157, in
>> makedirs
>> mkdir(name, mode)
>> OSError: [Errno 13] Permission denied:
>> '/usr/local/sage/sage-6.2/local/share/sage/ext/octave'
>>
>>
>> I was able to get things to work by doing
>>
>>mkdir -p /usr/local/sage/sage-6.2/local/share/sage/ext/octave/user
>>chown a+rwx /usr/local/sage/sage-6.2/local/share/sage/ext/octave/user
>>
>> I particularly *HATE* the second chown -- yes, you must give write to
>> everybody.
>> This of means any user could just fill up that directory and bring down
>> the
>> system.
>>
>> Anyway, what happened?
>>
>>
>> -- William
>
>
>
>
> --
> Andrew
--
William Stein
Professor of Mathematics
University of Washington
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: sage-6.x git-motivated re-organization seriously breaks system-wide sage
This doesn't at least look to be a regression, so much as a long term bug.
The offending path has always been a subpath of SAGE_ROOT since sage was
initially checked into a repository (it was SAGE_ROOT/data/extcode/octave
before). My guess is that if you are only experiencing issues with recent
versions of sage, is that there was some other change that is trying to
write to a file under that path.
On Sun, Mar 9, 2014 at 1:09 PM, William Stein wrote:
> Hi,
>
>
> I install sage-6.x systemwide for https://cloud.sagemath.com. Now it
> seems impossible for a normal user to use the octave interface (and
> probably many others), which is a _major_ regression:
>
>
> sage: octave.eval('rand(2)')
> Traceback (most recent call last):
> File
> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/expect.py",
> line 1208, in eval
> for L in code.split('\n') if L != ''])
> File
> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/expect.py",
> line 813, in _eval_line
> self._start()
> File
> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/octave.py",
> line 285, in _start
> Expect._start(self)
> File
> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/expect.py",
> line 389, in _start
> sage_makedirs(dir)
> File
> "/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/misc/misc.py",
> line 73, in sage_makedirs
> os.makedirs(dir)
> File "/usr/local/sage/sage-6.2/local/lib/python/os.py", line 150, in
> makedirs
> makedirs(head, mode)
> File "/usr/local/sage/sage-6.2/local/lib/python/os.py", line 157, in
> makedirs
> mkdir(name, mode)
> OSError: [Errno 13] Permission denied:
> '/usr/local/sage/sage-6.2/local/share/sage/ext/octave'
>
>
> I was able to get things to work by doing
>
>mkdir -p /usr/local/sage/sage-6.2/local/share/sage/ext/octave/user
>chown a+rwx /usr/local/sage/sage-6.2/local/share/sage/ext/octave/user
>
> I particularly *HATE* the second chown -- yes, you must give write to
> everybody.
> This of means any user could just fill up that directory and bring down the
> system.
>
> Anyway, what happened?
>
>
> -- William
>
--
Andrew
--
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: RFC: draft PEP for adding @ as a matrix multiplication operator to Python
On Mon, Mar 10, 2014 at 12:09 AM, Simon King wrote: > Hi Nathaniel, > > are you sure that you talk about actual matrices? Or do you just talk > about 2-dimensional arrays? Sure -- this is a useful distinction, and as far as it goes, I'm talking about arrays. But people do in fact want to do the operation commonly referred to as "matrix multiplication" when working with arrays, whether we like it or not. Many many people. Github code search produces >23,000 Python files containing the string "np.dot", and every one of those is a violation of the "keep matrices and arrays" separate principle. So this is the reality we live in... > By the way, how could your PEP possibly be relevant to Python? IIRC, > there neither is a matrix type nor an array type in Python, thus, it > makes no sense whatsoever to theoretise about special symbols for matrix > multiplication and component-wise action on arrays in *Python*. There are a dozen or more array and matrix types in Python. I use them all the time. So do thousands of other people. You don't download them from http://python.org, but this doesn't make them nonsense... > Such discussion sure makes sense in a CAS, though.. > > On 2014-03-09, Nathaniel Smith wrote: >> ... >> R alsos use * for elementwise mul. And really, it does work fine and >> is useful in many application areas, I promise! :-) I've sent similar >> heads-up emails to 13 projects now, and so far you guys are the only >> ones who have blinked at this part; > > Quite bizarre indeed, as I'd thought that your suggestion will seem rather > odd to most mathematicians and computer scientists. Well, not ones who crunch numbers all day :-). It's got a long history -- e.g. Fortran also uses * to mean elementwise mul. >> Even * is pretty >> arbitrary the first time you see it -- real mathematical notation uses >> \cdot or occasionally \times, not \star -- but we forget this because >> we already learned it a while ago :-). > > In mathematics, a lot of different multiplication symbols are in use. > For example, usually \cdot denotes pointwise multiplication, whereas > \star denotes convolution and \circ denotes composition, and there > is also cartesian product \times and tensor product \otimes. In > principal, all these operations can occur at the same time, thus, there > is no way around using a variety of symbols, to avoid confusion. > > Thus, it would certainly be a reasonable PEP to provide a framework in > Python to define custom infix operators (say, operator.compose), by > providing a character (say: '@') and the name of a custom "magical > method" (say: '__composition__') that is called on the operator's > arguments, in the same way as operator.mul uses '*' and results in > calling '__mul__'. I do not believe that it is possible to write such a PEP that would be acceptable to the broader Python community. (I don't even think I could come up with such a PEP that I would accept if I were BDFL.) It's a huge change to how Python works, and runs into a lot of practical problems (defining precedence, defining scoping, creating nasty couplings between parse time and eval time, etc.). That's just my best judgement, though; if someone comes along with a convincing proposal then I'll certainly advocate it. > However, in all algebraic textbooks I am aware of, \cdot is consistently > used to denote... > - multiplication in fields, > - the componentwise action of a field on vectors resp. matrices, aka > scalar multiplication, > - the dot product of vectors (resulting in a field element) > - matrix multiplication, > - generally multiplication in a ring, unless different kinds of > multiplication occur > > It may seem natural to multiply two 2-dimensional ARRAYS component-wise. > However, if you have MATRICES that deserve such a title (say, they > encode a linear map) then "Matrix \cdot Matrix" clearly is matrix > multiplication and nothing else. > > Python does not know about rings and vector spaces, whereas Sage does: > Sage uses '*' for multiplication in rings and for module actions. In > particular, by consistency, Sage must use '*' to denote multiplication > of square matrices (since this is multiplication in a matrix ring) > > Python uses * to denote multiplication of numbers, which is \cdot in > textbooks. Hence, according to the "principle of least surprise", one > has to use * for what is commonly denoted by \cdot in textbooks. And > this includes matrix multiplication. Sure, fair enough. If you're lucky enough to be dealing only with pure mathematical matrices, then the problem this PEP is addressing doesn't arise. Practical number crunching OTOH isn't so pretty, but it is useful :-). -n -- 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 ht
[sage-devel] Re: Call for vote about ticket #10963: axioms and more functorial constructions
Hi Volker,
On 2014-03-09, Volker Braun wrote:
> --=_Part_25_1398588.1394377030563
> Content-Type: text/plain; charset=UTF-8
>
> On Sunday, March 9, 2014 2:16:51 PM UTC, Simon King wrote:
>>
>> class Cs(Category):
>> class Finite(CategoryWithAxiom):
>> class ParentClass:
>> def some_method(self):
>> return "I am a finite c"
>> is also (I think) *sufficiently* explicit about Cs.Finite() being a
>> sub-category of Cs(), defined by the axiom Finite.
>>
>
> This snippet defines a finite axiom that is different from the finite axiom
> for sets, and your parents will not have a "is_finite()" method.
The snippet was supposed to be a continuation of the first snipped,
which stated that Cs() is a sub-category of Sets(). Sorry for not being
clear.
> Really, the whole subclass-as-axiom magic is just an attempt at syntactic
> sugar. The only thing that matters is that Cs().Finite() returns an
> instance of the the axiom. There are various functionally equivalent ways
> to implement it. There is yet another syntax to achieve the same end,
> namely Cs().with_axiom("Finite"). Except for the strings I would be much
> happier with that since it doesn't require an open-ended list of magic
> attribute names for axioms.
OK, that is the syntax that you want for *using* axioms: Not Cs.Finite() or
Cs().Finite(), but Cs.with_axiom("Finite") or even better
Cs.with_axiom(axioms.Finite). Fair enough.
But your answer is orthogonal to what I was asking you: What syntax to you
suggest for *implementing* axioms? Do you think stating that Cs() is a
subcategory of Sets() is not good enough for having Cs().Finite() being
a sub-category of Sets().Finite()? What else is there to code, in your
opinion?
Best regards,
Simon
--
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: RFC: draft PEP for adding @ as a matrix multiplication operator to Python
On 2014-03-10, Simon King wrote: > In mathematics, a lot of different multiplication symbols are in use. > For example, Here I did a wrong edit. Sorry. I meant to say: FOR FUNCTIONS, \cdot usually denotes pointwise multiplication > ..., whereas > \star denotes convolution and \circ denotes composition, and there > is also cartesian product \times and tensor product \otimes. In > principal, all these operations can occur at the same time, thus, there > is no way around using a variety of symbols, to avoid confusion. For matrices, \cdot clearly is NOT pointwise. Cheers, Simon -- 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: RFC: draft PEP for adding @ as a matrix multiplication operator to Python
Hi Nathaniel, are you sure that you talk about actual matrices? Or do you just talk about 2-dimensional arrays? By the way, how could your PEP possibly be relevant to Python? IIRC, there neither is a matrix type nor an array type in Python, thus, it makes no sense whatsoever to theoretise about special symbols for matrix multiplication and component-wise action on arrays in *Python*. Such discussion sure makes sense in a CAS, though.. On 2014-03-09, Nathaniel Smith wrote: > ... > R alsos use * for elementwise mul. And really, it does work fine and > is useful in many application areas, I promise! :-) I've sent similar > heads-up emails to 13 projects now, and so far you guys are the only > ones who have blinked at this part; Quite bizarre indeed, as I'd thought that your suggestion will seem rather odd to most mathematicians and computer scientists. > Even * is pretty > arbitrary the first time you see it -- real mathematical notation uses > \cdot or occasionally \times, not \star -- but we forget this because > we already learned it a while ago :-). In mathematics, a lot of different multiplication symbols are in use. For example, usually \cdot denotes pointwise multiplication, whereas \star denotes convolution and \circ denotes composition, and there is also cartesian product \times and tensor product \otimes. In principal, all these operations can occur at the same time, thus, there is no way around using a variety of symbols, to avoid confusion. Thus, it would certainly be a reasonable PEP to provide a framework in Python to define custom infix operators (say, operator.compose), by providing a character (say: '@') and the name of a custom "magical method" (say: '__composition__') that is called on the operator's arguments, in the same way as operator.mul uses '*' and results in calling '__mul__'. However, in all algebraic textbooks I am aware of, \cdot is consistently used to denote... - multiplication in fields, - the componentwise action of a field on vectors resp. matrices, aka scalar multiplication, - the dot product of vectors (resulting in a field element) - matrix multiplication, - generally multiplication in a ring, unless different kinds of multiplication occur It may seem natural to multiply two 2-dimensional ARRAYS component-wise. However, if you have MATRICES that deserve such a title (say, they encode a linear map) then "Matrix \cdot Matrix" clearly is matrix multiplication and nothing else. Python does not know about rings and vector spaces, whereas Sage does: Sage uses '*' for multiplication in rings and for module actions. In particular, by consistency, Sage must use '*' to denote multiplication of square matrices (since this is multiplication in a matrix ring) Python uses * to denote multiplication of numbers, which is \cdot in textbooks. Hence, according to the "principle of least surprise", one has to use * for what is commonly denoted by \cdot in textbooks. And this includes matrix multiplication. In conclusion: 1) Python has no array or matrix types, thus adding a special symbol for matrix multiplication makes no sense in Python. 2) It makes sense to support adding custom infix operators to Python. 3) Python could of course add an array type with component-wise multiplication and a matrix type with matrix multiplication. But please keep "arrays" and "matrices" apart. 4) It is common to use the same operator symbol for various types of operands. There is 'ab'+'cd' and 'ab'*3 in contrast to 3+4 and 4*3. So, why should one suddenly start using new symbols if the operand types happens to be "matrix"? Best regards, Simon -- 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] RFC: draft PEP for adding @ as a matrix multiplication operator to Python
On Sun, Mar 9, 2014 at 8:44 PM, William Stein wrote: > On Sun, Mar 9, 2014 at 12:40 PM, wrote: >> On Sunday, March 9, 2014 7:20:50 PM UTC, Jeroen Demeyer wrote: >>> >>> I think the following piece should be made more clear, I don't >>> understand what you're trying to say here: >>> >>> The problem is that the presence of two different duck-types for numeric >>> data -- one where * means matrix multiply, and one where * means >>> elementwise multiplication -- make it impossible to write generic >>> functions that can operate on arbitrary data. >> >> >> Indeed, it's clear from everyone's responses here that I at least need to >> add a new section talking about these things explicitly, and also about why >> elementwise-* is actually used so often in practice in numeric computation >> (as opposed dto symbolic comptuation), and why np.matrix is so loathed. (It >> really is though, I didn't just make that up :-) I doubt you can find a >> single developer of any numpy-using package who has anything good to say >> about it.) I'll try to get to write such a section over the next few hours; >> at least it might make a better basis for discussion. >> >> In brief, the issue is that elementwise-* is a fine convention and you can >> use it to write useful code, and matrix-multiply-* is a fine convention and > > I'm not convinced * is a fine convention for element-wise > multiplication of matrices, since there is no software I know of that > does that.Even Matlab uses * to mean matrix multiplication: > http://www.math.utah.edu/~eyre/computing/matlab-intro/math.html R alsos use * for elementwise mul. And really, it does work fine and is useful in many application areas, I promise! :-) I've sent similar heads-up emails to 13 projects now, and so far you guys are the only ones who have blinked at this part; numpy has ~25x more PyPI downloads than sympy (a terrible metric I know, but perhaps it's at least some vague noisy estimate of relative user bases) and I guess those users are pretty much all happy with elementwise-*. My point isn't that the majority is always right or anything like that. I'm just saying, if you think elementwise-* is not just sub-optimal but also bizarre and unthinkable, then you might be missing something :-) (just like I was missing something when I thought that elementwise-* was so obvious it needed no justification). It may well be that the answer is that sage (and perhaps sympy) is just not in the target audience for this PEP, because you only have one multiplication operation that matters and the status quo works fine for you. If so that's great, though it'd still be good to coordinate to the extent it makes sense, and the feedback is still really useful. > But * is set in stone for numpy. The motivation for your proposal is > to make your example code involving matrix multiplication of numpy > arrays easier to read/write. I wonder if there is any way to do this > using a with statement, e.g., > > >c = a*b # element-wise multiplication > >with numpy.mul_as_dot(): > c = a*b# matrix multiplication > > > Then the exact part of the code that involves some expressions with > matrix multiplies of numpy arrays can be cleanly written with * > instead of of numpy.dot, and without having to introduce another > operator. Is this at least technically possible? If so, it is worth > addressing in the PEP. It would solve the problem of coding up > certain algorithms cleanly, and it is extremely clear and explicit > what is going on when you just jump into the code. This is a really interesting suggestion, and it is technically possible. Unfortunately, though, after thinking for a bit I see some problems that strike me as insurmountable -- here's a potential discussion in PEP-ese (to be slotted into the list of "rejected alternatives"): **Use ``with`` to switch the meaning of ``*`` within a single code block**: E.g., numpy could define a special context object so that we'd have:: c = a * b # element-wise multiplication with numpy.mul_as_dot: c = a * b # matrix multiplication However, this has two serious problems: first, it requires that every matrix-like object ``__mul__`` method know how to check some global state (``numpy.mul_is_currently_dot`` or whatever). This is fine if ``a`` and ``b`` are numpy objects, but the world contains many non-numpy matrix-like objects. So this either requires non-local coupling -- every numpy competitor library has to import numpy and then check ``numpy.mul_is_currently_dot`` on every operation -- or else it breaks duck-typing, with the above code doing radically different things depending on whether ``a`` and ``b`` are numpy objects or some other sort of object. Second, and worse, ``with`` blocks are dynamically scoped, not lexically scoped; i.e., any function that gets called inside the ``with`` block will suddenly find itself executing inside the mul_as_dot world, and crash and burn horribly (if y
Re: [sage-devel] Re: RFC: draft PEP for adding @ as a matrix multiplication operator to Python
On Sun, Mar 9, 2014 at 1:52 PM, Dima Pasechnik wrote: > On 2014-03-09, William Stein wrote: >> On Sun, Mar 9, 2014 at 12:40 PM, wrote: >>> On Sunday, March 9, 2014 7:20:50 PM UTC, Jeroen Demeyer wrote: I think the following piece should be made more clear, I don't understand what you're trying to say here: The problem is that the presence of two different duck-types for numeric data -- one where * means matrix multiply, and one where * means elementwise multiplication -- make it impossible to write generic functions that can operate on arbitrary data. >>> >>> >>> Indeed, it's clear from everyone's responses here that I at least need to >>> add a new section talking about these things explicitly, and also about why >>> elementwise-* is actually used so often in practice in numeric computation >>> (as opposed dto symbolic comptuation), and why np.matrix is so loathed. (It >>> really is though, I didn't just make that up :-) I doubt you can find a >>> single developer of any numpy-using package who has anything good to say >>> about it.) I'll try to get to write such a section over the next few hours; >>> at least it might make a better basis for discussion. >>> >>> In brief, the issue is that elementwise-* is a fine convention and you can >>> use it to write useful code, and matrix-multiply-* is a fine convention and >> >> I'm not convinced * is a fine convention for element-wise >> multiplication of matrices, since there is no software I know of that >> does that. > > Mathematica does this. (and it uses '.' for the usual matrix > multiplication). Thanks for pointing that out. I looked it up and Mathematica does not even have a Matrix data type at all: "Matrices are represented in Mathematica with lists." https://reference.wolfram.com/mathematica/howto/CreateAMatrix.html > IIRC Maple used to have something like *& to denote matrix > multiplication, don't know if this is still the case, Hey, you're right-ish: http://kb.iu.edu/data/afbm.html They don't use * either, they use "." (like in Mathematica). They deprecated *&. So I stand corrected. -- William Stein Professor of Mathematics University of Washington 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] RFC: draft PEP for adding @ as a matrix multiplication operator to Python
On 2014-03-09 20:40, n...@vorpus.org wrote: Indeed, it's clear from everyone's responses here that I at least need to add a new section talking about these things explicitly, and also about why elementwise-* is actually used so often in practice in numeric computation (as opposed dto symbolic comptuation), and why np.matrix is so loathed. Perhaps a better solution would be to fix numpy.matrix then? -- 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] RFC: draft PEP for adding @ as a matrix multiplication operator to Python
On 2014-03-09 20:40, n...@vorpus.org wrote: In brief, the issue is that elementwise-* is a fine convention and you can use it to write useful code, and matrix-multiply-* is a fine convention and you can use it to write useful code, but if you then try to glue those two pieces of code together into a larger system you will quickly find yourself in hell as you have to cast objects back and forth at every function call. Or similarly, if you try to write a function that works regardless of whether it receives an elementwise-*-object or a matrix-multiply-*-object, then this is also very painful (suddenly you need lots of type-checking and if statements scattered around every single function you write, it's horrible and no-one is willing to do it). My impression is that a lot of this confusion is because you confuse matrix and ndarray. They represent very different data structures and purposes (they might be very similar in implementation and may share many methods, but that doesn't matter here) . They are simply different kinds of objects with different multiplication operations. Duck typing should treat * as a "black box" operation, when you want to differentiate between different kinds of multiplication you're probably doing it wrong. -- 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: RFC: draft PEP for adding @ as a matrix multiplication operator to Python
On 2014-03-09, William Stein wrote: > On Sun, Mar 9, 2014 at 12:40 PM, wrote: >> On Sunday, March 9, 2014 7:20:50 PM UTC, Jeroen Demeyer wrote: >>> >>> I think the following piece should be made more clear, I don't >>> understand what you're trying to say here: >>> >>> The problem is that the presence of two different duck-types for numeric >>> data -- one where * means matrix multiply, and one where * means >>> elementwise multiplication -- make it impossible to write generic >>> functions that can operate on arbitrary data. >> >> >> Indeed, it's clear from everyone's responses here that I at least need to >> add a new section talking about these things explicitly, and also about why >> elementwise-* is actually used so often in practice in numeric computation >> (as opposed dto symbolic comptuation), and why np.matrix is so loathed. (It >> really is though, I didn't just make that up :-) I doubt you can find a >> single developer of any numpy-using package who has anything good to say >> about it.) I'll try to get to write such a section over the next few hours; >> at least it might make a better basis for discussion. >> >> In brief, the issue is that elementwise-* is a fine convention and you can >> use it to write useful code, and matrix-multiply-* is a fine convention and > > I'm not convinced * is a fine convention for element-wise > multiplication of matrices, since there is no software I know of that > does that. Mathematica does this. (and it uses '.' for the usual matrix multiplication). IIRC Maple used to have something like *& to denote matrix multiplication, don't know if this is still the case, > Even Matlab uses * to mean matrix multiplication: > http://www.math.utah.edu/~eyre/computing/matlab-intro/math.html > > But * is set in stone for numpy. The motivation for your proposal is > to make your example code involving matrix multiplication of numpy > arrays easier to read/write. I wonder if there is any way to do this > using a with statement, e.g., > > >c = a*b # element-wise multiplication > >with numpy.mul_as_dot(): > c = a*b# matrix multiplication > > > Then the exact part of the code that involves some expressions with > matrix multiplies of numpy arrays can be cleanly written with * > instead of of numpy.dot, and without having to introduce another > operator. Is this at least technically possible? If so, it is worth > addressing in the PEP. It would solve the problem of coding up > certain algorithms cleanly, and it is extremely clear and explicit > what is going on when you just jump into the code. > > Another issue -- imagine jumping into code and seeing @'s everywhere > -- you would have to google and figure out what is going on, which > could be hard for "@ operator". For example, I use the @ operator > all the time in CoffeeScript, so it's a useful thing, but googling "@ > operator" yields basically nothing useful about anything. > > -- William > > > > >> you can use it to write useful code, but if you then try to glue those two >> pieces of code together into a larger system you will quickly find yourself >> in hell as you have to cast objects back and forth at every function call. >> Or similarly, if you try to write a function that works regardless of >> whether it receives an elementwise-*-object or a matrix-multiply-*-object, >> then this is also very painful (suddenly you need lots of type-checking and >> if statements scattered around every single function you write, it's >> horrible and no-one is willing to do it). >> >> This doesn't get into the reasons why numpy goes with the elementwise-* >> convention, but it's why it seems important to have *some* convention. >> >> (Some of the reasons for why numpy goes with elementwise-* are here: >> https://github.com/njsmith/numpy/blob/matmul-pep/doc/neps/return-of-revenge-of-matmul-pep.rst#choice-of-operation >> ; the other important reason that that section doesn't talk about as much as >> it could is that numpy has n-dimensional arrays, while matrix multiplication >> is only really natural for 2d arrays.) >> >> -n >> >> -- >> 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 Stein > Professor of Mathematics > University of Washington > 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.co
Re: [sage-devel] RFC: draft PEP for adding @ as a matrix multiplication operator to Python
On Sun, Mar 9, 2014 at 12:40 PM, wrote: > On Sunday, March 9, 2014 7:20:50 PM UTC, Jeroen Demeyer wrote: >> >> I think the following piece should be made more clear, I don't >> understand what you're trying to say here: >> >> The problem is that the presence of two different duck-types for numeric >> data -- one where * means matrix multiply, and one where * means >> elementwise multiplication -- make it impossible to write generic >> functions that can operate on arbitrary data. > > > Indeed, it's clear from everyone's responses here that I at least need to > add a new section talking about these things explicitly, and also about why > elementwise-* is actually used so often in practice in numeric computation > (as opposed dto symbolic comptuation), and why np.matrix is so loathed. (It > really is though, I didn't just make that up :-) I doubt you can find a > single developer of any numpy-using package who has anything good to say > about it.) I'll try to get to write such a section over the next few hours; > at least it might make a better basis for discussion. > > In brief, the issue is that elementwise-* is a fine convention and you can > use it to write useful code, and matrix-multiply-* is a fine convention and I'm not convinced * is a fine convention for element-wise multiplication of matrices, since there is no software I know of that does that.Even Matlab uses * to mean matrix multiplication: http://www.math.utah.edu/~eyre/computing/matlab-intro/math.html But * is set in stone for numpy. The motivation for your proposal is to make your example code involving matrix multiplication of numpy arrays easier to read/write. I wonder if there is any way to do this using a with statement, e.g., c = a*b # element-wise multiplication with numpy.mul_as_dot(): c = a*b# matrix multiplication Then the exact part of the code that involves some expressions with matrix multiplies of numpy arrays can be cleanly written with * instead of of numpy.dot, and without having to introduce another operator. Is this at least technically possible? If so, it is worth addressing in the PEP. It would solve the problem of coding up certain algorithms cleanly, and it is extremely clear and explicit what is going on when you just jump into the code. Another issue -- imagine jumping into code and seeing @'s everywhere -- you would have to google and figure out what is going on, which could be hard for "@ operator". For example, I use the @ operator all the time in CoffeeScript, so it's a useful thing, but googling "@ operator" yields basically nothing useful about anything. -- William > you can use it to write useful code, but if you then try to glue those two > pieces of code together into a larger system you will quickly find yourself > in hell as you have to cast objects back and forth at every function call. > Or similarly, if you try to write a function that works regardless of > whether it receives an elementwise-*-object or a matrix-multiply-*-object, > then this is also very painful (suddenly you need lots of type-checking and > if statements scattered around every single function you write, it's > horrible and no-one is willing to do it). > > This doesn't get into the reasons why numpy goes with the elementwise-* > convention, but it's why it seems important to have *some* convention. > > (Some of the reasons for why numpy goes with elementwise-* are here: > https://github.com/njsmith/numpy/blob/matmul-pep/doc/neps/return-of-revenge-of-matmul-pep.rst#choice-of-operation > ; the other important reason that that section doesn't talk about as much as > it could is that numpy has n-dimensional arrays, while matrix multiplication > is only really natural for 2d arrays.) > > -n > > -- > 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 Stein Professor of Mathematics University of Washington 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] sage-6.x git-motivated re-organization seriously breaks system-wide sage
Hi,
I install sage-6.x systemwide for https://cloud.sagemath.com. Now it
seems impossible for a normal user to use the octave interface (and
probably many others), which is a _major_ regression:
sage: octave.eval('rand(2)')
Traceback (most recent call last):
File
"/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/expect.py",
line 1208, in eval
for L in code.split('\n') if L != ''])
File
"/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/expect.py",
line 813, in _eval_line
self._start()
File
"/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/octave.py",
line 285, in _start
Expect._start(self)
File
"/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/interfaces/expect.py",
line 389, in _start
sage_makedirs(dir)
File
"/usr/local/sage/sage-6.2/local/lib/python2.7/site-packages/sage/misc/misc.py",
line 73, in sage_makedirs
os.makedirs(dir)
File "/usr/local/sage/sage-6.2/local/lib/python/os.py", line 150, in makedirs
makedirs(head, mode)
File "/usr/local/sage/sage-6.2/local/lib/python/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied:
'/usr/local/sage/sage-6.2/local/share/sage/ext/octave'
I was able to get things to work by doing
mkdir -p /usr/local/sage/sage-6.2/local/share/sage/ext/octave/user
chown a+rwx /usr/local/sage/sage-6.2/local/share/sage/ext/octave/user
I particularly *HATE* the second chown -- yes, you must give write to everybody.
This of means any user could just fill up that directory and bring down the
system.
Anyway, what happened?
-- William
--
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] RFC: draft PEP for adding @ as a matrix multiplication operator to Python
On Sunday, March 9, 2014 7:20:50 PM UTC, Jeroen Demeyer wrote: > > I think the following piece should be made more clear, I don't > understand what you're trying to say here: > > The problem is that the presence of two different duck-types for numeric > data -- one where * means matrix multiply, and one where * means > elementwise multiplication -- make it impossible to write generic > functions that can operate on arbitrary data. > Indeed, it's clear from everyone's responses here that I at least need to add a new section talking about these things explicitly, and also about why elementwise-* is actually used so often in practice in numeric computation (as opposed dto symbolic comptuation), and why np.matrix is so loathed. (It really is though, I didn't just make that up :-) I doubt you can find a single developer of any numpy-using package who has anything good to say about it.) I'll try to get to write such a section over the next few hours; at least it might make a better basis for discussion. In brief, the issue is that elementwise-* is a fine convention and you can use it to write useful code, and matrix-multiply-* is a fine convention and you can use it to write useful code, but if you then try to glue those two pieces of code together into a larger system you will quickly find yourself in hell as you have to cast objects back and forth at every function call. Or similarly, if you try to write a function that works regardless of whether it receives an elementwise-*-object or a matrix-multiply-*-object, then this is also very painful (suddenly you need lots of type-checking and if statements scattered around every single function you write, it's horrible and no-one is willing to do it). This doesn't get into the reasons why numpy goes with the elementwise-* convention, but it's why it seems important to have *some* convention. (Some of the reasons for why numpy goes with elementwise-* are here: https://github.com/njsmith/numpy/blob/matmul-pep/doc/neps/return-of-revenge-of-matmul-pep.rst#choice-of-operation ; the other important reason that that section doesn't talk about as much as it could is that numpy has n-dimensional arrays, while matrix multiplication is only really natural for 2d arrays.) -n -- 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] RFC: draft PEP for adding @ as a matrix multiplication operator to Python
I think the following piece should be made more clear, I don't understand what you're trying to say here: The problem is that the presence of two different duck-types for numeric data -- one where * means matrix multiply, and one where * means elementwise multiplication -- make it impossible to write generic functions that can operate on arbitrary data. -- 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: RFC: draft PEP for adding @ as a matrix multiplication operator to Python
On 2014-03-09, Jeroen Demeyer wrote: > On 2014-03-09 16:09, n...@vorpus.org wrote: >> I definitely want to hear your feedback. > I completely agree with John Cremona: please keep * for matrix > multiplication. Why not add a new dedicated operator for elementwise > multiplication and use * for matrix multiplication? > > In your PEP, you say that using * for matrix multiplication is a bad > idea, but without any justification (the only justification is > variations on "it's a bad idea" without reasons). In fact the PEP has a justification along the lines that elementwise matrix multiplication and scalar multiplication pops up 4 times more often in numpy code. But I doubt that the count was made correctly. Even if it was the case, still this would be truly horrible idea to use * for entrywise matrix multiplication... I've posted a comment here: https://github.com/numpy/numpy/pull/4351#issuecomment-37135112 Dima > > 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] RFC: draft PEP for adding @ as a matrix multiplication operator to Python
On 2014-03-09 18:19, Jeroen Demeyer wrote: In your PEP, you say that using * for matrix multiplication is a bad idea, but without any justification (the only justification is variations on "it's a bad idea" without reasons). From reading your PEP, it's clear that you don't like numpy.matrix but you don't say what's wrong with it. -- 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] RFC: draft PEP for adding @ as a matrix multiplication operator to Python
On 2014-03-09 16:09, n...@vorpus.org wrote: I definitely want to hear your feedback. I completely agree with John Cremona: please keep * for matrix multiplication. Why not add a new dedicated operator for elementwise multiplication and use * for matrix multiplication? In your PEP, you say that using * for matrix multiplication is a bad idea, but without any justification (the only justification is variations on "it's a bad idea" without reasons). 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] RFC: draft PEP for adding @ as a matrix multiplication operator to Python
I find it very hard to imagine Sage using anything other than * (as in A*B) for normal matrix multiplication, as anything else would alienate all of its mathematical users. I would have no reason at all ever to have an element-wise matrix product! John Cremona On 9 March 2014 15:09, wrote: > Greetings, Sage Ones, > > Some of you may have already seen this, but I've started working on a draft > PEP for adding a dedicated operator for matrix multiplication to Python: > https://github.com/numpy/numpy/pull/4351 > > https://github.com/njsmith/numpy/blob/matmul-pep/doc/neps/return-of-revenge-of-matmul-pep.rst > > I'm not sure how this would affect Sage, but since I know you have both > matrix-like types and your own ideas about what various unused tokens should > mean, I figure you'll probably have opinions :-). (Also, there's some > discussion of sage.misc.decorators.infix_operator in the final section - > hopefully I'm not mischaracterizing anything there.) The overall goal is to > come up with a proposal that the whole Python numeric community can support, > and that ideally in the long run will help reduce fragmentation in matrix > APIs, so I definitely want to hear your feedback. > > -n > > -- > 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: Sage/Gp interface space efficiency issue
Each instance of the pari/GP interpreter interface has its own list of
variable names, which is initialised to length 1024 but extended (by
doubling) as needed (see src/sage/interfaces/gp.py). It seems that
this extension does not work after a certain number of doublings.
This may be some limitation of the pari vector() type You can start
new GP interfaces (probably enough to just to gp=Gp() regularly) and
use a non-default value for init_list_length than 1024 each time.
John
On 9 March 2014 12:38, Volker Braun wrote:
> The "sage" variable in various interpreters is used to keep references to
> whatever is wrapped in Sage Python objects. Have you considered using the
> pari shared library ("pari" in Sage) instead of the gp interface? Its much
> faster, too.
>
> --
> 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] RFC: draft PEP for adding @ as a matrix multiplication operator to Python
Greetings, Sage Ones, Some of you may have already seen this, but I've started working on a draft PEP for adding a dedicated operator for matrix multiplication to Python: https://github.com/numpy/numpy/pull/4351 https://github.com/njsmith/numpy/blob/matmul-pep/doc/neps/return-of-revenge-of-matmul-pep.rst I'm not sure how this would affect Sage, but since I know you have both matrix-like types and your own ideas about what various unused tokens should mean, I figure you'll probably have opinions :-). (Also, there's some discussion of sage.misc.decorators.infix_operator in the final section - hopefully I'm not mischaracterizing anything there.) The overall goal is to come up with a proposal that the whole Python numeric community can support, and that ideally in the long run will help reduce fragmentation in matrix APIs, so I definitely want to hear your feedback. -n -- 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: Call for vote about ticket #10963: axioms and more functorial constructions
On Sunday, March 9, 2014 2:16:51 PM UTC, Simon King wrote:
>
> class Cs(Category):
> class Finite(CategoryWithAxiom):
> class ParentClass:
> def some_method(self):
> return "I am a finite c"
> is also (I think) *sufficiently* explicit about Cs.Finite() being a
> sub-category of Cs(), defined by the axiom Finite.
>
This snippet defines a finite axiom that is different from the finite axiom
for sets, and your parents will not have a "is_finite()" method. Only once
you join finite Cs with (not necessarily finite) Sets then suddenly you
also inherit "is_finite()". Depending on your viewpoint this is an awesome
feature or devastating if you want new developers to use the category
framework.
> What I am really not happy about is that in some cases (or in all? If
> not in all, then in what cases?) Cs.Finite is overridden in Cs() by a
> cached method.
>
Really, the whole subclass-as-axiom magic is just an attempt at syntactic
sugar. The only thing that matters is that Cs().Finite() returns an
instance of the the axiom. There are various functionally equivalent ways
to implement it. There is yet another syntax to achieve the same end,
namely Cs().with_axiom("Finite"). Except for the strings I would be much
happier with that since it doesn't require an open-ended list of magic
attribute names for axioms.
--
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: Call for vote about ticket #10963: axioms and more functorial constructions
Hi Volker, On 2014-03-09, Volker Braun wrote: > "Explicit from the context" is an oxymoron. If you can only be figure it=20 > out from the context, then it is by definition implicit. Only something=20 > that is written down in Python code is explicit in Python. But what other syntax do you suggest? Doing class Cs(Category): def super_categories(self): return [Sets()] *explicitly* states that Cs is a sub-category of the category of sets. Additionally doing class Cs(Category): class Finite(CategoryWithAxiom): class ParentClass: def some_method(self): return "I am a finite c" is also (I think) *sufficiently* explicit about Cs.Finite() being a sub-category of Cs(), defined by the axiom Finite. So, Cs.Finite() is a sub-category of Sets(). Do you think that an additional explicit statement is needed to tell that Cs.Finite() additionally is a sub-category of Sets.Finite()? I believe that the rule implemented in #10963 "Cs().SomeAxiom() is a sub-category of SCs().SomeAxiom() for all super-categories SCs() of Cs() to which SomeAxiom can be applied" is clear enough. What I am really not happy about is that in some cases (or in all? If not in all, then in what cases?) Cs.Finite is overridden in Cs() by a cached method. Nicolas hasn't answered yet if documentation respectively semantic specification of the "Finite" axiom is the only reason for this highly intransparent trick. If it is, then I think it would be better to turn axioms into objects (currently they are just names) carrying their own documentation and specification. Best regards, Simon -- 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: Call for vote about ticket #10963: axioms and more functorial constructions
"Explicit from the context" is an oxymoron. If you can only be figure it out from the context, then it is by definition implicit. Only something that is written down in Python code is explicit in Python. I guess that is a bit of an English language issue. Or, as the old joke goes, "It depends on what the meaning of the words 'is' is." On Saturday, March 8, 2014 9:32:21 PM UTC, Nicolas M. Thiéry wrote: > > the general Python rule > "explicit is better than implicit" is to be taken with a grain of > salt. Basically, "explicit" should be interpreted as "explicit from > the code or from the math context". > -- 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: Call for vote about ticket #10963: axioms and more functorial constructions
On Friday, 7 March 2014 23:14:44 UTC+11, Nicolas M. Thiéry wrote: > > Dear Sage developers, > > This is a call for vote about the ticket: > > #10963: axioms and more functorial constructions [1] > > Dear Nicolas, I think that it is good that this is being done (thank you!) but, like some others, I'm not fond of the use of implicit code and black magic whenever this makes it hard to track down the real source of some of the code. If everything is well documented and explained then this is probably OK, although I feel that one of the problems with python/sage documentation is that we are encouraged to write good documentation for methods but there is little emphasis of writing a self-contained general overview of what is going on -- I've even had reviewers take this out when I have tried to write it. To take the category framework as an example, I have fought with it and won on several occasions but it is always been a painful experience because I find that the documentation is not very helpful. Of course, perhaps it is just me but I find that most of the example code in the documentation is artificial and treats only simplified situations and that many little "secrets" are not documented at all. To be fair good documentation is hard to write, especially when you have a complex piece of code. Even so, in my experience there is quite a lot of undocumented magic in the category framework. I hope that the documentation for the functorial constructions patch is more helpful. Andrew -- 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: Error compiling dev version
Fixed in a later version. -- 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: Sage/Gp interface space efficiency issue
The "sage" variable in various interpreters is used to keep references to
whatever is wrapped in Sage Python objects. Have you considered using the
pari shared library ("pari" in Sage) instead of the gp interface? Its much
faster, too.
--
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] Sage/Gp interface space efficiency issue
I'm trying to find asymptotic bounds for the number of polynomials of
degree $n$ and height $\leq N$ with a specific Galois group (e.g.
$Syl_2(S_n)$, or in the example below $S_n$). I build all monic polynomials
with the given parameters, then ask pari for the order of their Galois
groups using the command
gp.polgalois(p)[1]
The problem is, when both $n$ and $N$ are both still relatively small, some
sort of data structure seems to be filling up, thereby causing a strange
error. It appears that this structure is saving the commands I have passed
to gp. The problem is cumulative, meaning this data structure is not
cleared unless I quit my Sage session and restart.
Perhaps the problem is best explained via an example. I can run the
function I constructed for $n=4, 2 \leq N \leq 4$, but when I try to run it
for $n=4, N=5$, the error appears:
sage: E4(5)
---
TypeError Traceback (most recent call last)
in ()
> 1 E4(Integer(5))
in E4(N)
/opt/sage/local/lib/python2.7/site-packages/sage/interfaces/interface.py
in__getitem__
(self, n)
945 P = self._check_valid()
946 if not isinstance(n, tuple):
--> 947 return P.new('%s[%s]'%(self._name, n))
948 else:
949 return P.new('%s[%s]'%(self._name, str(n)[1:-1]))
/opt/sage/local/lib/python2.7/site-packages/sage/interfaces/gp.py in set(
self, var, value)
509 out = self.eval(cmd)
510 if out.find('***') != -1:
--> 511 raise TypeError, "Error executing code in
GP:\nCODE:\n\t%s\nPARI/GP ERROR:\n%s"%(cmd, out)
512
513
TypeError: Error executing code in GP:
CODE:
sage[65536]=sage[65535][1];
PARI/GP ERROR:
*** at top-level: sage[65536]=sage[65535][1]
***^---
*** _[_]: not a vector.
The ellipses denote the error being traced through several different
methods within the file
/opt/sage/local/lib/python2.7/site-packages/sage/interfaces/gp.py
If you would like to see the entire example session in which I produced the
error message above, go to:
http://sharetext.org/GlBk
Noting that $65536=2^16$, it seems that this is quite a natural place for
this data structure (denoted by 'sage[]' in the example) to be filling up.
Unfortunately, this structure is essentially inaccessible from the Sage
command line.
I should also note that I attempted to fix the problem with the command
gp.eval('allocatemem()')
but this did not fix the problem.
Any sort of explanation of what this data structure is, how I can clear it
between calls to pari, or even some sort of black box workaround, would be
greatly appreciated.
--
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.
