OT but yet not OT:
http://existentialcomics.com/comic/86
"Why don't you have strict type checking on?"
"An Übermensch coder like me doesn't need it"
"Turn it on, Nietzsche!"
Good thing we use Python.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" grou
Hi Jeroen,
Great, thank you! That did indeed do the trick!
Anne
On Monday, June 22, 2015 at 1:02:21 AM UTC-7, Jeroen Demeyer wrote:
>
> It seems the directories don't match: the actual directory is
> /home/anne/sage-6.4.1
> which some libraries refer to
> /home/anne/sage
>
> I would reinstal
If the input is a (syntactically) mutable object without a hash, it errors
out. If the mutable object has a hash, then that is a bug. However the
output should be immutable (but doesn't necessarily have to be hashable).
Best,
Travis
On Tuesday, June 23, 2015 at 2:40:55 PM UTC-7, Nathann Cohen
> If a @cached_method accepts mutable objects, that's a bug.
Is it ? We could easily add checks for that.
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
If a @cached_method accepts mutable objects, that's a bug.
On Tue, Jun 23, 2015 at 12:48 AM, Volker Braun wrote:
> On Tuesday, June 23, 2015 at 3:40:24 AM UTC+2, William wrote:
>>
>> What about something explicit, e.g.,
>>A.add_inplace(B)
>> which would mutate A and be very clear and explicit
There's also a "performance" option.
Best,
Travis
On Tuesday, June 23, 2015 at 12:22:26 PM UTC-7, Nils Bruin wrote:
>
> On Tuesday, June 23, 2015 at 11:59:14 AM UTC-7, Jori Mäntysalo wrote:
>>
>> (Why don't we have "optimization" or "improving" as a type of ticket?)
>>
>
> According to Merriam-
Success.
Thanks so much for your help, Volker.
Final comments...
At some point in the past, on the first or second failure to build and long
before I reached out for help, I did the following apparent no-no:
I noticed that the c++, gcc, etc. files in
/Library/Developer/CommandLineTools/usr/bin
On Tuesday, June 23, 2015 at 11:59:14 AM UTC-7, Jori Mäntysalo wrote:
>
> (Why don't we have "optimization" or "improving" as a type of ticket?)
>
According to Merriam-Webster:
enhance: to increase or improve (something)
--
You received this message because you are subscribed to the Google G
On Tue, 23 Jun 2015, Travis Scrimshaw wrote:
This would definitely be a good optimization. Open a ticket.
http://trac.sagemath.org/ticket/18776
(Why don't we have "optimization" or "improving" as a type of ticket?) I
don't know how to fix this. "Authors"-field is open...
--
Jori Mäntysalo
On 2015-06-23 17:41, Nils Bruin wrote:
It's true that P.__iadd__ is the inherited
sage.structure.element.ModuleElement.__iadd__ that does try to P._iadd_
if a reference threshold is met
A threshold which is 0 currently. And it's exactly this which I want to
remove since it's not used because it'
This would definitely be a good optimization. Open a ticket.
Best,
Travis
On Tuesday, June 23, 2015 at 12:45:03 AM UTC-7, Jori Mäntysalo wrote:
>
> P = Poset({0:[1]})
> Q = Poset(P)
> L = LatticePoset(P)
> P._hasse_diagram is Q._hasse_diagram, P._hasse_diagram is L._hasse_diagram
>
> -->
>
On Tuesday, June 23, 2015 at 1:04:58 AM UTC-7, John Cremona wrote:
>
> Here's an example:
>
> sage: E = EllipticCurve(GF(101),[0,1,1,1,0])
> sage: P = E.random_point()
> sage: P.order()
> 8
> sage: P+=P
> sage: P.order()
> 4
>
> Now, after calling P.order(), P caches its order. Luckily the
Hello all,
I just created a new Trac component "interfaces: optional" for all
"interfaces" issues with not-standard parts of Sage:
optional/experimental packages but also external interfaces, for example
commercial Ma* packages.
Jeroen.
--
You received this message because you are subscribe
>
> > You might name that "trolling", I name it "calling out lousy
> practices".
But you keep screaming, without any goal in mind. That's called
> trolling. So stop the play, and if you want to help us you can send an
>
>
Okay, it's clear there is a disagreement about this and how best to
a
> I'm not serious, I'm sarcastic : what's the point of putting aside a few
> patches in a clean way if the upstream tarball is a mess already?
>
> You might name that "trolling", I name it "calling out lousy practices".
No, you are just trolling. We keep telling you that we did all we
could for up
Le 23/06/2015 12:40, Jeroen Demeyer a écrit :
On 2015-06-23 09:44, Julien Puydt wrote:
But after some digging around :
- the tarball isn't pristine, it's heavily patched ;
It's not "heavily patched", just the build system was changed.
*just* !
- one has to wonder why the remaining pat
On 2015-06-23 09:44, Julien Puydt wrote:
But after some digging around :
- the tarball isn't pristine, it's heavily patched ;
It's not "heavily patched", just the build system was changed.
- one has to wonder why the remaining patches aren't in the tarball
already...
Are you serious? You woul
Thank you, now it works !
Le vendredi 19 juin 2015 20:54:39 UTC+2, Volker Braun a écrit :
>
> You are missing part of Perl. Perl is a requirement for Sage. Ask your
> administrator.
>
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscr
On Mon, Jun 22, 2015 at 01:09:57PM +0200, Nathann Cohen wrote:
> I was about to say that "such forums tend to restrict to a subset of
> developers some conversations that have an impact for everybody".
>
> I just loaded sage-combinat's forum, to find out that there is a
> question there about grap
On Mon, Jun 22, 2015 at 08:02:55AM +0300, Jori Mäntysalo wrote:
> How should ideas about posets and lattices be collected? (In general: about
> some topic X on Sage.)
>
> For example there should be a function to check if a poset is
> series-parallel composable, a function to see if a lattice is v
On Mon, Jun 22, 2015 at 01:24:24PM +0200, Nathann Cohen wrote:
> I never claimed that graph theory was not a subfield of combinatorics.
> What I fight against is this group's pretense to control everything
> that is connected with combinatorics, by 'coining' a general
> mathematical term. Sage-comb
On 23 June 2015 at 08:53, Volker Braun wrote:
> On Tuesday, June 23, 2015 at 8:34:38 AM UTC+2, Nils Bruin wrote:
>>
>> Also, if A is immutable, then an explicit mutating operation would be
>> uncalled for. If A is mutable then we can just implement __iadd__ without
>> concern for reference counts.
> What I'm railing against is that this is a package where I obtained on the
> one hand a nice upstream/planarity-2.2.0.tar.bz2 and on the other end I have
> a very clean build/pkgs/planarity/ directory with simple patches :
> wonderful!
>
> ...
>
> I'm not just slacking off and critisizing... I'm
On Tuesday, June 23, 2015 at 8:34:38 AM UTC+2, Nils Bruin wrote:
>
> Also, if A is immutable, then an explicit mutating operation would be
> uncalled for. If A is mutable then we can just implement __iadd__ without
> concern for reference counts.
>
I agree, only explicitly mutable objects are
On Tuesday, June 23, 2015 at 3:40:24 AM UTC+2, William wrote:
>
> What about something explicit, e.g.,
>A.add_inplace(B)
> which would mutate A and be very clear and explicit.
"A" might be stored in a @cached_method without the user being aware of it.
--
You received this message because
P = Poset({0:[1]})
Q = Poset(P)
L = LatticePoset(P)
P._hasse_diagram is Q._hasse_diagram, P._hasse_diagram is L._hasse_diagram
-->
(True, False)
Why so? Poset is immutable, so I don't understand why another copy of
Hasse diagram is made.
--
Jori Mäntysalo
Hi,
Le 22/06/2015 17:25, Nathann Cohen a écrit :
I was heartily congratulating about having small reasonable patches to
upstream, and you tell me that they're in fact against an heavily patched
upstream, and upstream's licensing situation is muddy... no need to troll
when the facts are so prepo
27 matches
Mail list logo
