Re: [sage-devel] Re: About recmpilations caused by Git

[Jeroen Demeyer]

On 2014-11-18 23:15, Andrew wrote:

That is, the manual states that the recommended route is to use sage -br
unless you are modifying packages.
The manual is technically correct but can easily be misinterpreted. The 
problem is that switching branches often *does* modify packages.


In some cases (a package upgrade which isn't tied closely to the Sage 
library), you can get away with "./sage -b" and not building the new 
package, but for some package changes, you really need to run "make".


My workflow is:
1. checkout the relevant branch that I want to work on
2. run "make"
3. make edits (this can be done in parallel with 2)
4. run "./sage -br"
5. goto 3

--
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: Code of Conduct

[William Stein]

On Nov 18, 2014 6:44 PM, "kcrisman"  wrote:
>
> Commenting on a good point even though this is abandoned:
>
>>
>> > the top 12  all time list of contributors to Sage, in order, are:
>> >
>> > [a list of 12 dudes]
>> >
>>
>> In the event of a gender-polarizing conflict, this committee will not
>> be seen as unbiased.  In order to increase minority representation, I
>
>
> True, but currently unavoidable by that presumably-flawed metric.  The
only way to *really* fix this is for everyone to encourage their female
colleagues/students/friends/enemies/frenemies to start using, and
eventually contributing to Sage.  This is a lot easier from my more
pedagogically-focused context, but of course such people also are markedly
less likely to become developers.  This is part of a larger societal
picture in math and CS that Sage cannot (by itself, that is) fix.
>

Just a big shout out here to the hard work of All Deines and Jen
Balakrishnan and others for organizing at least five women encouraging sage
days workshops, and to Microsoft Research and Beatrice York fund for fully
funding all of them.  And there will be many more to come!

> --
> 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] Maple versus Mathematica

[kcrisman]

>
> > Problems arise when thinking about more complicated mathematical 
>> objects. I 
>> > don't know if I simply lack the appropriate Mathematica knowledge, but 
>> years 
>> > ago, when I implemented matroids in Mathematica, a matroid was simply a 
>> list 
>> > with 6 elements (groundset, representation matrix, and I forget what 
>> else) 
>> > and head Matroid. To access the elements of that list, you did stuff 
>> like 
>> > this: 
>> > 
>> > lM = Map[If[# == 0, 0, 1] &, M[[2]][[#[[2]] & /@ M[[3]], #[[2]] & /@ 
>> > M[[4, {2}]; 
>>
>> Holy f*2}];ng s&/@! 
>>
>>
>
 Let's hope the younger matroid theorists never have to see such obfuscated 
code again, thanks to your (and others') work!

-- 
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: Code of Conduct

[kcrisman]

Commenting on a good point even though this is abandoned:
 

> > the top 12  all time list of contributors to Sage, in order, are: 
> > 
> > [a list of 12 dudes] 
> > 
>
> In the event of a gender-polarizing conflict, this committee will not 
> be seen as unbiased.  In order to increase minority representation, I 
>

True, but currently unavoidable by that presumably-flawed metric.  The only 
way to *really* fix this is for everyone to encourage their female 
colleagues/students/friends/enemies/frenemies to start using, and 
eventually contributing to Sage.  This is a lot easier from my more 
pedagogically-focused context, but of course such people also are markedly 
less likely to become developers.  This is part of a larger societal 
picture in math and CS that Sage cannot (by itself, that is) fix.

-- 
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] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 18, 2014 at 6:51 PM, Bill Page  wrote:
> On 18 November 2014 17:40, Ondřej Čertík  wrote:
>>
>> In my notation, the Wirtinger derivative is d f(z) / d z and d f(z) /
>> d conjugate(z). The Df(z) / Dz is the complex derivative taking in
>> direction theta (where it could be theta=0). Given the chain rule, as
>> I derived above using chain rules for the Wirtinger derivative:
>>
>> D f(g) / D z = df/dg Dg/Dz + df/d conjugate(g) D conjugate(g) / Dz
>>
>> I don't see why you would need the isolated Wirtinger derivatives.
>
> You mean that only the function being differentiated needs to the
> Writinger derivatives (as part of the "formula" that it implements for
> the chain rule)?

Did you mean to write "You mean that only the function being
differentiated needs to do the
Writinger derivatives..."?

Yes.

>
>> The
>> method that implements the derivative of the given function, like
>> log(z) or abs(z) would simply return the correct formula, as I said
>> above, e.g.
>>
>> log(z).diff(z) = 1/z
>>
>> abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / 
>> (2*abs(f))
>>
>
> If the chain rule must  be implemented by each function then I suppose
> that you also have
>
>   log(f).diff(z) = f.diff(z) / z
>
> right?

Yes, correct.

>
>> Both formulas hold for any theta.
>
> The generality provided by theta seems not be be of much interest.

I agree, I think one can implicitly set theta=0 in a CAS. So that's
the option 2) in my email above.

>
>> I guess it depends on how the CAS is implemented, maybe
>> some CASes have a general machinery for derivatives. But
>> I am pretty sure you can simply implemented it as I outlined.
>>
>> Let me know if you found any issue with this.
>>
>
> Is this how derivatives are implemented in sympy?

It's a little more complicated in sympy, but that's how derivatives
are implemented in csympy (https://github.com/sympy/csympy).

Ondrej

-- 
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] Bug in abs(I*x).diff(x)

[Bill Page]

On 18 November 2014 17:40, Ondřej Čertík  wrote:
>
> In my notation, the Wirtinger derivative is d f(z) / d z and d f(z) /
> d conjugate(z). The Df(z) / Dz is the complex derivative taking in
> direction theta (where it could be theta=0). Given the chain rule, as
> I derived above using chain rules for the Wirtinger derivative:
>
> D f(g) / D z = df/dg Dg/Dz + df/d conjugate(g) D conjugate(g) / Dz
>
> I don't see why you would need the isolated Wirtinger derivatives.

You mean that only the function being differentiated needs to the
Writinger derivatives (as part of the "formula" that it implements for
the chain rule)?

> The
> method that implements the derivative of the given function, like
> log(z) or abs(z) would simply return the correct formula, as I said
> above, e.g.
>
> log(z).diff(z) = 1/z
>
> abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / 
> (2*abs(f))
>

If the chain rule must  be implemented by each function then I suppose
that you also have

  log(f).diff(z) = f.diff(z) / z

right?

> Both formulas hold for any theta.

The generality provided by theta seems not be be of much interest.

> I guess it depends on how the CAS is implemented, maybe
> some CASes have a general machinery for derivatives. But
> I am pretty sure you can simply implemented it as I outlined.
>
> Let me know if you found any issue with this.
>

Is this how derivatives are implemented in sympy?

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] Bug in abs(I*x).diff(x)

[w huang]

Hi, 

With Sage 6.3, I am getting: 

sage: abs(x).diff(x) 
x/abs(x) 
sage: abs(I*x).diff(x) 
-x/abs(I*x) 

But abs(I*x) == abs(x). So also abs(x).diff(x) and abs(I*x).diff(x) 
must be the same. But in the first case we get x/abs(x), and in the 
second we got -x/abs(x). 

In SymPy, the answer is: 
--///

www.mathHandbook.com show
http://www.mathHandbook.com/input/?guess=d(abs(x))  

-- 
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: Code of Conduct

[William Stein]

On Tue, Nov 18, 2014 at 3:14 PM, Tom Boothby  wrote:
> On Tue, Nov 18, 2014 at 10:36 AM, William Stein  wrote:
>
>> Given the potentially political nature of such a choice, one
>> possibility is to do something apolitical, and select based on
>> ownership. In particular, based on lines of code contributed to Sage,
>> which is an (imperfect!) but non-politicial measure of how much
>> ownership people have in Sage (with legal value, since people do not
>> contribute their copyright).By this definition:
>>
>>
>> https://github.com/sagemath/sage/graphs/contributors?from=2006-02-05&to=2014-11-18&type=a
>>
>> the top 12  all time list of contributors to Sage, in order, are:
>>
>> [a list of 12 dudes]
>>
>
> In the event of a gender-polarizing conflict, this committee will not
> be seen as unbiased.  In order to increase minority representation, I
> would suggest that a maximum of 2/3 of the committee should be
> comprised of a particular gender.  Perhaps the top 8 contributors,
> followed by the top 4 who do not identify as male.

Since I attempted to retract this proposal in light of Volker's
sensible criticism, and people keep responding as if I didn't, let me
officially retract this proposal.

Instead I support what I think Volker suggested, which is using our
existing completely open voting process on sage-devel, as we have been
doing for years, for sage-abuse issues.   But to make it clear that we
care about sage-abuse issues and make clear the existence of
sage-flame.


-- 
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] Re: Code of Conduct

[Tom Boothby]

On Tue, Nov 18, 2014 at 10:36 AM, William Stein  wrote:

> Given the potentially political nature of such a choice, one
> possibility is to do something apolitical, and select based on
> ownership. In particular, based on lines of code contributed to Sage,
> which is an (imperfect!) but non-politicial measure of how much
> ownership people have in Sage (with legal value, since people do not
> contribute their copyright).By this definition:
>
>
> https://github.com/sagemath/sage/graphs/contributors?from=2006-02-05&to=2014-11-18&type=a
>
> the top 12  all time list of contributors to Sage, in order, are:
>
> [a list of 12 dudes]
>

In the event of a gender-polarizing conflict, this committee will not
be seen as unbiased.  In order to increase minority representation, I
would suggest that a maximum of 2/3 of the committee should be
comprised of a particular gender.  Perhaps the top 8 contributors,
followed by the top 4 who do not identify as male.

-- 
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] Maple versus Mathematica

[William Stein]

On Tue, Nov 18, 2014 at 2:37 PM, Stefan  wrote:
> Problems arise when thinking about more complicated mathematical objects. I
> don't know if I simply lack the appropriate Mathematica knowledge, but years
> ago, when I implemented matroids in Mathematica, a matroid was simply a list
> with 6 elements (groundset, representation matrix, and I forget what else)
> and head Matroid. To access the elements of that list, you did stuff like
> this:
>
> lM = Map[If[# == 0, 0, 1] &, M[[2]][[#[[2]] & /@ M[[3]], #[[2]] & /@
> M[[4, {2}];

Holy f*2}];ng s&/@!

>
> I don't miss that aspect of Mathematica one bit! Python objects are so much
> nicer, and we still get lambda functions when we need them.
>
> Also, it might be experience, but I spent WAY more time debugging my
> Mathematica code than debugging my Python code.
>
> --
> 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.

Re: [sage-devel] Maple versus Mathematica

[Harald Schilly]

On Tue, Nov 18, 2014 at 11:37 PM, Stefan  wrote:
> Problems arise when thinking about more complicated mathematical objects.

This is also my main argument ... The core point is, that Python
allows you to define higher-level data-types, which are some
combination of data structures and convey a semantic meaning by the
class name.

I also think Python libs like "toolz"/"cytoolz" show that there is a
lot possible towards functional-stylish programming in Python. And
about functional programming, to my understanding there is a global
state, right? At least that's what I understand from MMA by having
variable assignments and ingredients like "Module". Correct me if I'm
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.

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 18, 2014 at 2:50 PM, Bill Page  wrote:
> On 18 November 2014 15:19, Ondřej Čertík  wrote:
>> On Tue, Nov 18, 2014 at 12:14 PM, Bill Page  
>> wrote:
>>>
>>>   abs(x).diff(x)
>>>
>>> would return the symbolic expression
>>>
>>>   conjugate(x)/(2*abs(x)) + conjugate(x)/(2*abs(x))* e^{-2*i*theta}
>>
>> I think you made a mistake, the correct expression is:
>>
>> conjugate(x)/(2*abs(x)) + x/(2*abs(x)) * e^{-2*i*theta}
>>
>
> Yes, sorry.
>
>>> ...
>>> I thought rather that what you were proposing was to set theta=0
>>> from the start.  If you did that, then I think you still have problems
>>> with the chain rule.
>>
>> For a CAS, I was leaning towards using theta=0. But given your
>> objections, I first needed to figure out the most general case that
>> covers everything. I think that's now sufficiently clarified.
>>
>
> OK.
>
>>> Let me add that the kind of solution to this problem that I did
>>> imagine was to implement two derivatives, for example both
>>>
>>>   f.diff(z) = df/dz + df/d conjugate(z)
>>>
>>> and
>>>
>>>   f.diff2(z) = df/dz - df/d conjugate(z)
>>>
>>> diff(z) would equal diff2(z) for all analytic functions and diff would
>>> reduce to the derivative of real non-analytic functions as you desire.
>>
>> Right, diff() is for theta = 0. diff2() is for theta=pi/2, i.e. taking
>> the derivative along the imaginary axis.
>>
>>> Note that for abs we have
>>>
>>>   abs(z).diff2(z) = 0
>>
>> Actually, for abs you have:
>>
>> abs(z).diff2(z) = (conjugate(z)-z)/(2*abs(z))
>>
>
> Yes again, sorry.  Of course 0 only if conjugate(z)=z.
>
>>> but not in general.  There would be no need to discuss this 2nd
>>> derivative with less experienced users until they were ready to
>>> consider more "advanced" mathematics.
>>>
>>> Clearly we could implement the chain rule given these two derivatives.
>> ...
>
> On 18 November 2014 15:46, Ondřej Čertík  wrote:
>> On Tue, Nov 18, 2014 at 1:19 PM, Ondřej Čertík  
>> wrote:
>> ..
>>>
>>> So I think that functions can return their own correct derivative, for
>>> example analytic functions just return the unique complex derivative,
>>> for example:
>>>
>>> log(z).diff(z) = 1/z
>>>
>>> This holds for all cases. Non-analytic functions like abs(f) can return:
>>>
>>> abs(f).diff(z) = (conjugate(f)*f.diff(z) +
>>> f*conjugate(f).diff(z)*e^{-2*i*theta}) / (2*abs(f))
>>
>> Actually, I think I made a mistake. Let's do abs(f).diff(x) again for
>> the most general case. We use:
>>
>> D f(g) / D z =
>>
>> = df/dg * (dg/dz + dg/d conjugate(z) * e^{-2*i*theta}) + df/d
>> conjugate(g) * (d conjugate(g)/dz + d conjugate(g)/d conjugate(z) *
>> e^{-2*i*theta}) =
>>
>> = df/dg Dg/Dz + df/d conjugate(g) D conjugate(g) / Dz
>>
>> Which we derived above. We have f(g) -> |g| and g(z) -> f(z). So we get:
>>
>> D |f| / Dz = d|f|/df * Df/Dz + d|f|/d conjugate(f) * D conjugate(f) / Dz =
>>
>> = (conjugate(f) * Df/Dz + f * D conjugate(f) / Dz) / (2*abs(f))
>>
>> And then:
>>
>> Df/Dz = f.diff(z)
>> D conjugate(f) / Dz = conjugate(f).diff(z)
>>
>> So I think the formula:
>>
>> abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / 
>> (2*abs(f))
>>
>> is the most general formula for any theta. The theta dependence is hidden
>> in conjugate(f).diff(z), since if "f" is analytic, like f=log(z), the
>> conjugate(f) is not analytic, and so the derivative is theta dependent.
>>
>> The below holds though:
>>
>>>
>>> I think that's the correct application of the chain rule. We can set
>>> theta=0, so we would just return:
>>>
>>> abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / 
>>> (2*abs(f))
>>>
>>> Which for real "f" (i.e. conjugate(f)=f) simplifies to (as a special case):
>>>
>>> abs(f).diff(z) = (f*f.diff(z) + f*f.diff(z)) / (2*abs(f)) = f/abs(f) *
>>> f.diff(z) = sign(f) * f.diff(z)
>>>
>>> So it all works.
>>>
>>> Unless there is some issue that I don't see, it seems to me we just
>>> need to have one diff(z) function, no need for diff2().
>>>
>
> Hmmm... So given only f(z).diff(z) as you have defined it above, how
> do I get Df(z)/D conjugate(z), i.e. the other Wirtinger derivative?
> Or are you claiming that this is not necessary in general in spite of
> the Wirtinger  formula for the chain rule?

In my notation, the Wirtinger derivative is d f(z) / d z and d f(z) /
d conjugate(z). The Df(z) / Dz is the complex derivative taking in
direction theta (where it could be theta=0). Given the chain rule, as
I derived above using chain rules for the Wirtinger derivative:

D f(g) / D z = df/dg Dg/Dz + df/d conjugate(g) D conjugate(g) / Dz

I don't see why you would need the isolated Wirtinger derivatives. The
method that implements the derivative of the given function, like
log(z) or abs(z) would simply return the correct formula, as I said
above, e.g.

log(z).diff(z) = 1/z

abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / (2*abs(f))

Both formulas hold for any theta. I guess it depends on how the CAS is
implemented, maybe some CASes have a gen

Re: [sage-devel] Re: About recmpilations caused by Git

[William Stein]

On Tue, Nov 18, 2014 at 2:15 PM, Andrew  wrote:
>
>> > I've gone back to sage -b.
>> Please don't, or at the very least don't ever report a bug or failing
>> doctest without doing "make" first.
>
>
> I am confused by Jeroen's comment. According to the sage 6.4 developers
> guide:
>
> Rebuilding Sage
>
> Once you have made any changes you of course want to build Sage and try out
> your edits. As long as you only modified the Sage library (that is, Python
> and Cython files under src/sage/...) you just have to run:
> [user@localhost sage]$ ./sage -br
>
> to rebuild the Sage library and then start Sage. This should be quite fast.
> If you made changes to third-party packages then you have to run:
> [user@localhost sage]$ make
>
> as if you were installing Sage from scratch. However, simply running make
> will only recompile packages that were changed, so it shoud be much faster
> than compiling Sage the first time. Rarely there are conflicts with other
> packages, or with the already-installed older version of the package that
> you changed, in that case you do have to recompile everything using:
> [user@localhost sage]$ make distclean && make
>
> Also, don't forget to run the tests (see Doctesting the Sage Library) and
> build the documentation (see The Sage Manuals).
>
>
> That is, the manual states that the recommended route is to use sage -br
> unless you are modifying packages. Does the manual need to be updated or do
> Jeroen's comments only apply when playing with external packages/code?
>
> Btw, as William mentioned in another post, sage's requirement to use sage
> -br, or make, when python files are changed shouldn't be necessary (cf. for
> example, this is done automatically when using setup tools). Are their plans
> to fix this?

Yes, definitely. We're I think just literally waiting for somebody
persistent to decide to do it. There's no real downside.
It was also dramatically reduce a massive source of confusion, where a
person does

  foo??

in some context (maybe sage or ipython), or maybe just uses "find" on
the command line, then tries to directly edit the file based on the
listed source code location.

There's also potentially a small savings of disk space.

>
> 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.



-- 
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] Maple versus Mathematica

[Stefan]

Problems arise when thinking about more complicated mathematical objects. I 
don't know if I simply lack the appropriate Mathematica knowledge, but 
years ago, when I implemented matroids in Mathematica, a matroid was simply 
a list with 6 elements (groundset, representation matrix, and I forget what 
else) and head Matroid. To access the elements of that list, you did stuff 
like this:

lM = Map[If[# == 0, 0, 1] &, M[[2]][[#[[2]] & /@ M[[3]], #[[2]] & /@ 
M[[4, {2}];

I don't miss that aspect of Mathematica one bit! Python objects are so much 
nicer, and we still get lambda functions when we need them.

Also, it might be experience, but I spent WAY more time debugging my 
Mathematica code than debugging my Python code.

-- 
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] Maple versus Mathematica

[William Stein]

On Tue, Nov 18, 2014 at 2:17 PM, Dan Drake  wrote:
> On Tue, 18 Nov 2014 at 01:34PM -0800, William Stein wrote:
>> When arguing for Maple's language over the Mathematica language, they
>> say "Functional programs are often opaque; most people, even
>> experienced programmers, find functional-style  programs to be
>> significantly harder to write, read, and debug."
>
> Perhaps I'm biased because I'm taking the edX functional programming
> MOOC right now, but isn't one of the arguments *for* functional
> programming style is that it is easier to debug, since you can reason
> about each of your functions separately, without tracking the state?

My personal experience with types of programming languages is that
functional/object oriented/etc. is terrible for one
class of problems and awesome for another. You're definitely doing
the right thing by learning several approaches well.  The sort of
statement that Maple document makes is really the worst possible
thing, namely to declare an entire style of programming inferior on
general principle.

I'm glad Python supports several different styles, though I do wish
Python had better functional support than it does (e.g., lambda
functions, scoping), since that would make it even more flexible...

I'm really glad that Sage has a fast C-level binding to lisp built in
by default, even if I don't use it so much.  (Thanks Nils.)

 - William


-- 
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] Maple versus Mathematica

[Dan Drake]

On Tue, 18 Nov 2014 at 01:34PM -0800, William Stein wrote:
> When arguing for Maple's language over the Mathematica language, they
> say "Functional programs are often opaque; most people, even
> experienced programmers, find functional-style  programs to be
> significantly harder to write, read, and debug."

Perhaps I'm biased because I'm taking the edX functional programming
MOOC right now, but isn't one of the arguments *for* functional
programming style is that it is easier to debug, since you can reason
about each of your functions separately, without tracking the state?


Dan

-- 
---  Dan Drake
-  www.math.wisc.edu/~ddrake/
---


signature.asc
Description: Digital signature

Re: [sage-devel] Re: About recmpilations caused by Git

[Andrew]

> > I've gone back to sage -b. 
> Please don't, or at the very least don't ever report a bug or failing 
> doctest without doing "make" first. 
>

I am confused by Jeroen's comment. According to the sage 6.4 developers 
guide 
:

Rebuilding Sage 

Once you have made any changes you of course want to build Sage and try out 
your edits. As long as you only modified the Sage library (that is, Python 
and Cython files under src/sage/...) you just have to run: 
[user@localhost sage]$ ./sage -br

to rebuild the Sage library and then start Sage. This should be quite fast. 
If you made changes to third-party packages then you have to run: 
[user@localhost sage]$ make

as if you were installing Sage from scratch 
. However, simply 
running make will only recompile packages that were changed, so it shoud be 
much faster than compiling Sage the first time. Rarely there are conflicts 
with other packages, or with the already-installed older version of the 
package that you changed, in that case you do have to recompile everything 
using: 
[user@localhost sage]$ make distclean && make

Also, don’t forget to run the tests (see Doctesting the Sage Library) and 
build the documentation (see The Sage Manuals).


That is, the manual states that the recommended route is to use sage -br 
unless you are modifying packages. Does the manual need to be updated or do 
Jeroen's comments only apply when playing with external packages/code?

Btw, as William mentioned in another post, sage's requirement to use sage 
-br, or make, when python files are changed shouldn't be necessary (cf. for 
example, this is done automatically when using setup tools). Are their 
plans to fix this?

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: Maple versus Mathematica

[Harald Schilly]

Writing such a comparison for all 4 packages sounds like a huge task, but 
it could really pay off.

Your episode does ring a bell, it reminds me of the MS-RSL license. This is 
maybe the same case and is only there to help you to make your code 
compatible with their product,that's all.
http://referencesource.microsoft.com/license.html

-- Harald

-- 
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: Code of Conduct

[Harald Schilly]

On Tue, Nov 18, 2014 at 10:29 PM, Dr. David Kirkby (Kirkby Microwave
Ltd)  wrote:
> but count me out.

As far as I can see, this idea is already abandoned anyway. Still, we
could do this list of  by self nomination and see if this leads to
anything. We could call this the "community management team" and
initially it consists of at least 5 self-nominated individuals, who
didn't face some strong objections. Of course, it is a problem to
communicate objections against someone in such a role directly. Maybe
there should be some kind of voting, where each of those 5 need at
least 5 who aren't nominated but "vouch" for them to get support in
the community.

Ok, I've finished my thought while writing, so I repeat:

1. new thread
2. call this "community management team"
3. self-nomination, at least 5 initially, who are somehow part of the
Sage community
4. each of them need at least 5 supporters, who aren't part of this
team, in order to receive support from the community.

What they do is then up to their responsibility, and they should start
with small steps (directing threads to sage-flame, receive complaints
"in private", etc...)

A "phase 2" could be to establish something similar for a "steering
committee" for the whole Sage project. No idea if there is any need
for this, but just an idea.

-- Harald

-- 
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] Bug in abs(I*x).diff(x)

[Bill Page]

On 18 November 2014 15:19, Ondřej Čertík  wrote:
> On Tue, Nov 18, 2014 at 12:14 PM, Bill Page  
> wrote:
>>
>>   abs(x).diff(x)
>>
>> would return the symbolic expression
>>
>>   conjugate(x)/(2*abs(x)) + conjugate(x)/(2*abs(x))* e^{-2*i*theta}
>
> I think you made a mistake, the correct expression is:
>
> conjugate(x)/(2*abs(x)) + x/(2*abs(x)) * e^{-2*i*theta}
>

Yes, sorry.

>> ...
>> I thought rather that what you were proposing was to set theta=0
>> from the start.  If you did that, then I think you still have problems
>> with the chain rule.
>
> For a CAS, I was leaning towards using theta=0. But given your
> objections, I first needed to figure out the most general case that
> covers everything. I think that's now sufficiently clarified.
>

OK.

>> Let me add that the kind of solution to this problem that I did
>> imagine was to implement two derivatives, for example both
>>
>>   f.diff(z) = df/dz + df/d conjugate(z)
>>
>> and
>>
>>   f.diff2(z) = df/dz - df/d conjugate(z)
>>
>> diff(z) would equal diff2(z) for all analytic functions and diff would
>> reduce to the derivative of real non-analytic functions as you desire.
>
> Right, diff() is for theta = 0. diff2() is for theta=pi/2, i.e. taking
> the derivative along the imaginary axis.
>
>> Note that for abs we have
>>
>>   abs(z).diff2(z) = 0
>
> Actually, for abs you have:
>
> abs(z).diff2(z) = (conjugate(z)-z)/(2*abs(z))
>

Yes again, sorry.  Of course 0 only if conjugate(z)=z.

>> but not in general.  There would be no need to discuss this 2nd
>> derivative with less experienced users until they were ready to
>> consider more "advanced" mathematics.
>>
>> Clearly we could implement the chain rule given these two derivatives.
> ...

On 18 November 2014 15:46, Ondřej Čertík  wrote:
> On Tue, Nov 18, 2014 at 1:19 PM, Ondřej Čertík  
> wrote:
> ..
>>
>> So I think that functions can return their own correct derivative, for
>> example analytic functions just return the unique complex derivative,
>> for example:
>>
>> log(z).diff(z) = 1/z
>>
>> This holds for all cases. Non-analytic functions like abs(f) can return:
>>
>> abs(f).diff(z) = (conjugate(f)*f.diff(z) +
>> f*conjugate(f).diff(z)*e^{-2*i*theta}) / (2*abs(f))
>
> Actually, I think I made a mistake. Let's do abs(f).diff(x) again for
> the most general case. We use:
>
> D f(g) / D z =
>
> = df/dg * (dg/dz + dg/d conjugate(z) * e^{-2*i*theta}) + df/d
> conjugate(g) * (d conjugate(g)/dz + d conjugate(g)/d conjugate(z) *
> e^{-2*i*theta}) =
>
> = df/dg Dg/Dz + df/d conjugate(g) D conjugate(g) / Dz
>
> Which we derived above. We have f(g) -> |g| and g(z) -> f(z). So we get:
>
> D |f| / Dz = d|f|/df * Df/Dz + d|f|/d conjugate(f) * D conjugate(f) / Dz =
>
> = (conjugate(f) * Df/Dz + f * D conjugate(f) / Dz) / (2*abs(f))
>
> And then:
>
> Df/Dz = f.diff(z)
> D conjugate(f) / Dz = conjugate(f).diff(z)
>
> So I think the formula:
>
> abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / 
> (2*abs(f))
>
> is the most general formula for any theta. The theta dependence is hidden
> in conjugate(f).diff(z), since if "f" is analytic, like f=log(z), the
> conjugate(f) is not analytic, and so the derivative is theta dependent.
>
> The below holds though:
>
>>
>> I think that's the correct application of the chain rule. We can set
>> theta=0, so we would just return:
>>
>> abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / 
>> (2*abs(f))
>>
>> Which for real "f" (i.e. conjugate(f)=f) simplifies to (as a special case):
>>
>> abs(f).diff(z) = (f*f.diff(z) + f*f.diff(z)) / (2*abs(f)) = f/abs(f) *
>> f.diff(z) = sign(f) * f.diff(z)
>>
>> So it all works.
>>
>> Unless there is some issue that I don't see, it seems to me we just
>> need to have one diff(z) function, no need for diff2().
>>

Hmmm... So given only f(z).diff(z) as you have defined it above, how
do I get Df(z)/D conjugate(z), i.e. the other Wirtinger derivative?
Or are you claiming that this is not necessary in general in spite of
the Wirtinger  formula for the chain rule?

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: inconsistent behavior with multivariate polynomial rings: what to do?

[John H Palmieri]

Sounds good to me. See http://trac.sagemath.org/ticket/17366.

  John


On Tuesday, November 18, 2014 10:42:15 AM UTC-8, Volker Braun wrote:
>
> Yes, DWIM and convert the argument to the ring if it is not already there.
>
>
>
> On Tuesday, November 18, 2014 6:24:12 PM UTC, John H Palmieri wrote:
>>
>> From #17205:
>>
>> sage: x, y = ZZ['x','y'].gens()
>> sage: GF(1091)['x','y'].random_element().degree(x) 
>> 2
>> sage: GF(3037000453)['x','y'].random_element().degree(x) 
>> ...
>> TypeError: x must be one of the generators of the parent.
>>
>> I don't think the behavior should be different the polynomial rings over 
>> GF(1091) and GF(3037000453), but I don't know what the right behavior 
>> should be. Should x (which is one of the generators of ZZ[x,y]) be 
>> automatically coerced to an element of GF(p)[x,y] when we call 
>> elt.degree(x)?
>>
>> -- 
>> John
>>
>>

-- 
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] Maple versus Mathematica

[William Stein]

See this interesting document:

   
http://www.maplesoft.com/products/maple/compare/HowMapleComparestoMathematica.pdf

It would be valuable to our users (and potential users) if we had a
similar document which explains and *argues* for why we believe our
approach to mathematical software is better than the ones taken by
Mathematica, Magma, Maple, and Matlab.

Some samples from their document: "About 95% of Maple's functionality
is written in the  Maple programming language, and every Maple user
can freely inspect the source code for any of these predefined Maple
library routines. [...] In Mathematica, the source code for all the
predefined library routines written in the Mathematica  programming
language is hidden from the user." (*)

When arguing for Maple's language over the Mathematica language, they
say "Functional programs are often opaque; most people,  even
experienced programmers, find functional-style  programs to be
significantly harder to write, read, and  debug."

(*) We had a specific situation a few years ago where an academic
wrote a package in maple, and a student at UW wanted to write a
similar open source package in Python.  We specifically asked
Maplesoft if the student could look at the source code of Maple, which
is "open" in the sense they list above, then be inspired by it in
writing his own Python code.   They came back and clearly said "no
way; absolutely not!"


-- 
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] Re: Code of Conduct

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 18 Nov 2014 18:36, "William Stein"  wrote:

> the top 12  all time list of contributors to Sage, in order, are:
>
>   - William Stein
>   - Mike Hansen
>   - Volker Braun
>   - Jereon Demeyer
>   - Nathann Cohen
>   - Robert Bradshaw
>   - Robert Miller
>   - Simon King
>   - John Palmieri
>   - Jason Grout
>   - Nicholas Thiery
>   - David Kirkby

> We could:
>
>   1. Create a private mailing list called sage-abuse with these people
> as members.

I don't know if I am the only one of the top 12 contributors who doesn't
want to be in the sage-abuse list, but count me out.

I don't feel qualified to do such a task. In fact,  I think I have been
accused of being abusive before. Without naming any names, I can think of
at least two others in that list which would be inappropriate people.

I think the who idea is quite flawed to be honest. Maybe the whole thread
should go to sage-flame, which I don't subscribe to.

David Kirkby.

-- 
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] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 18, 2014 at 1:19 PM, Ondřej Čertík  wrote:
> On Tue, Nov 18, 2014 at 12:14 PM, Bill Page  
> wrote:
>> On 18 November 2014 13:41, Ondřej Čertík  wrote:
>>> On Tue, Nov 18, 2014 at 11:08 AM, Bill Page  
>>> wrote:
 ...
 Have you had a chance to consider the issue of the chain-rule yet?
>>>
>>> Yes. Very straightforward, as I suggested in my last email. Just start with:
>>>
>>> D f / D z = df/dz + df/d conjugate(z) * e^{-2*i*theta}
>>>
>>> and then consider the chain rule for Wirtinger derivatives
>>> (http://en.wikipedia.org/wiki/Wirtinger_derivatives#Functions_of_one_complex_variable_2),
>>> I am sure that can be proven quite easily.
>>
>> Let me make sure I understand your proposal.  Are you saying that you
>> would introduce the symbolic expression
>>
>>e^{-2*i*theta}
>>
>> with theta undefined in the result of all derivatives?  So that
>> diff(x) is always the sum of two terms. In particular
>>
>>   abs(x).diff(x)
>>
>> would return the symbolic expression
>>
>>   conjugate(x)/(2*abs(x)) + conjugate(x)/(2*abs(x))* e^{-2*i*theta}
>
> I think you made a mistake, the correct expression is:
>
> conjugate(x)/(2*abs(x)) + x/(2*abs(x)) * e^{-2*i*theta}
>
>>
>> If you are, then clearly one can recover both Wirtinger derivatives
>> from this expression and the rest holds.
>
> For now I just wanted to get the math right in the most general case.
> I wasn't even considering what a CAS should do.
>
>>
>>> Then you just calculate directly:
>>> ...
>>> So it exactly agrees, except that there is a theta dependence in the
>>> final answer and GiNaC implicitly chose theta=0.
>>>...
>>> I hope I didn't make some mistake somewhere, but it looks all
>>> straightforward to me.
>>>
>>
>> It looks OK to me but I must say, it probably seems rather peculiar
>> from the point of view expressed earlier by David Roe.
>>
>> How can you explain the presence of the e^theta term to someone
>> without experience in complex analysis or at least multi-variable
>> calculus?
>>
>> I thought rather that what you were proposing was to set theta=0 from
>> the start.  If you did that, then I think you still have problems with
>> the chain rule.
>
> For a CAS, I was leaning towards using theta=0. But given your
> objections, I first needed to figure out the most general case that
> covers everything. I think that's now sufficiently clarified.
>
>> Let me add that the kind of solution to this problem that I did
>> imagine was to implement two derivatives, for example both
>>
>>   f.diff(z) = df/dz + df/d conjugate(z)
>>
>> and
>>
>>   f.diff2(z) = df/dz - df/d conjugate(z)
>>
>> diff(z) would equal diff2(z) for all analytic functions and diff would
>> reduce to the derivative of real non-analytic functions as you desire.
>
> Right, diff() is for theta = 0. diff2() is for theta=pi/2, i.e. taking
> the derivative along the imaginary axis.
>
>> Note that for abs we have
>>
>>   abs(z).diff2(z) = 0
>
> Actually, for abs you have:
>
> abs(z).diff2(z) = (conjugate(z)-z)/(2*abs(z))
>
>> but not in general.  There would be no need to discuss this 2nd
>> derivative with less experienced users until they were ready to
>> consider more "advanced" mathematics.
>>
>> Clearly we could implement the chain rule given these two derivatives.
>
> So I think that functions can return their own correct derivative, for
> example analytic functions just return the unique complex derivative,
> for example:
>
> log(z).diff(z) = 1/z
>
> This holds for all cases. Non-analytic functions like abs(f) can return:
>
> abs(f).diff(z) = (conjugate(f)*f.diff(z) +
> f*conjugate(f).diff(z)*e^{-2*i*theta}) / (2*abs(f))

Actually, I think I made a mistake. Let's do abs(f).diff(x) again for
the most general case. We use:

D f(g) / D z =

= df/dg * (dg/dz + dg/d conjugate(z) * e^{-2*i*theta}) + df/d
conjugate(g) * (d conjugate(g)/dz + d conjugate(g)/d conjugate(z) *
e^{-2*i*theta}) =

= df/dg Dg/Dz + df/d conjugate(g) D conjugate(g) / Dz

Which we derived above. We have f(g) -> |g| and g(z) -> f(z). So we get:

D |f| / Dz = d|f|/df * Df/Dz + d|f|/d conjugate(f) * D conjugate(f) / Dz =

= (conjugate(f) * Df/Dz + f * D conjugate(f) / Dz) / (2*abs(f))

And then:

Df/Dz = f.diff(z)
D conjugate(f) / Dz = conjugate(f).diff(z)

So I think the formula:

abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / (2*abs(f))

is the most general formula for any theta. The theta dependence is hidden
in conjugate(f).diff(z), since if "f" is analytic, like f=log(z), the
conjugate(f) is
not analytic, and so the derivative is theta dependent.

The below holds though:

>
> I think that's the correct application of the chain rule. We can set
> theta=0, so we would just return:
>
> abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / 
> (2*abs(f))
>
> Which for real "f" (i.e. conjugate(f)=f) simplifies to (as a special case):
>
> abs(f).diff(z) = (f*f.diff(z) + f*f.diff(z)) / (2*abs(f)) = f/abs(f) *
> f.diff(z) = sign(f) * f.diff(z)
>
> So it all works.
>

Re: [sage-devel] Octave interface broken

[François Bissey]

Note that if you want to fix in your current 6.3, creating folder is
not helpful (you already figured that out because of permission).
sed -i "s:script_subdirectory='user':script_subdirectory=None:" \
src/sage/interfaces/octave.py

will do the job.

Francois

On Tue, 18 Nov 2014 13:43:05 Jan Groenewald wrote:
> Hi
> 
> I have 6.3
> 
> I am glad to see this is fixed in 6.4.
> I do not see 6.4 binaries for Ubuntu 14.04, so I have not updated the PPA
> yet.
> ftp://ftp.sun.ac.za/pub/mirrors/www.sagemath.org/linux/64bit/index.html
> 
> Regards,
> Jan
> 
> On 18 November 2014 13:15, Francois Bissey  > wrote:
> > 
> > Which version of sage? It should have been fixed in 6.4. We initially
> > spotted this in sage-on-gentoo and someone finally opened an issue for it
> > that got merged in 6.4:
> > https://github.com/cschwan/sage-on-gentoo/issues/289
> > 
> > François
> > 
> > > On 18/11/2014, at 23:48, Jan Groenewald  wrote:
> > > 
> > > Hi
> > > 
> > > Original problem: a PPA sage has a sage installation with system-wide
> > 
> > files owned by root.
> > 
> > > Such a user running octave('1+1') get permission denied:
> > /usr/lib/sagemath/local/share/
> > 
> > > sage/ext/octave/user instead of running octave code (it does not clearly
> > 
> > say those don't exist, it just says permission denied).
> > 
> > > Regards,
> > > Jan
> > > 
> > > 
> > > On 18 November 2014 10:30, Jan Groenewald  wrote:
> > > 
> > > Hi
> > > 
> > > By default our PPA installation does not have the folders octave and
> > 
> > user in
> > 
> > > /usr/lib/sagemath/local/share/sage/ext/octave/user
> > > 
> > > And /usr/lib/sagemath/local/share/sage/ext/ is owned by root in a
> > 
> > system-wide install. I can add these two folders to the PPA, but would
> > rather have then added upstream with the correct permissions (755).
> > 
> > > If I run
> > > 
> > > sage: octave('1+1')
> > > 
> > > as root, the folders get created permission 700 and owned by root. Once
> > 
> > I made them 755, normal users can run octave in sage, and there does not
> > seem to be any files savedin those folders, they just need to exist. One
> > 
> > error remains though, when exiting sage:
> > > sage: octave('1+2')
> > > 
> > >  3
> > > 
> > > sage: r=octave('rand(1)')
> > > sage: r
> > > 
> > >  0.484611
> > > 
> > > sage:
> > > Exiting Sage (CPU time 0m0.30s, Wall time 2m43.88s).
> > > Exiting spawned Octave process.
> > > Octave crashed -- automatically restarting.
> > > Octave crashed -- automatically restarting.
> > > 0 jan@mangoky:~$logout
> > > Connection to mangoky closed.
> > > 0 jan@muizenberg:/var/autofs/misc/home/jan$
> > > 
> > > 
> > > (whether run as me or as root I still get this message that octave
> > 
> > crashed).
> > 
> > > Regards,
> > > Jan
> > > 
> > > 
> > > 
> > > 
> > > --
> > > 
> > >   .~.
> > >   /V\ Jan Groenewald
> > >  
> > >  /( )\www.aims.ac.za
> > >  ^^-^^
> > > 
> > > --
> > > 
> > >   .~.
> > >   /V\ Jan Groenewald
> > >  
> > >  /( )\www.aims.ac.za
> > >  ^^-^^
> > > 
> > > --
> > > 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.

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 18, 2014 at 12:14 PM, Bill Page  wrote:
> On 18 November 2014 13:41, Ondřej Čertík  wrote:
>> On Tue, Nov 18, 2014 at 11:08 AM, Bill Page  
>> wrote:
>>> ...
>>> Have you had a chance to consider the issue of the chain-rule yet?
>>
>> Yes. Very straightforward, as I suggested in my last email. Just start with:
>>
>> D f / D z = df/dz + df/d conjugate(z) * e^{-2*i*theta}
>>
>> and then consider the chain rule for Wirtinger derivatives
>> (http://en.wikipedia.org/wiki/Wirtinger_derivatives#Functions_of_one_complex_variable_2),
>> I am sure that can be proven quite easily.
>
> Let me make sure I understand your proposal.  Are you saying that you
> would introduce the symbolic expression
>
>e^{-2*i*theta}
>
> with theta undefined in the result of all derivatives?  So that
> diff(x) is always the sum of two terms. In particular
>
>   abs(x).diff(x)
>
> would return the symbolic expression
>
>   conjugate(x)/(2*abs(x)) + conjugate(x)/(2*abs(x))* e^{-2*i*theta}

I think you made a mistake, the correct expression is:

conjugate(x)/(2*abs(x)) + x/(2*abs(x)) * e^{-2*i*theta}

>
> If you are, then clearly one can recover both Wirtinger derivatives
> from this expression and the rest holds.

For now I just wanted to get the math right in the most general case.
I wasn't even considering what a CAS should do.

>
>> Then you just calculate directly:
>> ...
>> So it exactly agrees, except that there is a theta dependence in the
>> final answer and GiNaC implicitly chose theta=0.
>>...
>> I hope I didn't make some mistake somewhere, but it looks all
>> straightforward to me.
>>
>
> It looks OK to me but I must say, it probably seems rather peculiar
> from the point of view expressed earlier by David Roe.
>
> How can you explain the presence of the e^theta term to someone
> without experience in complex analysis or at least multi-variable
> calculus?
>
> I thought rather that what you were proposing was to set theta=0 from
> the start.  If you did that, then I think you still have problems with
> the chain rule.

For a CAS, I was leaning towards using theta=0. But given your
objections, I first needed to figure out the most general case that
covers everything. I think that's now sufficiently clarified.

> Let me add that the kind of solution to this problem that I did
> imagine was to implement two derivatives, for example both
>
>   f.diff(z) = df/dz + df/d conjugate(z)
>
> and
>
>   f.diff2(z) = df/dz - df/d conjugate(z)
>
> diff(z) would equal diff2(z) for all analytic functions and diff would
> reduce to the derivative of real non-analytic functions as you desire.

Right, diff() is for theta = 0. diff2() is for theta=pi/2, i.e. taking
the derivative along the imaginary axis.

> Note that for abs we have
>
>   abs(z).diff2(z) = 0

Actually, for abs you have:

abs(z).diff2(z) = (conjugate(z)-z)/(2*abs(z))

> but not in general.  There would be no need to discuss this 2nd
> derivative with less experienced users until they were ready to
> consider more "advanced" mathematics.
>
> Clearly we could implement the chain rule given these two derivatives.

So I think that functions can return their own correct derivative, for
example analytic functions just return the unique complex derivative,
for example:

log(z).diff(z) = 1/z

This holds for all cases. Non-analytic functions like abs(f) can return:

abs(f).diff(z) = (conjugate(f)*f.diff(z) +
f*conjugate(f).diff(z)*e^{-2*i*theta}) / (2*abs(f))

I think that's the correct application of the chain rule. We can set
theta=0, so we would just return:

abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / (2*abs(f))

Which for real "f" (i.e. conjugate(f)=f) simplifies to (as a special case):

abs(f).diff(z) = (f*f.diff(z) + f*f.diff(z)) / (2*abs(f)) = f/abs(f) *
f.diff(z) = sign(f) * f.diff(z)

So it all works.

Unless there is some issue that I don't see, it seems to me we just
need to have one diff(z) function, no need for diff2().

Ondrej

-- 
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: Code of Conduct

[Harald Schilly]

On Tue, Nov 18, 2014 at 8:36 PM, Harald Schilly
 wrote:
> This is the result for the last year


looking at the result again, I think it sorts by number of commits,
not lines. one could tweak the number of top authors (default is 20)
to get all of them in … so don't take this output seriously.

-- harald

-- 
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] Bug in abs(I*x).diff(x)

[Bill Page]

On 18 November 2014 14:14, Bill Page  wrote:
> On 18 November 2014 13:41, Ondřej Čertík  wrote:
>> On Tue, Nov 18, 2014 at 11:08 AM, Bill Page  
>> wrote:
>>> ...
>>> Have you had a chance to consider the issue of the chain-rule yet?
>>
>> Yes. Very straightforward, as I suggested in my last email. Just start with:
>>
>> D f / D z = df/dz + df/d conjugate(z) * e^{-2*i*theta}
>>
>> and then consider the chain rule for Wirtinger derivatives
>> (http://en.wikipedia.org/wiki/Wirtinger_derivatives#Functions_of_one_complex_variable_2),
>> I am sure that can be proven quite easily.
> ...
> I thought rather that what you were proposing was to set theta=0 from
> the start.  If you did that, then I think you still have problems with
> the chain rule.
>

Let me add that the kind of solution to this problem that I did
imagine was to implement two derivatives, for example both

  f.diff(z) = df/dz + df/d conjugate(z)

and

  f.diff2(z) = df/dz - df/d conjugate(z)

diff(z) would equal diff2(z) for all analytic functions and diff would
reduce to the derivative of real non-analytic functions as you desire.
Note that for abs we have

  abs(z).diff2(z) = 0

but not in general.  There would be no need to discuss this 2nd
derivative with less experienced users until they were ready to
consider more "advanced" mathematics.

Clearly we could implement the chain rule given these two derivatives.

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: Code of Conduct

[William Stein]

On Tue, Nov 18, 2014 at 11:33 AM, Anne Schilling  wrote:

> Not everybody who contributes through trac seems to have an account on github.
> So there are lots of contributors missing!

It would be fun to have somebody produce a proper list directly from
the git commit history.
However, I think Volker raised some valid objections to this proposal,
so for the purposes of
this thread, my concrete proposal probably shouldn't move forward.

 - William


-- 
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] Re: Code of Conduct

[Harald Schilly]

On Tuesday, November 18, 2014 7:37:21 PM UTC+1, William wrote:

> Here is I think a concrete, apolitical proposal. 
>
>
Calculating stakeholders by core contribution is certainly possible. My 
only contribution would be, that this sage-abuse mailing list is read-only 
for all others, not hidden and private.
I have played around with a tool called "gitstats", installed via "sudo 
apt-get install gitstats".
It generates statistics, and you can also specify some parameters.

This is the result for the last year, obtained via
$ gitstats -c commit_begin=1c1ee9f0 . stats

http://boxen.math.washington.edu/home/schilly/gitstats/1year/authors.html

and this for the full sage git repo
$ gitstats . stats

http://boxen.math.washington.edu/home/schilly/gitstats/full/authors.html

This could be part of the website, btw... ?!

-- Harald

-- 
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: Code of Conduct

[Anne Schilling]

On 11/18/14 11:07 AM, William Stein wrote:
> On Tue, Nov 18, 2014 at 11:05 AM, Anne Schilling  
> wrote:
>> On 11/18/14 10:36 AM, William Stein wrote:
>>> On Tue, Nov 18, 2014 at 10:01 AM, Anne Schilling  
>>> wrote:
 On 11/18/14 7:55 AM, Harald Schilly wrote:
>
> On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote:
>
> What if instead of a "code of conduct" there was a "community 
> expectations" SHORT document that just say what we expect?
>
>
> I'm a little bit late to this thread, but I've read all the mails. This 
> "expectations" document sounds interesting to me, whereas I'm a bit 
> hesitant to this "code of conduct" thing. In my eyes, it is
> stating a lot of obvious things, and doesn't solve immediate problems. I 
> agree that it could be abused in some way, just because it exists and 
> hence it is a leverage point. e.g. phrases like "poor
> behavior" are a bit hollow for me. (*)

 Saying that discussions that get out of hand can be relegated to 
 sage-flame is, I think, important.
 For example, I did not know that we could do that until very recently. 
 Stating explicitly how this can
 be done might be good.

> We should not forget, that most of us here (as mathematicians & 
> researchers in general) are trained to be (a) very picky and (b) 
> long-term persistent. Those ingredients do not help if a discussion
> derails into lengthy substitution-arguments to just make a point in a 
> time-consuming thread. What would actually help in such situations is to 
> step back and look at the bigger picture. Maybe there
> should be an intervention team of "senior" community people to sort this 
> out: e.g. just posting "DRAMA MODE" as a signal for everyone to stop it? 
> But who are those and how do they gain authority?

 One problem with this is that the intervention team might not be reading 
 all threads.
 So having a way to say where there is a problem might still be useful.
 I agree deciding who the intervention team is is an important question. 
 Probably William
 would be a good choice.
>>>
>>> Here is I think a concrete, apolitical proposal.
>>>
>>> Given the potentially political nature of such a choice, one
>>> possibility is to do something apolitical, and select based on
>>> ownership. In particular, based on lines of code contributed to Sage,
>>> which is an (imperfect!) but non-politicial measure of how much
>>> ownership people have in Sage (with legal value, since people do not
>>> contribute their copyright).By this definition:
>>>
>>>
>>> https://github.com/sagemath/sage/graphs/contributors?from=2006-02-05&to=2014-11-18&type=a
>>>
>>> the top 12  all time list of contributors to Sage, in order, are:
>>>
>>>   - William Stein
>>>   - Mike Hansen
>>>   - Volker Braun
>>>   - Jereon Demeyer
>>>   - Nathann Cohen
>>>   - Robert Bradshaw
>>>   - Robert Miller
>>>   - Simon King
>>>   - John Palmieri
>>>   - Jason Grout
>>>   - Nicholas Thiery
>>>   - David Kirkby
>>>
>>>
>>> We could:
>>>
>>>   1. Create a private mailing list called sage-abuse with these people
>>> as members.
>>>
>>>   2. Make a clear statement on the sagemath.org website, etc., that if
>>> people think a thread should be on sage-flame, send a message to the
>>> sage-abuse list.
>>>
>>>   3. The sage-abuse list members will have a quick discussion and if
>>> what to do isn't clear, they will vote (which means a quick on-list
>>> vote that must be completed within one day).If a majority votes to
>>> move the discussion should move to sage-flame, they ensure it moves.
>>>
>>> For now, the sage-abuse group would have exactly one duty, which is to
>>> ensure that discussions get moved to sage-flame when requested.
>>> That's it.   We would give this a try for 6 months, and only then
>>> revisit whether the group should expand its duties or be dissolved.
>>
>> This looks in principle like a good idea. However, how did you obtain this
>> data? Is this code contributed to Sage? On the link that you post above, 
>> there are
>> definitely contributors missing that have contributed lots of code. So how
>> precisely is this data obtained?
> 
> I just mindlessly clicked a few times on links on github.  I believe
> they are computing the total number of lines of code contributed to
> the Sage git repo.   So this is mostly code included in the core Sage
> library, via the trac review process.

Not everybody who contributes through trac seems to have an account on github.
So there are lots of contributors missing!

Best,

Anne

-- 
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/grou

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Bill Page]

On 18 November 2014 13:41, Ondřej Čertík  wrote:
> On Tue, Nov 18, 2014 at 11:08 AM, Bill Page  
> wrote:
>> ...
>> Have you had a chance to consider the issue of the chain-rule yet?
>
> Yes. Very straightforward, as I suggested in my last email. Just start with:
>
> D f / D z = df/dz + df/d conjugate(z) * e^{-2*i*theta}
>
> and then consider the chain rule for Wirtinger derivatives
> (http://en.wikipedia.org/wiki/Wirtinger_derivatives#Functions_of_one_complex_variable_2),
> I am sure that can be proven quite easily.

Let me make sure I understand your proposal.  Are you saying that you
would introduce the symbolic expression

   e^{-2*i*theta}

with theta undefined in the result of all derivatives?  So that
diff(x) is always the sum of two terms. In particular

  abs(x).diff(x)

would return the symbolic expression

  conjugate(x)/(2*abs(x)) + conjugate(x)/(2*abs(x))* e^{-2*i*theta}

If you are, then clearly one can recover both Wirtinger derivatives
from this expression and the rest holds.

> Then you just calculate directly:
> ...
> So it exactly agrees, except that there is a theta dependence in the
> final answer and GiNaC implicitly chose theta=0.
>...
> I hope I didn't make some mistake somewhere, but it looks all
> straightforward to me.
>

It looks OK to me but I must say, it probably seems rather peculiar
from the point of view expressed earlier by David Roe.

How can you explain the presence of the e^theta term to someone
without experience in complex analysis or at least multi-variable
calculus?

I thought rather that what you were proposing was to set theta=0 from
the start.  If you did that, then I think you still have problems with
the chain rule.

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: Code of Conduct

[William Stein]

On Tue, Nov 18, 2014 at 11:05 AM, Anne Schilling  wrote:
> On 11/18/14 10:36 AM, William Stein wrote:
>> On Tue, Nov 18, 2014 at 10:01 AM, Anne Schilling  
>> wrote:
>>> On 11/18/14 7:55 AM, Harald Schilly wrote:

 On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote:

 What if instead of a "code of conduct" there was a "community 
 expectations" SHORT document that just say what we expect?


 I'm a little bit late to this thread, but I've read all the mails. This 
 "expectations" document sounds interesting to me, whereas I'm a bit 
 hesitant to this "code of conduct" thing. In my eyes, it is
 stating a lot of obvious things, and doesn't solve immediate problems. I 
 agree that it could be abused in some way, just because it exists and 
 hence it is a leverage point. e.g. phrases like "poor
 behavior" are a bit hollow for me. (*)
>>>
>>> Saying that discussions that get out of hand can be relegated to sage-flame 
>>> is, I think, important.
>>> For example, I did not know that we could do that until very recently. 
>>> Stating explicitly how this can
>>> be done might be good.
>>>
 We should not forget, that most of us here (as mathematicians & 
 researchers in general) are trained to be (a) very picky and (b) long-term 
 persistent. Those ingredients do not help if a discussion
 derails into lengthy substitution-arguments to just make a point in a 
 time-consuming thread. What would actually help in such situations is to 
 step back and look at the bigger picture. Maybe there
 should be an intervention team of "senior" community people to sort this 
 out: e.g. just posting "DRAMA MODE" as a signal for everyone to stop it? 
 But who are those and how do they gain authority?
>>>
>>> One problem with this is that the intervention team might not be reading 
>>> all threads.
>>> So having a way to say where there is a problem might still be useful.
>>> I agree deciding who the intervention team is is an important question. 
>>> Probably William
>>> would be a good choice.
>>
>> Here is I think a concrete, apolitical proposal.
>>
>> Given the potentially political nature of such a choice, one
>> possibility is to do something apolitical, and select based on
>> ownership. In particular, based on lines of code contributed to Sage,
>> which is an (imperfect!) but non-politicial measure of how much
>> ownership people have in Sage (with legal value, since people do not
>> contribute their copyright).By this definition:
>>
>>
>> https://github.com/sagemath/sage/graphs/contributors?from=2006-02-05&to=2014-11-18&type=a
>>
>> the top 12  all time list of contributors to Sage, in order, are:
>>
>>   - William Stein
>>   - Mike Hansen
>>   - Volker Braun
>>   - Jereon Demeyer
>>   - Nathann Cohen
>>   - Robert Bradshaw
>>   - Robert Miller
>>   - Simon King
>>   - John Palmieri
>>   - Jason Grout
>>   - Nicholas Thiery
>>   - David Kirkby
>>
>>
>> We could:
>>
>>   1. Create a private mailing list called sage-abuse with these people
>> as members.
>>
>>   2. Make a clear statement on the sagemath.org website, etc., that if
>> people think a thread should be on sage-flame, send a message to the
>> sage-abuse list.
>>
>>   3. The sage-abuse list members will have a quick discussion and if
>> what to do isn't clear, they will vote (which means a quick on-list
>> vote that must be completed within one day).If a majority votes to
>> move the discussion should move to sage-flame, they ensure it moves.
>>
>> For now, the sage-abuse group would have exactly one duty, which is to
>> ensure that discussions get moved to sage-flame when requested.
>> That's it.   We would give this a try for 6 months, and only then
>> revisit whether the group should expand its duties or be dissolved.
>
> This looks in principle like a good idea. However, how did you obtain this
> data? Is this code contributed to Sage? On the link that you post above, 
> there are
> definitely contributors missing that have contributed lots of code. So how
> precisely is this data obtained?

I just mindlessly clicked a few times on links on github.  I believe
they are computing the total number of lines of code contributed to
the Sage git repo.   So this is mostly code included in the core Sage
library, via the trac review process.

William

>
> Best,
>
> Anne
>
> --
> 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 

Re: [sage-devel] Re: Code of Conduct

[William Stein]

On Tue, Nov 18, 2014 at 10:55 AM, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
> 2014-11-18 11:36 UTC-07:00, William Stein :
>> On Tue, Nov 18, 2014 at 10:01 AM, Anne Schilling 
>> wrote:
>>> On 11/18/14 7:55 AM, Harald Schilly wrote:

 On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote:

 What if instead of a "code of conduct" there was a "community
 expectations" SHORT document that just say what we expect?


 I'm a little bit late to this thread, but I've read all the mails. This
 "expectations" document sounds interesting to me, whereas I'm a bit
 hesitant to this "code of conduct" thing. In my eyes, it is
 stating a lot of obvious things, and doesn't solve immediate problems. I
 agree that it could be abused in some way, just because it exists and
 hence it is a leverage point. e.g. phrases like "poor
 behavior" are a bit hollow for me. (*)
>>>
>>> Saying that discussions that get out of hand can be relegated to
>>> sage-flame is, I think, important.
>>> For example, I did not know that we could do that until very recently.
>>> Stating explicitly how this can
>>> be done might be good.
>>>
 We should not forget, that most of us here (as mathematicians &
 researchers in general) are trained to be (a) very picky and (b)
 long-term persistent. Those ingredients do not help if a discussion
 derails into lengthy substitution-arguments to just make a point in a
 time-consuming thread. What would actually help in such situations is to
 step back and look at the bigger picture. Maybe there
 should be an intervention team of "senior" community people to sort this
 out: e.g. just posting "DRAMA MODE" as a signal for everyone to stop it?
 But who are those and how do they gain authority?
>>>
>>> One problem with this is that the intervention team might not be reading
>>> all threads.
>>> So having a way to say where there is a problem might still be useful.
>>> I agree deciding who the intervention team is is an important question.
>>> Probably William
>>> would be a good choice.
>>
>> Here is I think a concrete, apolitical proposal.
>>
>> Given the potentially political nature of such a choice, one
>> possibility is to do something apolitical, and select based on
>> ownership. In particular, based on lines of code contributed to Sage,
>> which is an (imperfect!) but non-politicial measure of how much
>> ownership people have in Sage (with legal value, since people do not
>> contribute their copyright).By this definition:
>>
>>
>> https://github.com/sagemath/sage/graphs/contributors?from=2006-02-05&to=2014-11-18&type=a
>>
>> the top 12  all time list of contributors to Sage, in order, are:
>>
>>   - William Stein
>>  [SNIP]
>>
>> We could:
>>
>>   1. Create a private mailing list called sage-abuse with these people
>> as members.
>>
>>   2. Make a clear statement on the sagemath.org website, etc., that if
>> people think a thread should be on sage-flame, send a message to the
>> sage-abuse list.
>>
>>   3. The sage-abuse list members will have a quick discussion and if
>> what to do isn't clear, they will vote (which means a quick on-list
>> vote that must be completed within one day).If a majority votes to
>> move the discussion should move to sage-flame, they ensure it moves.
>>
>> For now, the sage-abuse group would have exactly one duty, which is to
>> ensure that discussions get moved to sage-flame when requested.
>> That's it.   We would give this a try for 6 months, and only then
>> revisit whether the group should expand its duties or be dissolved.
>
> Having a committee in charge of the repression looks more than
> suspicious to me. Why would you exclude people from those important
> decision ? Why do not make the discussion public ?
>  Isn't sage-devel
> good enough for that ?

Maybe sage-devel would be good enough.   We could use our existing
process, which is that you start a new thread with a title like

VOTE: to move thread  to sage-flame

[ ] Yes
[ ] No

Anybody on sage-devel can vote (or argue) for 24 hours, we count the
votes, and if there is a simple majority for moving the thread to
sage-flame, it moves.  That's it.

> Moreover, it would be nice to point precisely
> the thread/tickets where problems occurred.
> On the other hand, for what William called a "non-political choice" of
> the committee, if you look at the period 2012-2014 which reflects more
> who is *involved* in Sage, the top list is not at all the same. I hope
> that you agree that Sage "belongs" to who use it and not to who create
> it.


Legally the copyright of Sage belongs to those who created Sage, since
we've never done copyright assignments to a foundation (or something
similar).   The GPLv3 copyright grants a specific list of rights to
those who use and redistribute Sage.


-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

-- 
You received this message because you 

Re: [sage-devel] Re: Code of Conduct

[Anne Schilling]

On 11/18/14 10:36 AM, William Stein wrote:
> On Tue, Nov 18, 2014 at 10:01 AM, Anne Schilling  
> wrote:
>> On 11/18/14 7:55 AM, Harald Schilly wrote:
>>>
>>> On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote:
>>>
>>> What if instead of a "code of conduct" there was a "community 
>>> expectations" SHORT document that just say what we expect?
>>>
>>>
>>> I'm a little bit late to this thread, but I've read all the mails. This 
>>> "expectations" document sounds interesting to me, whereas I'm a bit 
>>> hesitant to this "code of conduct" thing. In my eyes, it is
>>> stating a lot of obvious things, and doesn't solve immediate problems. I 
>>> agree that it could be abused in some way, just because it exists and hence 
>>> it is a leverage point. e.g. phrases like "poor
>>> behavior" are a bit hollow for me. (*)
>>
>> Saying that discussions that get out of hand can be relegated to sage-flame 
>> is, I think, important.
>> For example, I did not know that we could do that until very recently. 
>> Stating explicitly how this can
>> be done might be good.
>>
>>> We should not forget, that most of us here (as mathematicians & researchers 
>>> in general) are trained to be (a) very picky and (b) long-term persistent. 
>>> Those ingredients do not help if a discussion
>>> derails into lengthy substitution-arguments to just make a point in a 
>>> time-consuming thread. What would actually help in such situations is to 
>>> step back and look at the bigger picture. Maybe there
>>> should be an intervention team of "senior" community people to sort this 
>>> out: e.g. just posting "DRAMA MODE" as a signal for everyone to stop it? 
>>> But who are those and how do they gain authority?
>>
>> One problem with this is that the intervention team might not be reading all 
>> threads.
>> So having a way to say where there is a problem might still be useful.
>> I agree deciding who the intervention team is is an important question. 
>> Probably William
>> would be a good choice.
> 
> Here is I think a concrete, apolitical proposal.
> 
> Given the potentially political nature of such a choice, one
> possibility is to do something apolitical, and select based on
> ownership. In particular, based on lines of code contributed to Sage,
> which is an (imperfect!) but non-politicial measure of how much
> ownership people have in Sage (with legal value, since people do not
> contribute their copyright).By this definition:
> 
>
> https://github.com/sagemath/sage/graphs/contributors?from=2006-02-05&to=2014-11-18&type=a
> 
> the top 12  all time list of contributors to Sage, in order, are:
> 
>   - William Stein
>   - Mike Hansen
>   - Volker Braun
>   - Jereon Demeyer
>   - Nathann Cohen
>   - Robert Bradshaw
>   - Robert Miller
>   - Simon King
>   - John Palmieri
>   - Jason Grout
>   - Nicholas Thiery
>   - David Kirkby
> 
> 
> We could:
> 
>   1. Create a private mailing list called sage-abuse with these people
> as members.
> 
>   2. Make a clear statement on the sagemath.org website, etc., that if
> people think a thread should be on sage-flame, send a message to the
> sage-abuse list.
> 
>   3. The sage-abuse list members will have a quick discussion and if
> what to do isn't clear, they will vote (which means a quick on-list
> vote that must be completed within one day).If a majority votes to
> move the discussion should move to sage-flame, they ensure it moves.
> 
> For now, the sage-abuse group would have exactly one duty, which is to
> ensure that discussions get moved to sage-flame when requested.
> That's it.   We would give this a try for 6 months, and only then
> revisit whether the group should expand its duties or be dissolved.

This looks in principle like a good idea. However, how did you obtain this
data? Is this code contributed to Sage? On the link that you post above, there 
are
definitely contributors missing that have contributed lots of code. So how
precisely is this data obtained?

Best,

Anne

-- 
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: Code of Conduct

[Vincent Delecroix]

2014-11-18 11:36 UTC−07:00, William Stein :
> On Tue, Nov 18, 2014 at 10:01 AM, Anne Schilling 
> wrote:
>> On 11/18/14 7:55 AM, Harald Schilly wrote:
>>>
>>> On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote:
>>>
>>> What if instead of a "code of conduct" there was a "community
>>> expectations" SHORT document that just say what we expect?
>>>
>>>
>>> I'm a little bit late to this thread, but I've read all the mails. This
>>> "expectations" document sounds interesting to me, whereas I'm a bit
>>> hesitant to this "code of conduct" thing. In my eyes, it is
>>> stating a lot of obvious things, and doesn't solve immediate problems. I
>>> agree that it could be abused in some way, just because it exists and
>>> hence it is a leverage point. e.g. phrases like "poor
>>> behavior" are a bit hollow for me. (*)
>>
>> Saying that discussions that get out of hand can be relegated to
>> sage-flame is, I think, important.
>> For example, I did not know that we could do that until very recently.
>> Stating explicitly how this can
>> be done might be good.
>>
>>> We should not forget, that most of us here (as mathematicians &
>>> researchers in general) are trained to be (a) very picky and (b)
>>> long-term persistent. Those ingredients do not help if a discussion
>>> derails into lengthy substitution-arguments to just make a point in a
>>> time-consuming thread. What would actually help in such situations is to
>>> step back and look at the bigger picture. Maybe there
>>> should be an intervention team of "senior" community people to sort this
>>> out: e.g. just posting "DRAMA MODE" as a signal for everyone to stop it?
>>> But who are those and how do they gain authority?
>>
>> One problem with this is that the intervention team might not be reading
>> all threads.
>> So having a way to say where there is a problem might still be useful.
>> I agree deciding who the intervention team is is an important question.
>> Probably William
>> would be a good choice.
>
> Here is I think a concrete, apolitical proposal.
>
> Given the potentially political nature of such a choice, one
> possibility is to do something apolitical, and select based on
> ownership. In particular, based on lines of code contributed to Sage,
> which is an (imperfect!) but non-politicial measure of how much
> ownership people have in Sage (with legal value, since people do not
> contribute their copyright).By this definition:
>
>
> https://github.com/sagemath/sage/graphs/contributors?from=2006-02-05&to=2014-11-18&type=a
>
> the top 12  all time list of contributors to Sage, in order, are:
>
>   - William Stein
>  [SNIP]
>
> We could:
>
>   1. Create a private mailing list called sage-abuse with these people
> as members.
>
>   2. Make a clear statement on the sagemath.org website, etc., that if
> people think a thread should be on sage-flame, send a message to the
> sage-abuse list.
>
>   3. The sage-abuse list members will have a quick discussion and if
> what to do isn't clear, they will vote (which means a quick on-list
> vote that must be completed within one day).If a majority votes to
> move the discussion should move to sage-flame, they ensure it moves.
>
> For now, the sage-abuse group would have exactly one duty, which is to
> ensure that discussions get moved to sage-flame when requested.
> That's it.   We would give this a try for 6 months, and only then
> revisit whether the group should expand its duties or be dissolved.

Having a committee in charge of the repression looks more than
suspicious to me. Why would you exclude people from those important
decision ? Why do not make the discussion public ? Isn't sage-devel
good enough for that ? Moreover, it would be nice to point precisely
the thread/tickets where problems occurred.

On the other hand, for what William called a "non-political choice" of
the committee, if you look at the period 2012-2014 which reflects more
who is *involved* in Sage, the top list is not at all the same. I hope
that you agree that Sage "belongs" to who use it and not to who create
it.

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: inconsistent behavior with multivariate polynomial rings: what to do?

[Volker Braun]

Yes, DWIM and convert the argument to the ring if it is not already there.



On Tuesday, November 18, 2014 6:24:12 PM UTC, John H Palmieri wrote:
>
> From #17205:
>
> sage: x, y = ZZ['x','y'].gens()
> sage: GF(1091)['x','y'].random_element().degree(x) 
> 2
> sage: GF(3037000453)['x','y'].random_element().degree(x) 
> ...
> TypeError: x must be one of the generators of the parent.
>
> I don't think the behavior should be different the polynomial rings over 
> GF(1091) and GF(3037000453), but I don't know what the right behavior 
> should be. Should x (which is one of the generators of ZZ[x,y]) be 
> automatically coerced to an element of GF(p)[x,y] when we call 
> elt.degree(x)?
>
> -- 
> John
>
>

-- 
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] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 18, 2014 at 11:08 AM, Bill Page  wrote:
> On 18 November 2014 12:29, Ondřej Čertík  wrote:
>> On Tue, Nov 18, 2014 at 9:28 AM, David Roe  wrote:
>>> ...
>>> Because derivative is not just used in the context of functions of a
>>> complex variable (whether they are analytic or not).  Probably more
>>> than 90% of Sage users don't know any complex analysis (as frequently
>>> lamented by rtf).  I will certainly acknowledge that people get things
>>> wrong with regard to sqrt and log by not knowing about branch cuts.
>>> But when it comes to the definition of derivative, we need to stay
>>> consistent with the standard definition of lim_{h -> 0} (f(x + h) -
>>> f(x))/h for functions of a real variable (or functions that many
>>> people interpret as just functions of a real variable).  Any other
>>> decision will cause frustration for the vast majority of our users.
>>
>> Well, I think it doesn't matter if you know complex analysis or not.
>
> I agree, but apparently for a different reason.
>
>> The point is rather that there is a real derivative and a complex
>> derivative. The complex derivative being a generalization of the
>> real one (http://en.wikipedia.org/wiki/Derivative#Generalizations,
>> http://en.wikipedia.org/wiki/Generalizations_of_the_derivative#Complex_analysis).
>> As such, it must reduce to the real derivative as a special case when
>> all variables are real, otherwise you get inconsistencies.
>>
>
> As I said in another email, I think this is highly dependent on one's
> education and experience. Although I admit that it is very common
> (almost ubiquitous) to teach calculus starting from the notion of
> continuity and limits, I my opinion these references on wikipedia are
> especially biased.   To me from the point of view of computer algebra,
> the algebraic properties of derivatives are more important.
>
> For the sake of continuing the argument, from the point of view of
> algebra why should we consider derivatives of complex functions as a
> generalization of the real one rather than the real derivative as a
> defined in terms of something more general?  In particular notice that
> the so called Wirtinger derivatives also make sense in the case of
> quaternion analysis, so should we be expecting to view quaternion
> calculus also as a "generalization' of real derivatives?

I don't know that much about quaternions. Real numbers and real
analysis is essentially a subset of complex analysis. Is that true
that complex analysis is a subset of quaternion analysis? But I think
it's true that quaternion analysis is a generalization of a real
analysis, so I would definitely expect the quaternion derivatives to
match the real ones.

>
> OK, maybe I am pushing this a little too far.  I admit that the
> argument from the point of view of limits and without any reference to
> conjugate is quite convincing.
>
>> ...
>> Bill, you wrote "I think rather that one should strive for the most
>> general solution
>> consistent with the mathematics.". Well, the above (i.e.
>> x.conjugate()/(2*abs(x)) + x/(2*abs(x)) * exp(-2*I*theta)) is the
>> most general solution consistent with mathematics.
>>
>> Of these options, only theta=0 gives the real derivative as a special
>> case, that's what the GiNaC proposal does.
>>
>
> Have you had a chance to consider the issue of the chain-rule yet?

Yes. Very straightforward, as I suggested in my last email. Just start with:

D f / D z = df/dz + df/d conjugate(z) * e^{-2*i*theta}

and then consider the chain rule for Wirtinger derivatives
(http://en.wikipedia.org/wiki/Wirtinger_derivatives#Functions_of_one_complex_variable_2),
I am sure that can be proven quite easily. Then you just calculate
directly:

D f(g) / D z = df(g)/dz + df(g)/d conjugate(z) * e^{-2*i*theta} =

= (df/dg * dg/dz + df/d conjugate(g) * d conjugate(g) / dz) + (df/dg *
dg/d conjugate(z) + df/d conjugate(g) * d conjugate(g) / d
conjugate(z)) * e^{-2*i*theta} =

= df/dg * (dg/dz + dg/d conjugate(z) * e^{-2*i*theta}) + df/d
conjugate(g) * (d conjugate(g)/dz + d conjugate(g)/d conjugate(z) *
e^{-2*i*theta}) =

= df/dg Dg/Dz + df/d conjugate(g) D conjugate(g) / Dz

So at the end, the theta dependence got absorbed into Dg/Dz and D
conjugate(g) / Dz, but it assumes that these directional derivatives
are taken with the same angle theta.

You can now use it to do the example from GiNaC:

  cout << abs(log(z)).diff(z) << endl;
  // (before) -> D[0](abs)(log(z))*z^(-1)
  // (now) -> 
1/2*(z^(-1)*conjugate(log(z))+log(z)*conjugate(z)^(-1))*abs(log(z))^(-1)

I.e. f(g) = |g|, g(z) = log(z) and you get:

D |log(z)| / D z = conjugate(g)/(2*|g|) * D log(z) / Dz + g / (2*|g|)
* D conjugate(log(z)) / Dz =

= conjugate(log(z)) / (2*|log(z)|) * 1/z + log(z) / (2*|log(z)|) *
1/conjugate(z) * e^{-2*i*theta})

= 1/(2*|log(z)|) * (conjugate(log(z)) / z + log(z) / conjugate(z) *
e^{-2*i*theta})

So it exactly agrees, except that there is a theta dependence in the
final answer and GiNaC implicitly chose theta=0. Everyt

Re: [sage-devel] Re: Code of Conduct

[William Stein]

On Tue, Nov 18, 2014 at 10:01 AM, Anne Schilling  wrote:
> On 11/18/14 7:55 AM, Harald Schilly wrote:
>>
>> On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote:
>>
>> What if instead of a "code of conduct" there was a "community 
>> expectations" SHORT document that just say what we expect?
>>
>>
>> I'm a little bit late to this thread, but I've read all the mails. This 
>> "expectations" document sounds interesting to me, whereas I'm a bit hesitant 
>> to this "code of conduct" thing. In my eyes, it is
>> stating a lot of obvious things, and doesn't solve immediate problems. I 
>> agree that it could be abused in some way, just because it exists and hence 
>> it is a leverage point. e.g. phrases like "poor
>> behavior" are a bit hollow for me. (*)
>
> Saying that discussions that get out of hand can be relegated to sage-flame 
> is, I think, important.
> For example, I did not know that we could do that until very recently. 
> Stating explicitly how this can
> be done might be good.
>
>> We should not forget, that most of us here (as mathematicians & researchers 
>> in general) are trained to be (a) very picky and (b) long-term persistent. 
>> Those ingredients do not help if a discussion
>> derails into lengthy substitution-arguments to just make a point in a 
>> time-consuming thread. What would actually help in such situations is to 
>> step back and look at the bigger picture. Maybe there
>> should be an intervention team of "senior" community people to sort this 
>> out: e.g. just posting "DRAMA MODE" as a signal for everyone to stop it? But 
>> who are those and how do they gain authority?
>
> One problem with this is that the intervention team might not be reading all 
> threads.
> So having a way to say where there is a problem might still be useful.
> I agree deciding who the intervention team is is an important question. 
> Probably William
> would be a good choice.

Here is I think a concrete, apolitical proposal.

Given the potentially political nature of such a choice, one
possibility is to do something apolitical, and select based on
ownership. In particular, based on lines of code contributed to Sage,
which is an (imperfect!) but non-politicial measure of how much
ownership people have in Sage (with legal value, since people do not
contribute their copyright).By this definition:

   
https://github.com/sagemath/sage/graphs/contributors?from=2006-02-05&to=2014-11-18&type=a

the top 12  all time list of contributors to Sage, in order, are:

  - William Stein
  - Mike Hansen
  - Volker Braun
  - Jereon Demeyer
  - Nathann Cohen
  - Robert Bradshaw
  - Robert Miller
  - Simon King
  - John Palmieri
  - Jason Grout
  - Nicholas Thiery
  - David Kirkby


We could:

  1. Create a private mailing list called sage-abuse with these people
as members.

  2. Make a clear statement on the sagemath.org website, etc., that if
people think a thread should be on sage-flame, send a message to the
sage-abuse list.

  3. The sage-abuse list members will have a quick discussion and if
what to do isn't clear, they will vote (which means a quick on-list
vote that must be completed within one day).If a majority votes to
move the discussion should move to sage-flame, they ensure it moves.

For now, the sage-abuse group would have exactly one duty, which is to
ensure that discussions get moved to sage-flame when requested.
That's it.   We would give this a try for 6 months, and only then
revisit whether the group should expand its duties or be dissolved.


 -- William

-- 
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] inconsistent behavior with multivariate polynomial rings: what to do?

[John H Palmieri]

>From #17205:

sage: x, y = ZZ['x','y'].gens()
sage: GF(1091)['x','y'].random_element().degree(x) 
2
sage: GF(3037000453)['x','y'].random_element().degree(x) 
...
TypeError: x must be one of the generators of the parent.

I don't think the behavior should be different the polynomial rings over 
GF(1091) and GF(3037000453), but I don't know what the right behavior 
should be. Should x (which is one of the generators of ZZ[x,y]) be 
automatically coerced to an element of GF(p)[x,y] when we call 
elt.degree(x)?

-- 
John

-- 
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] Bug in abs(I*x).diff(x)

[Bill Page]

On 18 November 2014 12:29, Ondřej Čertík  wrote:
> On Tue, Nov 18, 2014 at 9:28 AM, David Roe  wrote:
>> ...
>> Because derivative is not just used in the context of functions of a
>> complex variable (whether they are analytic or not).  Probably more
>> than 90% of Sage users don't know any complex analysis (as frequently
>> lamented by rtf).  I will certainly acknowledge that people get things
>> wrong with regard to sqrt and log by not knowing about branch cuts.
>> But when it comes to the definition of derivative, we need to stay
>> consistent with the standard definition of lim_{h -> 0} (f(x + h) -
>> f(x))/h for functions of a real variable (or functions that many
>> people interpret as just functions of a real variable).  Any other
>> decision will cause frustration for the vast majority of our users.
>
> Well, I think it doesn't matter if you know complex analysis or not.

I agree, but apparently for a different reason.

> The point is rather that there is a real derivative and a complex
> derivative. The complex derivative being a generalization of the
> real one (http://en.wikipedia.org/wiki/Derivative#Generalizations,
> http://en.wikipedia.org/wiki/Generalizations_of_the_derivative#Complex_analysis).
> As such, it must reduce to the real derivative as a special case when
> all variables are real, otherwise you get inconsistencies.
>

As I said in another email, I think this is highly dependent on one's
education and experience. Although I admit that it is very common
(almost ubiquitous) to teach calculus starting from the notion of
continuity and limits, I my opinion these references on wikipedia are
especially biased.   To me from the point of view of computer algebra,
the algebraic properties of derivatives are more important.

For the sake of continuing the argument, from the point of view of
algebra why should we consider derivatives of complex functions as a
generalization of the real one rather than the real derivative as a
defined in terms of something more general?  In particular notice that
the so called Wirtinger derivatives also make sense in the case of
quaternion analysis, so should we be expecting to view quaternion
calculus also as a "generalization' of real derivatives?

OK, maybe I am pushing this a little too far.  I admit that the
argument from the point of view of limits and without any reference to
conjugate is quite convincing.

> ...
> Bill, you wrote "I think rather that one should strive for the most
> general solution
> consistent with the mathematics.". Well, the above (i.e.
> x.conjugate()/(2*abs(x)) + x/(2*abs(x)) * exp(-2*I*theta)) is the
> most general solution consistent with mathematics.
>
> Of these options, only theta=0 gives the real derivative as a special
> case, that's what the GiNaC proposal does.
>

Have you had a chance to consider the issue of the chain-rule yet?

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: Code of Conduct

[Anne Schilling]

On 11/18/14 7:55 AM, Harald Schilly wrote:
> 
> On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote:
> 
> What if instead of a "code of conduct" there was a "community 
> expectations" SHORT document that just say what we expect? 
> 
> 
> I'm a little bit late to this thread, but I've read all the mails. This 
> "expectations" document sounds interesting to me, whereas I'm a bit hesitant 
> to this "code of conduct" thing. In my eyes, it is
> stating a lot of obvious things, and doesn't solve immediate problems. I 
> agree that it could be abused in some way, just because it exists and hence 
> it is a leverage point. e.g. phrases like "poor
> behavior" are a bit hollow for me. (*)

Saying that discussions that get out of hand can be relegated to sage-flame is, 
I think, important.
For example, I did not know that we could do that until very recently. Stating 
explicitly how this can
be done might be good.

> We should not forget, that most of us here (as mathematicians & researchers 
> in general) are trained to be (a) very picky and (b) long-term persistent. 
> Those ingredients do not help if a discussion
> derails into lengthy substitution-arguments to just make a point in a 
> time-consuming thread. What would actually help in such situations is to step 
> back and look at the bigger picture. Maybe there
> should be an intervention team of "senior" community people to sort this out: 
> e.g. just posting "DRAMA MODE" as a signal for everyone to stop it? But who 
> are those and how do they gain authority?

One problem with this is that the intervention team might not be reading all 
threads.
So having a way to say where there is a problem might still be useful.
I agree deciding who the intervention team is is an important question. 
Probably William
would be a good choice.

Best,

Anne

-- 
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] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 18, 2014 at 9:28 AM, David Roe  wrote:
> On Tue, Nov 18, 2014 at 8:05 AM, Bill Page  wrote:
>> On 18 November 2014 09:02, David Roe  wrote:
>>> On Tue, Nov 18, 2014 at 5:57 AM, Bill Page  
>>> wrote:

 > I think you are overly focused on trying to define a derivative that
 > reduces to the conventional derivative of non-analytic functions
 > over the reals.

 I've just been casually following this conversation, but I think it's
 important that the derivative of abs(x) be sign(x) not 2*sign(x) or
 1/2*sign(x).

>>
>> What makes it important that "the" derivative of abs(x) be sign(x)?
>> An important point here is that there is no one single unique
>> derivative of non-analytic functions like abs, but rather than all of
>> their derivatives can be expressed in terms of just two.  I am
>> seriously interested in reasons for retaining the status quo.
>
> Because derivative is not just used in the context of functions of a
> complex variable (whether they are analytic or not).  Probably more
> than 90% of Sage users don't know any complex analysis (as frequently
> lamented by rtf).  I will certainly acknowledge that people get things
> wrong with regard to sqrt and log by not knowing about branch cuts.
> But when it comes to the definition of derivative, we need to stay
> consistent with the standard definition of lim_{h -> 0} (f(x + h) -
> f(x))/h for functions of a real variable (or functions that many
> people interpret as just functions of a real variable).  Any other
> decision will cause frustration for the vast majority of our users.

Well, I think it doesn't matter if you know complex analysis or not.
The point is rather that there is a real derivative and a complex
derivative. The complex derivative being a generalization of the real
one (http://en.wikipedia.org/wiki/Derivative#Generalizations,
http://en.wikipedia.org/wiki/Generalizations_of_the_derivative#Complex_analysis).
As such, it must reduce to the real derivative as a special case when
all variables are real, otherwise you get inconsistencies.

For example for real numbers, you get:

|x|' = x / |x| = sign(x)

and you can do this numerically. Here is a function that does this for
any angle theta in the complex plane:

def diff(f, z0, theta, eps=1e-8):
h = eps*exp(I*theta)
return (f(z0+h)-f(z0)) / h

For real numbers, you need to set theta=0. This then obviously becomes
the standard definition of a real derivative. So any other definition
than |x|' = sign(x) gives wrong answers. No matter if you know complex
analysis or not.

As far as the derivative of abs(x) in the complex plane for any theta,
the above "diff" function is just the directional derivative, i.e.
derivative in the direction theta. Based on my previous email, the
(only) correct analytic answer is, using Python notation:

x.conjugate()/(2*abs(x)) + x/(2*abs(x)) * exp(-2*I*theta)

And you can check numerically using the function "diff" above that
this is indeed the correct answer (just plug in various complex or
real values for "x" and check that "diff" and the above formula gives
the same numerical answer for all theta).

Bill, you wrote "I think rather that one should strive for the most
general solution
consistent with the mathematics.". Well, the above (i.e.
x.conjugate()/(2*abs(x)) + x/(2*abs(x)) * exp(-2*I*theta)) is the most
general solution consistent with mathematics.

Of these options, only theta=0 gives the real derivative as a special
case, that's what the GiNaC proposal does.

Ondrej

-- 
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] Code of Conduct

[Anne Schilling]

On Saturday, November 15, 2014 2:10:04 PM UTC-8, P Purkayastha wrote:

> Yes. Typically, they ban the user for a period of time. The violations are 
> dealt with on a case-by-case basis. It seems quite a few requests (code of 
> conduct violations, and otherwise) have piled up in 
> http://forums.gentoo.org/viewtopic-t-28820.html !
>

Since this seems to be one of the main questions that people have about the 
proposal, who in your community handles the code of conduct violations? How 
were they chosen?

Best,

Anne 

-- 
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] Bug in abs(I*x).diff(x)

[David Roe]

On Tue, Nov 18, 2014 at 8:05 AM, Bill Page  wrote:
> On 18 November 2014 09:02, David Roe  wrote:
>> On Tue, Nov 18, 2014 at 5:57 AM, Bill Page  
>> wrote:
>>>
>>> > I think you are overly focused on trying to define a derivative that
>>> > reduces to the conventional derivative of non-analytic functions
>>> > over the reals.
>>>
>>> I've just been casually following this conversation, but I think it's
>>> important that the derivative of abs(x) be sign(x) not 2*sign(x) or
>>> 1/2*sign(x).
>>>
>
> What makes it important that "the" derivative of abs(x) be sign(x)?
> An important point here is that there is no one single unique
> derivative of non-analytic functions like abs, but rather than all of
> their derivatives can be expressed in terms of just two.  I am
> seriously interested in reasons for retaining the status quo.

Because derivative is not just used in the context of functions of a
complex variable (whether they are analytic or not).  Probably more
than 90% of Sage users don't know any complex analysis (as frequently
lamented by rtf).  I will certainly acknowledge that people get things
wrong with regard to sqrt and log by not knowing about branch cuts.
But when it comes to the definition of derivative, we need to stay
consistent with the standard definition of lim_{h -> 0} (f(x + h) -
f(x))/h for functions of a real variable (or functions that many
people interpret as just functions of a real variable).  Any other
decision will cause frustration for the vast majority of our users.
David

>
>>> If you use a different function, like f.wirtinger_derivative(), then
>>> it doesn't matter so much.
>>> David
>>>
>
> On 18 November 2014 10:11, kcrisman  wrote:
>>
>> +1
>>
>
> Although I guess this would be consistent with the over all
> "assimilation philosophy" adopted by Sage, I am rather strongly
> against this in general.  In my opinion it is in part what has lead to
> the rather confusing situation in most other computer algebra systems.
> I think rather that one should strive for the most general solution
> consistent with the mathematics.  I suppose that to some extent this
> is conditioned by how the subject is taught.  It came as a surprise to
> me that a solution of this problem (Wirtinger calculus or CR-calculus)
> was apparently "well-known" is some circles but considered only a
> marginal curiosity in others (if at all).
>
>> That notwithstanding, this conversation is really great to see and I hope
>> we get something that works for the usual cases in the original post
>> too!
>>
>
> Provided that one realizes its limitations I think the solution
> proposed by Vladimir V. Kisil for ginac and in more generality by
> Ondrej is quite good.  I don't think a new name for this is desirable.
>
> 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.

-- 
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] Bug in abs(I*x).diff(x)

[Bill Page]

On 18 November 2014 09:02, David Roe  wrote:
> On Tue, Nov 18, 2014 at 5:57 AM, Bill Page  wrote:
>>
>> > I think you are overly focused on trying to define a derivative that
>> > reduces to the conventional derivative of non-analytic functions
>> > over the reals.
>>
>> I've just been casually following this conversation, but I think it's
>> important that the derivative of abs(x) be sign(x) not 2*sign(x) or
>> 1/2*sign(x).
>>

What makes it important that "the" derivative of abs(x) be sign(x)?
An important point here is that there is no one single unique
derivative of non-analytic functions like abs, but rather than all of
their derivatives can be expressed in terms of just two.  I am
seriously interested in reasons for retaining the status quo.

>> If you use a different function, like f.wirtinger_derivative(), then
>> it doesn't matter so much.
>> David
>>

On 18 November 2014 10:11, kcrisman  wrote:
>
> +1
>

Although I guess this would be consistent with the over all
"assimilation philosophy" adopted by Sage, I am rather strongly
against this in general.  In my opinion it is in part what has lead to
the rather confusing situation in most other computer algebra systems.
I think rather that one should strive for the most general solution
consistent with the mathematics.  I suppose that to some extent this
is conditioned by how the subject is taught.  It came as a surprise to
me that a solution of this problem (Wirtinger calculus or CR-calculus)
was apparently "well-known" is some circles but considered only a
marginal curiosity in others (if at all).

> That notwithstanding, this conversation is really great to see and I hope
> we get something that works for the usual cases in the original post
> too!
>

Provided that one realizes its limitations I think the solution
proposed by Vladimir V. Kisil for ginac and in more generality by
Ondrej is quite good.  I don't think a new name for this is desirable.

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: Code of Conduct

[Harald Schilly]

On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote:
>
> What if instead of a "code of conduct" there was a "community 
> expectations" SHORT document that just say what we expect? 
>

I'm a little bit late to this thread, but I've read all the mails. This 
"expectations" document sounds interesting to me, whereas I'm a bit 
hesitant to this "code of conduct" thing. In my eyes, it is stating a lot 
of obvious things, and doesn't solve immediate problems. I agree that it 
could be abused in some way, just because it exists and hence it is a 
leverage point. e.g. phrases like "poor behavior" are a bit hollow for me. 
(*)

We should not forget, that most of us here (as mathematicians & researchers 
in general) are trained to be (a) very picky and (b) long-term persistent. 
Those ingredients do not help if a discussion derails into lengthy 
substitution-arguments to just make a point in a time-consuming thread. 
What would actually help in such situations is to step back and look at the 
bigger picture. Maybe there should be an intervention team of "senior" 
community people to sort this out: e.g. just posting "DRAMA MODE" as a 
signal for everyone to stop it? But who are those and how do they gain 
authority?

Apart from that, I think there should also be a clarification if such rules 
are exercised on a case-by-case or person-per-person basis. I'm pretty 
sure, that if someone starts to break the rules in one thread, doesn't mean 
that we should exclude that person forever. That could very well be a 
temporary phase, some short slightness, or only happening when interacting 
with one certain person.

-- Harald

(*) even my email could be regarded as poor behavior, because I wasn't 
thankful to all of those who did work on drafting those 4 rules.

-- 
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] Bug in abs(I*x).diff(x)

[kcrisman]

>
> > I think you are overly focused on trying to define a derivative that 
> > reduces to the conventional derivative of non-analytic functions over 
> > the reals. 
>
> I've just been casually following this conversation, but I think it's 
> important that the derivative of abs(x) be sign(x) not 2*sign(x) or 
> 1/2*sign(x). 
>
> If you use a different function, like f.wirtinger_derivative(), then 
> it doesn't matter so much. 
> David 
>
>
+1

That notwithstanding, this conversation is really great to see and I hope 
we get something that works for the usual cases in the original post 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] Re: c++11, mpirxx, and normaliz problem

[Dima Pasechnik]

On 2014-11-18, Volker Braun  wrote:
> --=_Part_3954_883918061.1416322498399
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> Yes, this is a MPIR bug. In mpir.h, the following takes place:
>
> #define __need_size_t  /* tell gcc stddef.h we only want size_t */
> #include  /* for size_t */
>
> As expected from changing implementation macros, his breaks sooner or later=

Thanks. I wonder if blatant abuse of gcc headers is allowed by the draft Sage
Code of Conduct...

>:
>
> $ gcc -std=3Dc++11 align.cc
> In file included from align.cc:2:0:
> /usr/include/c++/4.9.2/cstddef:51:11: error: =E2=80=98::max_align_t=E2=80=
>=99 has not been=20
> declared
>using ::max_align_t;
>^
>
>=20
>
> On Tuesday, November 18, 2014 2:39:32 PM UTC, Dima Pasechnik wrote:
>>
>> basically, current (upstream) normaliz does not compile with gcc 4.9.2;=
>=20
>> (with Sage 4.5.beta0).=20
>> I tracked it down to the following test, showing that mpir(xx) does=20
>> something strange...=20
>>
>> $ cat b.cpp=20
>> #include =20
>> int main()=20
>> {=20
>> return alignof(std::max_align_t);=20
>> }=20
>>
>> $ g++   -std=3Dc++11 -c b.cpp=20
>> In file included from=20
>> /home/scratch/dimpase/sage/sage6.3/local/include/mpir.h:53:0,=20
>>  from=20
>> /home/scratch/dimpase/sage/sage6.3/local/include/mpirxx.h:44,=20
>>  from b.cpp:1:=20
>> /home/scratch/dimpase/sage/sage6.3/local/include/c++/4.9.2/cstddef:51:11:=
>=20
>> error: '::max_align_t' has not been declared=20
>>using ::max_align_t;=20
>>^=20
>> b.cpp: In function 'int main()':=20
>> b.cpp:6:20: error: 'max_align_t' is not a member of 'std'=20
>>  return alignof(std::max_align_t);=20
>>
>> e$ g++ -v=20
>> Using built-in specs.=20
>> COLLECT_GCC=3D/home/scratch/dimpase/sage/sage6.3/local/bin/g++=20
>> COLLECT_LTO_WRAPPER=3D/home/scratch/dimpase/sage/sage6.3/local/libexec/gc=
> c/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper=20
>>
>> Target: x86_64-unknown-linux-gnu=20
>> Configured with: ../src/configure=20
>> --prefix=3D/home/scratch/dimpase/sage/sage6.3/local=20
>> --with-local-prefix=3D/home/scratch/dimpase/sage/sage6.3/local=20
>> --with-gmp=3D/home/scratch/dimpase/sage/sage6.3/local=20
>> --with-mpfr=3D/home/scratch/dimpase/sage/sage6.3/local=20
>> --with-mpc=3D/home/scratch/dimpase/sage/sage6.3/local --with-system-zlib=
>=20
>> --disable-multilib --disable-nls --enable-languages=3Dc,c++,fortran=20
>> --disable-libitm  =20
>> Thread model: posix=20
>> gcc version 4.9.2 (GCC)=20
>>
>>
>>
>
> --=20
> 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 e=
> mail 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.
>
> --=_Part_3954_883918061.1416322498399
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
>Yes, this is a MPIR bug. In mpir.h, the following takes pl=
> ace:#define __need_size_t  /* tell gcc stddef=
> .h we only want size_t */#include      =
> /* for size_t */As expected from changing i=
> mplementation macros, his breaks sooner or later:=
>$ gcc -std=3Dc++11 align.ccIn file included from align.cc:2=
>:0:/usr/include/c++/4.9.2/cstddef:51:11: error: =E2=80=98::max_a=
> lign_t=E2=80=99 has not been declared   using ::max_al=
> ign_t;           ^> On Tuesday, November 18, 2014 2:39:32 PM UTC,=
>  Dima Pasechnik wrote: margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">basicall=
> y, current (upstream) normaliz does not compile with gcc 4.9.2;=20
>(with Sage 4.5.beta0).
>I tracked it down to the following test, showing that mpir(xx) does
>something strange...
>
>$ cat b.cpp
>#include 
>int main()
>{
>    return alignof(std::max_align_t);
>}
>
>$ g++   -std=3Dc++11 -c b.cpp
>In file included from
>/home/scratch/dimpase/sage/sage6.3/local/include/mpir.h:53:0,
>                 from
>/home/scratch/dimpase/sage/sage6.3/local/include/mpirxx.h:44,
>                 from b.cp=
> p:1:
>/home/scratch/dimpase/sage/sage6.3/local/include/c++/4.9.2/cs=
> tddef:51:11:
>error: '::max_align_t' has not been declared
>   using ::max_align_t;
>           ^
>b.cpp: In function 'int main()':
>b.cpp:6:20: error: 'max_align_t' is not a member of 'std'
>     return alignof(std::max_align_t);
>
>e$ g++ -v
>Using built-in specs.
>COLLECT_GCC=3D/home/scratch/dimpase/sage/sage6.3/local/bin/g+=
> +
>COLLECT_LTO_WRAPPER=3D/home/scratch/dimpase/sage/sage6.3/loca=
> l/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
>Target: x86_64-unknown-linux-gnu
>Configured with: ../src/configure
>--prefix=3D/home/scratch/dimpase/sage/sage6.3/local
>--with-local-prefix=3D/home/scratch/dimpase/sage/sage6.3/loca=
> l
>--with-g

[sage-devel] Re: c++11, mpirxx, and normaliz problem

[Dima Pasechnik]

On 2014-11-18, Dima Pasechnik  wrote:
> basically, current (upstream) normaliz does not compile with gcc 4.9.2; 
> (with Sage 4.5.beta0).
> I tracked it down to the following test, showing that mpir(xx) does
> something strange...

As Jeroen mentiones on the mpir list, a workaround is suggested in
https://gcc.gnu.org/gcc-4.9/porting_to.html, section 
Header  changes 

And it seems to help here.
>
> $ cat b.cpp
> #include 
> int main()
> {
> return alignof(std::max_align_t);
> }
>
> $ g++   -std=c++11 -c b.cpp
> In file included from
> /home/scratch/dimpase/sage/sage6.3/local/include/mpir.h:53:0,
>  from
> /home/scratch/dimpase/sage/sage6.3/local/include/mpirxx.h:44,
>  from b.cpp:1:
> /home/scratch/dimpase/sage/sage6.3/local/include/c++/4.9.2/cstddef:51:11:
> error: '::max_align_t' has not been declared
>using ::max_align_t;
>^
> b.cpp: In function 'int main()':
> b.cpp:6:20: error: 'max_align_t' is not a member of 'std'
>  return alignof(std::max_align_t);
>
> e$ g++ -v
> Using built-in specs.
> COLLECT_GCC=/home/scratch/dimpase/sage/sage6.3/local/bin/g++
> COLLECT_LTO_WRAPPER=/home/scratch/dimpase/sage/sage6.3/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
> Target: x86_64-unknown-linux-gnu
> Configured with: ../src/configure
> --prefix=/home/scratch/dimpase/sage/sage6.3/local
> --with-local-prefix=/home/scratch/dimpase/sage/sage6.3/local
> --with-gmp=/home/scratch/dimpase/sage/sage6.3/local
> --with-mpfr=/home/scratch/dimpase/sage/sage6.3/local
> --with-mpc=/home/scratch/dimpase/sage/sage6.3/local --with-system-zlib
> --disable-multilib --disable-nls --enable-languages=c,c++,fortran
> --disable-libitm  
> Thread model: posix
> gcc version 4.9.2 (GCC) 
>
>

-- 
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: c++11, mpirxx, and normaliz problem

[Volker Braun]

Yes, this is a MPIR bug. In mpir.h, the following takes place:

#define __need_size_t  /* tell gcc stddef.h we only want size_t */
#include  /* for size_t */

As expected from changing implementation macros, his breaks sooner or later:

$ gcc -std=c++11 align.cc
In file included from align.cc:2:0:
/usr/include/c++/4.9.2/cstddef:51:11: error: ‘::max_align_t’ has not been 
declared
   using ::max_align_t;
   ^

 

On Tuesday, November 18, 2014 2:39:32 PM UTC, Dima Pasechnik wrote:
>
> basically, current (upstream) normaliz does not compile with gcc 4.9.2; 
> (with Sage 4.5.beta0). 
> I tracked it down to the following test, showing that mpir(xx) does 
> something strange... 
>
> $ cat b.cpp 
> #include  
> int main() 
> { 
> return alignof(std::max_align_t); 
> } 
>
> $ g++   -std=c++11 -c b.cpp 
> In file included from 
> /home/scratch/dimpase/sage/sage6.3/local/include/mpir.h:53:0, 
>  from 
> /home/scratch/dimpase/sage/sage6.3/local/include/mpirxx.h:44, 
>  from b.cpp:1: 
> /home/scratch/dimpase/sage/sage6.3/local/include/c++/4.9.2/cstddef:51:11: 
> error: '::max_align_t' has not been declared 
>using ::max_align_t; 
>^ 
> b.cpp: In function 'int main()': 
> b.cpp:6:20: error: 'max_align_t' is not a member of 'std' 
>  return alignof(std::max_align_t); 
>
> e$ g++ -v 
> Using built-in specs. 
> COLLECT_GCC=/home/scratch/dimpase/sage/sage6.3/local/bin/g++ 
> COLLECT_LTO_WRAPPER=/home/scratch/dimpase/sage/sage6.3/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
>  
>
> Target: x86_64-unknown-linux-gnu 
> Configured with: ../src/configure 
> --prefix=/home/scratch/dimpase/sage/sage6.3/local 
> --with-local-prefix=/home/scratch/dimpase/sage/sage6.3/local 
> --with-gmp=/home/scratch/dimpase/sage/sage6.3/local 
> --with-mpfr=/home/scratch/dimpase/sage/sage6.3/local 
> --with-mpc=/home/scratch/dimpase/sage/sage6.3/local --with-system-zlib 
> --disable-multilib --disable-nls --enable-languages=c,c++,fortran 
> --disable-libitm   
> Thread model: posix 
> gcc version 4.9.2 (GCC) 
>
>
>

-- 
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] c++11, mpirxx, and normaliz problem

[Francesco Biscani]

Looks like this might be the root:

https://gcc.gnu.org/gcc-4.9/porting_to.html

Unformatted quoting:

"""
Header  changes

The  header was updated for C++11 support and this breaks some
libraries which misuse macros meant for internal use by GCC only. For
instance with GMP versions up to 5.1.3, you may see:

/usr/include/c++/4.9.0/cstddef:51:11: error: ‘::max_align_t’ has not been
declared
   using ::max_align_t;
   ^
Another possible error is:

someheader.h:99:13: error: ‘ptrdiff_t’ does not name a type

A workaround until libraries get updated is to include  or
 before any headers from that library.
"""

On 18 November 2014 15:39, Dima Pasechnik  wrote:

> basically, current (upstream) normaliz does not compile with gcc 4.9.2;
> (with Sage 4.5.beta0).
> I tracked it down to the following test, showing that mpir(xx) does
> something strange...
>
> $ cat b.cpp
> #include 
> int main()
> {
> return alignof(std::max_align_t);
> }
>
> $ g++   -std=c++11 -c b.cpp
> In file included from
> /home/scratch/dimpase/sage/sage6.3/local/include/mpir.h:53:0,
>  from
> /home/scratch/dimpase/sage/sage6.3/local/include/mpirxx.h:44,
>  from b.cpp:1:
> /home/scratch/dimpase/sage/sage6.3/local/include/c++/4.9.2/cstddef:51:11:
> error: '::max_align_t' has not been declared
>using ::max_align_t;
>^
> b.cpp: In function 'int main()':
> b.cpp:6:20: error: 'max_align_t' is not a member of 'std'
>  return alignof(std::max_align_t);
>
> e$ g++ -v
> Using built-in specs.
> COLLECT_GCC=/home/scratch/dimpase/sage/sage6.3/local/bin/g++
>
> COLLECT_LTO_WRAPPER=/home/scratch/dimpase/sage/sage6.3/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
> Target: x86_64-unknown-linux-gnu
> Configured with: ../src/configure
> --prefix=/home/scratch/dimpase/sage/sage6.3/local
> --with-local-prefix=/home/scratch/dimpase/sage/sage6.3/local
> --with-gmp=/home/scratch/dimpase/sage/sage6.3/local
> --with-mpfr=/home/scratch/dimpase/sage/sage6.3/local
> --with-mpc=/home/scratch/dimpase/sage/sage6.3/local --with-system-zlib
> --disable-multilib --disable-nls --enable-languages=c,c++,fortran
> --disable-libitm
> Thread model: posix
> gcc version 4.9.2 (GCC)
>
>
> --
> 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] c++11, mpirxx, and normaliz problem

[Dima Pasechnik]

basically, current (upstream) normaliz does not compile with gcc 4.9.2; 
(with Sage 4.5.beta0).
I tracked it down to the following test, showing that mpir(xx) does
something strange...

$ cat b.cpp
#include 
int main()
{
return alignof(std::max_align_t);
}

$ g++   -std=c++11 -c b.cpp
In file included from
/home/scratch/dimpase/sage/sage6.3/local/include/mpir.h:53:0,
 from
/home/scratch/dimpase/sage/sage6.3/local/include/mpirxx.h:44,
 from b.cpp:1:
/home/scratch/dimpase/sage/sage6.3/local/include/c++/4.9.2/cstddef:51:11:
error: '::max_align_t' has not been declared
   using ::max_align_t;
   ^
b.cpp: In function 'int main()':
b.cpp:6:20: error: 'max_align_t' is not a member of 'std'
 return alignof(std::max_align_t);

e$ g++ -v
Using built-in specs.
COLLECT_GCC=/home/scratch/dimpase/sage/sage6.3/local/bin/g++
COLLECT_LTO_WRAPPER=/home/scratch/dimpase/sage/sage6.3/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure
--prefix=/home/scratch/dimpase/sage/sage6.3/local
--with-local-prefix=/home/scratch/dimpase/sage/sage6.3/local
--with-gmp=/home/scratch/dimpase/sage/sage6.3/local
--with-mpfr=/home/scratch/dimpase/sage/sage6.3/local
--with-mpc=/home/scratch/dimpase/sage/sage6.3/local --with-system-zlib
--disable-multilib --disable-nls --enable-languages=c,c++,fortran
--disable-libitm  
Thread model: posix
gcc version 4.9.2 (GCC) 


-- 
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: About recmpilations caused by Git

[Felix Salfelder]

On Tue, Nov 18, 2014 at 03:35:57AM -0800, Volker Braun wrote:
> The problem with union file systems is that you don't have a good option on 
> OSX (e.g. forget about the built-in union fs). 

Hi Volker.

i dont think that reviews made on non-OSX computers are inferior. and,
nobody would keep you from recompiling on OSX, while other platforms do
better. anyway there must be something like cp -a on OSX, and can
probably be used instead, to bridge the semantics -- until OSX gets a
suitable update. yes, there might be some impact on efficiency, clearly
SEP...

note that sage includes conditional stuff that only works for OSX, and
is of no use otherwise (which is not a bad thing!).

cheers
felix

PS: i have not used aufs or anything like it. it appears to potentially
solve a problem. if its not perfect, maybe recompilations are still
worse.

-- 
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] Bug in abs(I*x).diff(x)

[David Roe]

On Tue, Nov 18, 2014 at 5:57 AM, Bill Page  wrote:
> On 17 November 2014 23:16, Ondřej Čertík  wrote:
>> Hi Bill,
>>
>> Thanks for the clarification. So your point is that 2) is not
>> sufficient, that we really need two Wirtinger derivatives --- it's
>> just that one can be expressed using the other and a conjugate,
>> so perhaps CAS can only return one, but a chain rule needs
>> modification and probably some other derivatives handling as
>> well. I need to think about this harder.
>>
>
> Yes, that is a good summary.  My tentative conclusion was that we
> could implement just one (Wirtinger) derivative, a modified chain rule
> and a sufficiently strong conjugate operation.  This derivative is the
> same as the usual derivative in the case of analytic functions but we
> would have to live with the fact that it is slightly different (factor
> of 1/2) for the case of common real derivatives of non-analytic
> functions such as abs.  Introducing a factor of 2, such as in the case
> of the definition of the sign function seems like a small price to
> pay.
>
>> Here is a relation that I found today in [1] (see also the references
>> there), I don't know if you are aware of it:
>>
>> D f / D z = df/dz + df/d conjugate(z) * e^{-2*i*theta}
>>
>> Where Df/Dz is the derivative in a complex plane along the direction
>> theta (the angle between the direction and the x-axis) and df/dz and
>> df/d conjugate(z) are the two Wirtinger derivatives. This formula
>> holds for any function. So all the derivatives no matter which
>> direction lie on a circle of radius df/d conjugate(z) and center
>> df/dz.
>>
>> [1] Pyle, H. R., & Barker, B. M. (1946). A Vector Interpretation of
>> the Derivative Circle. The American Mathematical Monthly, 53(2), 79.
>> doi:10.2307/2305454
>
> http://phdtree.org/pdf/36421281-a-vector-interpretation-of-the-derivative-circle/
>
> Thank you.  I was not aware of that specific publication.  I think
> their geometric interpretation is useful.
>
>>
>> For CAS, one could probably just say that theta=0 in our definition,
>> and then everything is consistent, and we only have one derivative,
>> 2). The other option is to return both derivatives and make the
>> derivative Df/Dz of non-analytic function equal to the above formula,
>> i.e. depending on df/dz, df/d conjugate(z) and theta.
>
> I think you are overly focused on trying to define a derivative that
> reduces to the conventional derivative of non-analytic functions over
> the reals.

I've just been casually following this conversation, but I think it's
important that the derivative of abs(x) be sign(x) not 2*sign(x) or
1/2*sign(x).

If you use a different function, like f.wirtinger_derivative(), then
it doesn't matter so much.
David

>
>>
>> I need to think about the chain rule. I would simply introduce the
>> theta dependence into all formulas, as that gives all possible
>> derivatives and gives the exact functional dependence of all
>> possibilities. And then see whether we need to keep all formulas
>> in terms of theta, or perhaps if we can set theta = 0 for everything.
>>
>
> It is not clear to me how to use such as "generic" derivative in the
> application of the chain rule.
>
> 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.

-- 
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: Code of Conduct

[kcrisman]

>
>
> >> rjf, I (once again) *highly* recommend Steven Weber's 
> >> http://www.hup.harvard.edu/catalog.php?isbn=9780674018587 "The Success 
> of 
> >> Open Source", in particular the chapters on self-governance in open 
> source, 
> >> as a place to start reading about this.   
> >> 
> > 
> > Ironically, Weber's book is itself not free, but is sold for $24.50.   
> > Maybe his belief in open whatever does not 
> > extend to the intellectual property that he himself produces.. 
> Maybe you are confusing scientific literature (published by a 
> traditional publisher) with religious one? 
>
>
Not to mention that tenure committees probably aren't too hot on things 
release with a CC-BY license, more's the pity ;-)   This is not a dogmatic 
work, though it does take a side, like most social science literature.
 

> > Can you provide a link to an open discussion of this matter? 
> > (while I could perhaps borrow a copy from a library, there are people 
> who 
> > might not 
> > have access to a library copy.  etc.) 
> >  


True, but if I recall correctly, at one time rms also charged for certain 
GNU documentation - not the code!  In fact, O'Reilly seems to have made an 
entire business model of this - and perhaps not unfair, if one believes 
that the moral issue is access to the *code*/program, not how to use it. 
 This is one of many reasons that improving Sage's documentation (or 
Maxima's, or anything) is so crucial to making the promise of open source 
be useful to those outside the cognoscenti. 

- kcrisman

-- 
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] Bug in abs(I*x).diff(x)

[Bill Page]

On 17 November 2014 23:16, Ondřej Čertík  wrote:
> Hi Bill,
>
> Thanks for the clarification. So your point is that 2) is not
> sufficient, that we really need two Wirtinger derivatives --- it's
> just that one can be expressed using the other and a conjugate,
> so perhaps CAS can only return one, but a chain rule needs
> modification and probably some other derivatives handling as
> well. I need to think about this harder.
>

Yes, that is a good summary.  My tentative conclusion was that we
could implement just one (Wirtinger) derivative, a modified chain rule
and a sufficiently strong conjugate operation.  This derivative is the
same as the usual derivative in the case of analytic functions but we
would have to live with the fact that it is slightly different (factor
of 1/2) for the case of common real derivatives of non-analytic
functions such as abs.  Introducing a factor of 2, such as in the case
of the definition of the sign function seems like a small price to
pay.

> Here is a relation that I found today in [1] (see also the references
> there), I don't know if you are aware of it:
>
> D f / D z = df/dz + df/d conjugate(z) * e^{-2*i*theta}
>
> Where Df/Dz is the derivative in a complex plane along the direction
> theta (the angle between the direction and the x-axis) and df/dz and
> df/d conjugate(z) are the two Wirtinger derivatives. This formula
> holds for any function. So all the derivatives no matter which
> direction lie on a circle of radius df/d conjugate(z) and center
> df/dz.
>
> [1] Pyle, H. R., & Barker, B. M. (1946). A Vector Interpretation of
> the Derivative Circle. The American Mathematical Monthly, 53(2), 79.
> doi:10.2307/2305454

http://phdtree.org/pdf/36421281-a-vector-interpretation-of-the-derivative-circle/

Thank you.  I was not aware of that specific publication.  I think
their geometric interpretation is useful.

>
> For CAS, one could probably just say that theta=0 in our definition,
> and then everything is consistent, and we only have one derivative,
> 2). The other option is to return both derivatives and make the
> derivative Df/Dz of non-analytic function equal to the above formula,
> i.e. depending on df/dz, df/d conjugate(z) and theta.

I think you are overly focused on trying to define a derivative that
reduces to the conventional derivative of non-analytic functions over
the reals.

>
> I need to think about the chain rule. I would simply introduce the
> theta dependence into all formulas, as that gives all possible
> derivatives and gives the exact functional dependence of all
> possibilities. And then see whether we need to keep all formulas
> in terms of theta, or perhaps if we can set theta = 0 for everything.
>

It is not clear to me how to use such as "generic" derivative in the
application of the chain rule.

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: sage-6.4 fallout: the normaliz package is now broken

[Dima Pasechnik]

On 2014-11-15, William Stein  wrote:
> Hi,
>
> I guess the upgrade to patch broke more optional packages:
>
> sage -i normaliz
> ...
>
> gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
> 
> patching file source/Makefile.configuration
> (Stripping trailing CRs from patch; use --binary to disable.)
> patching file Singular/normaliz.lib
> Hunk #1 FAILED at 1371 (different line endings).
> 1 out of 1 hunk FAILED -- saving rejects to file Singular/normaliz.lib.rej
> Error: Couldn't apply patch.
>
> real0m0.010s
> user0m0.005s
> sys 0m0.005s
> 
> Error installing package normaliz-2.8.p0

OK, I'll try updating normaliz to the current version (2.12.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.

[sage-devel] Re: checkout for closed tickets which are not yet in develop

[kcrisman]

>
> What is our policy concerning deleting branches from the trac repositories 
> (e.g., I usually delete all branches on trac which are merged in a stable 
> release, say, just to unclutter the name space there)? 
>
> The current workflow (replacing the branch by the commit id when closing 
> the 
> ticket) suggests that the branch could be deleted at that stage; actually, 
> it 
> should only be deleted later (when the ticket is part of a release), 
> because 
> your workflow described above depends on that (well, ok, you do not do git 
> remote update --prune trac). 
>
> If the "merged in" field would be set when releasing a develop version, 
> then the 
> replacement of the branch name by the commit id in the ticket could occur 
> at the 
> same time (and not at the time when closing the ticket). 
>
>
+1 - but see https://github.com/sagemath/git-trac-command/issues/18 because 
there might be more technical challenges to making that happen than one 
thinks.  If you have any ideas that can solve Volker's comments about 
possible problems with this that would be fantastic.

- kcrisman 

-- 
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: About recmpilations caused by Git

[kcrisman]

>
>
> > Also part of the problem is the use of 'make' that is recommended 
> Yes, and there are good reasons for this. 
>
> > I've gone back to sage -b. 
> Please don't, or at the very least don't ever report a bug or failing 
> doctest without doing "make" first. 
>
> The problem with "sage -b" is that you *include* Sage library changes 
> because of a new package version but you *exclude* the actual package 
> changes. 
>
>
Ah, I only do this when checking out Sage library-only branches that I then 
merge develop into (which is okay because I am only reviewing them, not 
committing), for exactly this reason.  
 

> Forget your past experiences and try again now that we have #17286. 
>
>
Okay, we'll see! That certainly should help a lot.

-- 
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: About recmpilations caused by Git

[Jeroen Demeyer]

On 2014-11-17 15:03, kcrisman wrote:

Also part of the problem is the use of 'make' that is recommended

Yes, and there are good reasons for this.


I've gone back to sage -b.
Please don't, or at the very least don't ever report a bug or failing 
doctest without doing "make" first.


The problem with "sage -b" is that you *include* Sage library changes 
because of a new package version but you *exclude* the actual package 
changes.


Forget your past experiences and try again now that we have #17286.


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] About recmpilations caused by Git

[Jeroen Demeyer]

Ticket #17286 has been merged in sage-6.5.beta0 which should solve most 
of the problems mentioned in this thread.


One major cause of recompilation what that Python implicitly depended on 
$SAGE_ROOT/configure, which changes in every single Sage version. So 
going from one beta to a different beta changes configure, requiring 
recompilation of Python and everything depending on Python.


This big recompilation shouldn't happen anymore (assuming you switch to 
branches including #17286).


--
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] Octave interface broken

[Jan Groenewald]

Hi

I have 6.3

I am glad to see this is fixed in 6.4.
I do not see 6.4 binaries for Ubuntu 14.04, so I have not updated the PPA
yet.
ftp://ftp.sun.ac.za/pub/mirrors/www.sagemath.org/linux/64bit/index.html

Regards,
Jan

On 18 November 2014 13:15, Francois Bissey  wrote:

> Which version of sage? It should have been fixed in 6.4. We initially
> spotted this in sage-on-gentoo and someone finally opened an issue for it
> that got merged in 6.4:
> https://github.com/cschwan/sage-on-gentoo/issues/289
>
> François
> > On 18/11/2014, at 23:48, Jan Groenewald  wrote:
> >
> > Hi
> >
> > Original problem: a PPA sage has a sage installation with system-wide
> files owned by root.
> >
> > Such a user running octave('1+1') get permission denied:
> /usr/lib/sagemath/local/share/
> > sage/ext/octave/user instead of running octave code (it does not clearly
> say those don't exist, it just says permission denied).
> >
> > Regards,
> > Jan
> >
> >
> > On 18 November 2014 10:30, Jan Groenewald  wrote:
> >
> > Hi
> >
> > By default our PPA installation does not have the folders octave and
> user in
> >
> > /usr/lib/sagemath/local/share/sage/ext/octave/user
> >
> > And /usr/lib/sagemath/local/share/sage/ext/ is owned by root in a
> system-wide install. I can add these two folders to the PPA, but would
> rather have then added upstream with the correct permissions (755).
> >
> > If I run
> >
> > sage: octave('1+1')
> >
> > as root, the folders get created permission 700 and owned by root. Once
> I made them 755, normal users can run octave in sage, and there does not
> seem to be any files savedin those folders, they just need to exist. One
> error remains though, when exiting sage:
> >
> >
> > sage: octave('1+2')
> >  3
> > sage: r=octave('rand(1)')
> > sage: r
> >  0.484611
> > sage:
> > Exiting Sage (CPU time 0m0.30s, Wall time 2m43.88s).
> > Exiting spawned Octave process.
> > Octave crashed -- automatically restarting.
> > Octave crashed -- automatically restarting.
> > 0 jan@mangoky:~$logout
> > Connection to mangoky closed.
> > 0 jan@muizenberg:/var/autofs/misc/home/jan$
> >
> >
> > (whether run as me or as root I still get this message that octave
> crashed).
> >
> > Regards,
> > Jan
> >
> >
> >
> >
> > --
> >   .~.
> >   /V\ Jan Groenewald
> >  /( )\www.aims.ac.za
> >  ^^-^^
> >
> >
> >
> > --
> >   .~.
> >   /V\ Jan Groenewald
> >  /( )\www.aims.ac.za
> >  ^^-^^
> >
> > --
> > 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.
>



-- 
  .~.
  /V\ Jan Groenewald
 /( )\www.aims.ac.za
 ^^-^^

-- 
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: About recmpilations caused by Git

[Volker Braun]

On Tuesday, November 18, 2014 8:12:42 AM UTC, Felix Salfelder wrote:
>
> - aufs [2]. use an overlay for reviewing. afterwards discard it and return 
>   to the previous state. 
>

The problem with union file systems is that you don't have a good option on 
OSX (e.g. forget about the built-in union fs). 

Even better: docker images can build on other images, just create a new 
container for each review and destroy the container when you are finished. 
But no native support on OSX. 

-- 
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: checkout for closed tickets which are not yet in develop

[Clemens Heuberger]

Am 2014-11-16 um 12:27 schrieb Volker Braun:
> On Sunday, November 16, 2014 6:34:56 AM UTC, Clemens Heuberger wrote:
> 
> > Works for me, possibly because I have a newer git.
> Can it be that it works for you because the commit
> ec0aae9358f5204a3db6406b2c2f2818a78f5892 (this is the actual commit of 
> #16747)
> is contained in your local repository?
> 
> 
> Yes, and I have the commit visible because I ran "git remote update trac" (and
> trac is not set up as tracking remote). This pulls down all branches, so in
> particular it makes the commit visible again.

What is our policy concerning deleting branches from the trac repositories
(e.g., I usually delete all branches on trac which are merged in a stable
release, say, just to unclutter the name space there)?

The current workflow (replacing the branch by the commit id when closing the
ticket) suggests that the branch could be deleted at that stage; actually, it
should only be deleted later (when the ticket is part of a release), because
your workflow described above depends on that (well, ok, you do not do git
remote update --prune trac).

If the "merged in" field would be set when releasing a develop version, then the
replacement of the branch name by the commit id in the ticket could occur at the
same time (and not at the time when closing the ticket).

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] Octave interface broken

[Francois Bissey]

Which version of sage? It should have been fixed in 6.4. We initially spotted 
this in sage-on-gentoo and someone finally opened an issue for it that got 
merged in 6.4:
https://github.com/cschwan/sage-on-gentoo/issues/289

François
> On 18/11/2014, at 23:48, Jan Groenewald  wrote:
> 
> Hi
> 
> Original problem: a PPA sage has a sage installation with system-wide files 
> owned by root.
> 
> Such a user running octave('1+1') get permission denied: 
> /usr/lib/sagemath/local/share/
> sage/ext/octave/user instead of running octave code (it does not clearly say 
> those don't exist, it just says permission denied).
> 
> Regards,
> Jan
> 
> 
> On 18 November 2014 10:30, Jan Groenewald  wrote:
> 
> Hi
> 
> By default our PPA installation does not have the folders octave and user in 
> 
> /usr/lib/sagemath/local/share/sage/ext/octave/user
> 
> And /usr/lib/sagemath/local/share/sage/ext/ is owned by root in a system-wide 
> install. I can add these two folders to the PPA, but would rather have then 
> added upstream with the correct permissions (755).
> 
> If I run 
> 
> sage: octave('1+1')
> 
> as root, the folders get created permission 700 and owned by root. Once I 
> made them 755, normal users can run octave in sage, and there does not seem 
> to be any files savedin those folders, they just need to exist. One error 
> remains though, when exiting sage:
> 
> 
> sage: octave('1+2')
>  3
> sage: r=octave('rand(1)')
> sage: r
>  0.484611
> sage: 
> Exiting Sage (CPU time 0m0.30s, Wall time 2m43.88s).
> Exiting spawned Octave process.
> Octave crashed -- automatically restarting.
> Octave crashed -- automatically restarting.
> 0 jan@mangoky:~$logout
> Connection to mangoky closed.
> 0 jan@muizenberg:/var/autofs/misc/home/jan$
> 
> 
> (whether run as me or as root I still get this message that octave crashed).
> 
> Regards,
> Jan
> 
> 
> 
> 
> -- 
>   .~. 
>   /V\ Jan Groenewald
>  /( )\www.aims.ac.za
>  ^^-^^ 
> 
> 
> 
> -- 
>   .~. 
>   /V\ Jan Groenewald
>  /( )\www.aims.ac.za
>  ^^-^^ 
> 
> -- 
> 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: Relabeling posets vs. lattices

[Nathann Cohen]

Hello !

> Because after thinking this it kind of feels wrong. A class should not
> "know" other classes deriving from it.

Yes yes. Well, "the correct way" would be to implement .relabel() in
every superclass. But like for "disjoint union" that is a lot of code
(+doc) for almost nothing, so listing the known superclasses in the
function as you did is a good way out I believe.

> And in theory someone could also
> extend class hierarchy, for example to have distributed lattices to be own
> class (with, for example, function giving the unique complement of an
> element). After that one should also modify posets.py.

Yep. Well, either implement it 4 times or centralize it all in
posets.py, as you prefer.

> It is #17142 and you already are at cc field.

Oh okay. The only tickets I have in mind are those on needs_review
that I should work on. I will review it when it will be implemented
:-)

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: Relabeling posets vs. lattices

[Jori Mantysalo]

On Tue, 18 Nov 2014, Nathann Cohen wrote:

Why don't you do what you did for ordinal sum, and change the code of 
Poset to deal with the "lattice" case ?


Because after thinking this it kind of feels wrong. A class should not 
"know" other classes deriving from it. And in theory someone could also 
extend class hierarchy, for example to have distributed lattices to be own 
class (with, for example, function giving the unique complement of an 
element). After that one should also modify posets.py.



P.S. : please add me in Cc for the review


It is #17142 and you already are at cc field.

--
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.

[sage-devel] Re: Octave interface broken

[Jan Groenewald]

Hi

Original problem: a PPA sage has a sage installation with system-wide files
owned by root.

Such a user running octave('1+1') get permission denied:
/usr/lib/sagemath/local/share/
sage/ext/octave/user instead of running octave code (it does not clearly
say those don't exist, it just says permission denied).

Regards,
Jan


On 18 November 2014 10:30, Jan Groenewald  wrote:

>
> Hi
>
> By default our PPA installation does not have the folders octave and user
> in
>
> /usr/lib/sagemath/local/share/sage/ext/octave/user
>
> And /usr/lib/sagemath/local/share/sage/ext/ is owned by root in a
> system-wide install. I can add these two folders to the PPA, but would
> rather have then added upstream with the correct permissions (755).
>
> If I run
>
> sage: octave('1+1')
>
> as root, the folders get created permission 700 and owned by root. Once I
> made them 755, normal users can run octave in sage, and there does not seem
> to be any files savedin those folders, they just need to exist. One error
> remains though, when exiting sage:
>
>
> sage: octave('1+2')
>  3
> sage: r=octave('rand(1)')
> sage: r
>  0.484611
> sage:
> Exiting Sage (CPU time 0m0.30s, Wall time 2m43.88s).
> Exiting spawned Octave process.
> Octave crashed -- automatically restarting.
> Octave crashed -- automatically restarting.
> 0 jan@mangoky:~$logout
> Connection to mangoky closed.
> 0 jan@muizenberg:/var/autofs/misc/home/jan$
>
>
> (whether run as me or as root I still get this message that octave
> crashed).
>
> Regards,
> Jan
>
>
>
>
> --
>   .~.
>   /V\ Jan Groenewald
>  /( )\www.aims.ac.za
>  ^^-^^
>



-- 
  .~.
  /V\ Jan Groenewald
 /( )\www.aims.ac.za
 ^^-^^

-- 
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: Relabeling posets vs. lattices

[Nathann Cohen]

Hello !

Well, I would say that rewriting Poset.relabel to use the master's class 
directly (which would be Poset,or Lattice, or UpperSemiLattice ...) would 
be too much, though I do not think that it would ever lead to actual 
mistake. Why don't you do what you did for disjoint union, and change the 
code of Poset to deal with the "lattice" case ?

It keeps the length of the code to a minimum, and it is safe. It is a bit 
unpleasant to do the same thing several times though :-/

Nathann

P.S. : please add me in Cc for the review

-- 
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] Relabeling posets vs. lattices

[Jori Mantysalo]

This says that after relabeling a lattice we have a poset:

L=LatticePoset({0:[1]})
type(L.relabel(lambda n: n+1))

Should this be corrected at posets.py, or should lattices.py contain 
wrapper functions? As a code perspective it seems logical to a class 
derived from poset to define it's own function. On the user perspective 
relabeling of a lattice is just a relabeling of a poset, it is kind of 
"just the same thing". (Whereas, for example, subposet of a lattice is not 
always a lattice.)


Or should we left it to user to say LatticePoset(L.relabel(...))?

--
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.

[sage-devel] Re: Code of Conduct

[Dima Pasechnik]

On 2014-11-15, rjf  wrote:
> --=_Part_62_455616071.1416063379935
> Content-Type: text/plain; charset=UTF-8
>
>
>
> On Friday, November 14, 2014 7:06:56 AM UTC-8, kcrisman wrote:
>>
>>
>>> If person A verbally attacks person B, I still think it does not help to 
>>> show a *disapproving* reaction towards person A, because then A may feel 
>>> attacked, which may make his/her behaviour even worse, and which 
>>> wouldn't help B at all. Instead, I suggest to show a *supporting* 
>>> reaction 
>>> towards person B, in order to make B stronger and prevent damage. 
>>>
>>
>> Yes, that is correct.  Especially in the highly fragmented and 
>> open-to-misinterpretation text-only domain we live in.
>>
>> > Is this a well-known  negative of open source development (resolving
>> > disputes?)  Has it been explored in journals? (I'm not well-read on 
>> whatever
>> > literature there is on open source pro/con  recently.)
>> > RJF
>>
>> rjf, I (once again) *highly* recommend Steven Weber's 
>> http://www.hup.harvard.edu/catalog.php?isbn=9780674018587 "The Success of 
>> Open Source", in particular the chapters on self-governance in open source, 
>> as a place to start reading about this.  
>>
>
> Ironically, Weber's book is itself not free, but is sold for $24.50.   
> Maybe his belief in open whatever does not
> extend to the intellectual property that he himself produces..
Maybe you are confusing scientific literature (published by a
traditional publisher) with religious one?

> Can you provide a link to an open discussion of this matter?
> (while I could perhaps borrow a copy from a library, there are people who 
> might not
> have access to a library copy.  etc.)
>  
>
>> There are also numerous articles in various collections on this issue, but 
>> somewhat surprisingly there is a lot of repetition - the researchers on 
>> this seem to focus on motivation and economic success, or other 
>> socio-economic issues, and less on the socio-political aspect which is just 
>> as important.  There are also several mildly scholarly histories of e.g. 
>> Linux that go in far too much detail about the damage (and the good) that 
>> Torvald's personality does there.  But there is certainly an abundance of 
>> anecdotal stuff regarding this out there, just not often well-organized - 
>> it comes in the midst of other discussions.
>>
> I question the claim made by some people that Linux (the base operating 
> system) is an example of sophisticated programming.  The collection of
> everything that runs on Linux is impossible to assess.
>
>
>> And someone asked about RTM style comments - yes, we do get those, more's 
>> the pity, though Sage is pretty good about such things, largely thanks to 
>> the tone William set very early on.  But there is still some of it, which 
>> is why at least having a non-penalty-based 'honor code' sort of "out there" 
>> could be useful as a place to gently remind people that we're not just 
>> working for the 20-odd people replying to this thread, but for hundreds or 
>> thousands watching.
>>
> If they come in via Google Groups, are they not counted?
>  
>
>>
>> - kcrisman
>>
>

-- 
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: Code of Conduct

[Dima Pasechnik]

On 2014-11-14, Simon King  wrote:
> Hi Travis,
>
> On 2014-11-14, Travis Scrimshaw  wrote:
>>To give a counterpoint to Simon's analogy, we agree that bullying is 
>> bad, but by the rules, we can tell bullies explicitly what their doing is 
>> wrong, why we can't push the bullies down, and explain what will happen if 
>> the behavior escalates. Bullying can get so bad that the teachers need to 
>> step in and enact the correct punishment.
>
> In my experience, it is often the *teachers* who are bullying, in the
> sense that bullying pupils are just the teacher's tools to destroy
> pupils they don't like. But school aside.
sometimes a teacher just doesn't know any better. One famous example is
I.M.Gelfand, who sometimes called his pupils fools in the open...

>
> If person A verbally attacks person B, I still think it does not help to
> show a *disapproving* reaction towards person A, because then A may feel
> attacked, which may make his/her behaviour even worse, and which
> wouldn't help B at all. Instead, I suggest to show a *supporting* reaction
> towards person B, in order to make B stronger and prevent damage.
>
> As it has been said by (IIRC) Jan, it is important that authorities set
> a good example. It may not always help with any individual, but is the
> best way to keep a communicative environment healthy. And concerning those
> individuals for which a good example isn't good enough, I'd prefer to
> see a "don't feed the troll" policy. If person A realises that his/her
> stampede ended in a vacuum, then s/he will usually stop. And if there
> was harm done to B on the way towards the vacuum, then helping B has
> priority over banning A.
>
> 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] Octave interface broken

[Jan Groenewald]

Hi

By default our PPA installation does not have the folders octave and user
in

/usr/lib/sagemath/local/share/sage/ext/octave/user

And /usr/lib/sagemath/local/share/sage/ext/ is owned by root in a
system-wide install. I can add these two folders to the PPA, but would
rather have then added upstream with the correct permissions (755).

If I run

sage: octave('1+1')

as root, the folders get created permission 700 and owned by root. Once I
made them 755, normal users can run octave in sage, and there does not seem
to be any files savedin those folders, they just need to exist. One error
remains though, when exiting sage:


sage: octave('1+2')
 3
sage: r=octave('rand(1)')
sage: r
 0.484611
sage:
Exiting Sage (CPU time 0m0.30s, Wall time 2m43.88s).
Exiting spawned Octave process.
Octave crashed -- automatically restarting.
Octave crashed -- automatically restarting.
0 jan@mangoky:~$logout
Connection to mangoky closed.
0 jan@muizenberg:/var/autofs/misc/home/jan$


(whether run as me or as root I still get this message that octave crashed).

Regards,
Jan




-- 
  .~.
  /V\ Jan Groenewald
 /( )\www.aims.ac.za
 ^^-^^

-- 
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: About recmpilations caused by Git

[Felix Salfelder]

On Mon, Nov 17, 2014 at 05:57:53PM -0800, Andrew wrote:
> When the branch is finally ready for review it has to be merged with the 
> latest development branch, so you can't avoid this indefinitely. As with 
> Nathan, I'm reluctant to continuously switch between versions because of 
> the compile time lag. 

hi there.

some thoughts

- there is no such thing as a 'reviewed' branch. if a review
  corresponded to a merge into 'reviewed', no switching back (to develop?
  master?) would be necessary (in theory..)

- git-new-workdir (part of git) [1] permits multiple work directories on
  top of one repository. this makes multiple builds more efficient, such
  as one for production and one for review.

- aufs [2]. use an overlay for reviewing. afterwards discard it and return
  to the previous state.

hth
felix

[1] -> search engine, tons of resources available.
[2] http://aufs.sourceforge.net

-- 
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.