[sage-devel] Unpacking sage i could not manage to. Would anybody give me a hint please i am a newby! Thanks
┐ │ SageMath version 8.1, Release Date: 2017-12-07 │ │ Type "notebook()" for the browser-based notebook interface.│ │ Type "help()" for help.│ └┘ Traceback (most recent call last): File "/usr/share/sagemath/bin/sage-ipython", line 7, in from sage.repl.interpreter import SageTerminalApp File "/usr/lib/python2.7/dist-packages/sage/repl/interpreter.py", line 108, in from sage.repl.prompts import SagePrompts, InterfacePrompts File "/usr/lib/python2.7/dist-packages/sage/repl/prompts.py", line 15, in from pygments.token import Token ImportError: No module named pygments.token -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Unpacking sage i could not manage to. Would anybody give me a hint please i am a newby! Thanks
Hi, I'm assuming you're running Sage from the Debian package. Is that correct? It's possible that something about your Debian installation is broken somehow.We'd need more information such as how you installed Sage, what you ran,if you have any strange environment variables set (try running `sage -sh -c env` for example). Without more details about your system and what you did it's hard to say much. On Mon, May 28, 2018 at 7:33 AM, Elaettin Yesilcimen wrote: > ┐ > │ SageMath version 8.1, Release Date: 2017-12-07 │ > │ Type "notebook()" for the browser-based notebook interface.│ > │ Type "help()" for help.│ > └┘ > Traceback (most recent call last): > File "/usr/share/sagemath/bin/sage-ipython", line 7, in > from sage.repl.interpreter import SageTerminalApp > File "/usr/lib/python2.7/dist-packages/sage/repl/interpreter.py", line > 108, in > from sage.repl.prompts import SagePrompts, InterfacePrompts > File "/usr/lib/python2.7/dist-packages/sage/repl/prompts.py", line 15, in > > from pygments.token import Token > ImportError: No module named pygments.token > > -- > 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 https://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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Matrix groups are not uniquely represented, why?
On Sat, May 26, 2018 at 6:24 AM, Travis Scrimshaw wrote: > MatrixGroups are immutable and their comparison is by checking the > generators (and not isomorphism), which are essentially the construction > parameters (in reality, they are the corresponding GAP group). For > permutation groups, the equality seems to be isomorphism. So there is no > problem for MatrixGroups being UniqueRepresentation in terms of behavior. +1 in principle. Nils has said to me as well that UniqueRepresention (or even simply CachedRepresentation) is known for introducing memory leaks. I certainly believe that--one doesn't come to such a conclusion without hard-earned experience. But I'm skeptical that that's something inherent to its design that can't be overcome with correct use. Obviously it should not be used with classes that are not truly immutable. I think Sage could use a better way to keep track of and/or enforce immutability of classes (that is, instances of classes). For example, have some base class which can be used as a mix-in (or an ABC) that designates something as immutable, and disallow assigning any attributes to its dict that aren't also immutable (including of course support for all the common built-in types). Of course, getting something like that right is not completely trivial and would require a lot of overhaul. I'm just surprised that it isn't already something that is considered more systematically. > On Saturday, May 26, 2018 at 5:53:15 AM UTC+10, Nils Bruin wrote: >> >> >> >> On Friday, May 25, 2018 at 12:17:35 PM UTC-7, Simon King wrote: >>> >>> But they could still be CachedRepresentation. Then, if the same subgroup >>> is given by the same generators, it is identical, but if the same >>> subgroup is given by different generators, it is just equal but not >>> identical. >>> >> But before doing so, you would need to show that in common scenarios it >> produces a benefit. It has three significant draw-backs: >> - you'd slow down the creation of matrix groups in general, because >> you're requiring the system to first go and look if there already is an >> object like it. >> - because the object you get *may* be shared with other code, you're at >> the mercy of that other code to not mutate it. (and you have to behave >> yourself too) >> - it would likely introduce memory leaks (because it's the >> CachedRepresentation part of UniqueRepresentation that makes these leaks >> likely). >> > > -- > 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 https://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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Matrix groups are not uniquely represented, why?
Hi Erik
On 2018-05-28, Erik Bray wrote:
> I think Sage could use a better way to keep
> track of and/or enforce immutability of classes (that is, instances of
> classes). For example, have some base class which can be used as a
> mix-in (or an ABC) that designates something as immutable, and
> disallow assigning any attributes to its dict that aren't also
> immutable (including of course support for all the common built-in
> types).
I don't think this could possibly work. But actually that's not a Sage
problem but a Python problem: Perhaps somewhere in the Python ecosystem
such a mix-in class exists?
However, I find your notion of immutability ("do not allow assigning
attributes and make all existing attributes immutable") far too narrow.
IIRC, immutable means that once the object is created, its equivalence
class with respect to the "==" operator will be preserved no matter what
of its (no-underscore?) methods are called.
Thus, I believe it must be allowed to assign to an attribute of object X,
as long as the behaviour of X==Y remains unchanged for all objects Y
(and of course hash(X) doesn't change either).
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] IPython transformations rework
Thomas Kluyver is reworking the input transformation framework for IPython for IPython 7, and is requesting input from whoever is doing transformations. Whoever is working on the input transformations for Sage these days might want to chime in: https://mail.python.org/pipermail/ipython-dev/2018-May/thread.html#16320 Thanks, Jason -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Matrix groups are not uniquely represented, why?
On Monday, May 28, 2018 at 7:24:31 AM UTC-7, Simon King wrote:
>
> However, I find your notion of immutability ("do not allow assigning
> attributes and make all existing attributes immutable") far too narrow.
> IIRC, immutable means that once the object is created, its equivalence
> class with respect to the "==" operator will be preserved no matter what
> of its (no-underscore?) methods are called.
>
> Thus, I believe it must be allowed to assign to an attribute of object X,
> as long as the behaviour of X==Y remains unchanged for all objects Y
> (and of course hash(X) doesn't change either).
>
That's a definition of "immutable" that suffices for using things as keys
in dictionaries. However, if the object you created might be referenced
elsewhere, in totally unrelated code (because that code happens to have
called PolynomialRing(Rationals(),names=['x','y']) as well) then you need
to be a *lot* more careful. I'm not sure that locking some objects
completely from mutation would be a feasible solution (it will be nearly
impossible to enforce in python, and we might not be able to get proper
performance with it), but if programmers don't take this very seriously
we'll end up with a code base that is very difficult to reason about.
The conflation of the two notions of immutability, and the different levels
of enforcement required for them, is what worries me about
UniqueRepresentation. Originally, the use of UniqueRepresentation was
required to ensure the system could *repeatedly* produce identical objects
automatically, based on input parameters, see
https://trac.sagemath.org/ticket/25388#comment:10 . It has the side-effect
of allowing quick equality-by-identity checking. So it may *look* like
UniqueRepresentation is a great way of speeding up "==" and "hash" for
things that are immutable, but it requires a much higher level of
immutability than required for hash.
(and in practice, the memory leaks caused by UniqueRepresentation bite us
with clockwork regularity)
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
