[sage-devel] Documentation links

[Jeroen Demeyer]

Most of the translations mentioned on http://www.sagemath.org/help.html
are in fact broken links, for example
http://www.sagemath.org/de/html/thematische_anleitungen/index.html


The link to the "Tutorial (Printed & Bound)" is a printed version of the 
Sage-3.4 tutorial from 2009. Is this still relevant?


The link "Constructions (Printed & Bound)" refers to a non-existing 
book, so this should either be fixed or removed (it's probably outdated 
anyway).



Some translations seem to be missing: Sage has Italian, Portuguese and 
Turkish documentation but I cannot find them on the Sage website.


In fact, I think the translations should be mentioned also on
http://www.sagemath.org/doc/index.html.

--
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: VOTE: code of conduct - ends Monday at midnight, PST.

[mmarco]

[X] No -- do not adopt the code of conduct stated below

-- 
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: VOTE: code of conduct - ends Monday at midnight, PST.

[chris wuthrich]

[X ] Yes -- adopt the code of conduct stated below 

-- 
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 (missing dependencies)

[Nathann Cohen]

Hello,

> Realistically, that is not how we operate. Somebody opens a ticket, works on
> it, and then posts the result for review. I have found quite a number of
> random failures on the buildbot (tagged by the random_fail keyword:
> http://trac.sagemath.org/query?keywords=~random_fail) and nobody jumped in
> to fix them for me. That doesn't mean that we live under the dictatorship of
> those who step up to the plate and hammer out a proposal for review.

Trac tickets and comments, however, are public. Thus, among the many
good questions raised by Thierry which deserve an answer, I am also
interested by the answer to the following question:

I consider myself as a Sage developer, i have never heard about this
initiative before. Could you please tell us more about the context, e.g.
 - who is on the short list ?
 - with which motivation ?
 - which concrete examples in mind ?

Thanks for your answer,

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: Sage installation guide and git

[kcrisman]

>
>
> We should for sure mention the git repo on the download-source page 
> too. If I could create a pull request against the download-source web 
> I would. 
>

You can!

https://github.com/sagemath/website/blob/master/src/download-source.html 

-- 
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: Documentation links

[kcrisman]

> Most of the translations mentioned on http://www.sagemath.org/help.html 
> are in fact broken links, for example 
> http://www.sagemath.org/de/html/thematische_anleitungen/index.html 
>
>
> The link to the "Tutorial (Printed & Bound)" is a printed version of the 
> Sage-3.4 tutorial from 2009. Is this still relevant? 
>
> The link "Constructions (Printed & Bound)" refers to a non-existing 
> book, so this should either be fixed or removed (it's probably outdated 
> anyway). 
>
>
> Some translations seem to be missing: Sage has Italian, Portuguese and 
> Turkish documentation but I cannot find them on the Sage website. 
>
> In fact, I think the translations should be mentioned also on 
> http://www.sagemath.org/doc/index.html. 
>


See https://github.com/sagemath/website/ and please help with pull requests 
- Harald is aware of this but it seems like it will be some substantial 
work to fix this, apparently it is due to some reorganization needed 
because of the vm where the doc is hosted?

Also, there is still a constructions document, believe it or not!

-- 
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 (missing dependencies)

[kcrisman]

>
> Trac tickets and comments, however, are public. Thus, among the many 
> good questions raised by Thierry which deserve an answer, I am also 
> interested by the answer to the following question: 
>
> I consider myself as a Sage developer, i have never heard about this 
> initiative before. Could you please tell us more about the context, e.g. 
>  - who is on the short list ? 
>  - with which motivation ? 
>  - which concrete examples in mind ? 
>
>
>
I am also interested in this, and for the record only heard about it when 
the first email came through, but because ANYONE (group or not) could have 
sent such an email at any point, and since it is clear that the community 
can discuss and/or reject it (even before the current voting thread), I was 
not particularly worried about it.

There are in fact hundreds of Sage developers, and most of them do not seem 
to be voting or discussing at all.  

I am glad you brought up a lot of these points.   A brief rejoinder as to 
why I do not see them as particularly bad, *in the current Sage context* 
(important qualifier):

> Establishing such a list is (again) a strong attack against the 
Sage community whose existence relies in openness and diversity: 

I disagree; it seems unwise, but there are many successful and open and 
diverse open source projects who have a "committers list" or something like 
that of people who are allowed to make commits, which is a far stronger 
power; it is the exercise of the power that makes the difference.  To 
paraphrase Stalin, "How many divisions does Sage have"?  Answer: none. 
 Again, I don't think it is wise, but in reality any use of beyond serious 
cases would be 

> With such a perspective, people who organize Sage days and 
tutorial sessions, teach with Sage, report bugs, write books, review 
patches, ask 
> questions, provide support to newcomers, discuss code design, help in 
Sage deployment, maintain the infrastructure, provide buildbots,... are not 
> really useful, not really contributing to Sage's development. This 
is insulting ! 

It seemed to me that this was an attempt to provide some slightly less 
arbitrary measure than "the BDFL and whoever he likes" or "the release 
manager and his friends".  I am pretty sure that there were calls to 
perhaps find a different measure.  Naturally, it is still arbitrary, but in 
the end any such list would be arbitrary, which is why I don't see it as 
necessary or welcome.  But the effort was honest enough, I believe.  It 
could have also been based on posts to sage-devel or changes on Trac or 
reputation on ask.sagemath (my favorite ;-) j/k) but in the end it was just 
a suggestion, and I don't think it went anywhere.  Did it?  This thread is 
VERY long...

> [Edited because this should be a family show]
Because of the linguistic issues you mentioned earlier, perhaps you were 
not aware that the insult you used for the list of names is considered 
fairly vulgar in the United States; I cannot speak to how it is perceived 
by English-speaking communities elsewhere, including those in the sciences 
using English as a lingua franca.  This (and various people doing similar 
things on Trac) may turn off as many people to Sage development by 
'proving' it is unprofessional than any rules here.   I know that there are 
many who would disagree with me on whether "strong language" (whatever that 
means) should be used on sage-devel, or whether asking people to refrain 
even when angry is just censorship, but nonetheless it will also, 
incrementally (differential addition ala Tolstoy, maybe) do so.

Hopefully others will have more cogent discussion of this.  Again, I don't 
think there is any proto-oligarchy forming - for the zillionth time, I will 
recommend reading about governance in open source and why it is so 
different than in other domains - but it's definitely worth discussing.

-- 
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: VOTE: code of conduct - ends Monday at midnight, PST.

[Mike Zabrocki]

[X] Yes -- adopt the code of conduct stated below

-- 
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] Do we have a make target to clean upstream directory?

[Jean-Pierre Flori]

As time goes it gets bigger and bigger...

-- 
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: Do we have a make target to clean upstream directory?

[kcrisman]

> As time goes it gets bigger and bigger...
>

+1 (only if it is documented properly!)
 

-- 
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: VOTE: code of conduct - ends Monday at midnight, PST.

[Franco Saliola]

[X] Yes -- adopt the code of conduct stated below (*)

-- 
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] help with QQbar conversion to complex number

[Ben Hutz]

I'm having trouble with getting a complex approximation to a QQbar number. 
We're working with symmetric polynomials of multipliers of periodic points, 
so the numbers generated are complicated and the failure occurs fairly far 
along in the computation, so the code to generate the error is a little 
complicated. The issue is that I'm getting a 'maximum recursion depth 
error' when trying to get any kind of numerical approximation to the 
number. The code below will produce the error. I've tried looking through 
the qqbar.py file and am having trouble isolating exactly what the issue 
is. If someone knowledgeable about the QQbar/CIF code could give a suggest 
on how to get a numerical approximation of these numbers that would be 
appreciated (working from the start with complex number leads to too much 
error after iteration, and working with the resulting QQbar numbers is too 
slow)

Thanks,
 Ben

A. = AffineSpace(QQ,1)
H = End(A)
f = H([z^2 + 3/4])
n = 6
type = 6

d = f.nth_iterate_map(n)._polys[0].univariate_polynomial().derivative(z)

roots = (f.nth_iterate_map(n)._polys[0].univariate_polynomial() - 
z).univariate_polynomial().roots(QQbar, multiplicities = false)
mult = [d(P) for P in roots]
mult = [mult[k] for k in [0,1,2,3,6,8,9,10,11,18,20,21,42,43]]

v = [0..len(mult)-1]

spv = 0
S = Set(v)
SB = Subsets(S,type)

for subset in SB:
prod = 1
for k in range(0,len(subset)):
prod = prod * mult[subset[k]]
spv = spv + prod
ComplexField(100)(spv)

-- 
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] help with QQbar conversion to complex number

[Vincent Delecroix]

Hi Ben,

You are dealing with complicated numbers, it is not surprising that
things like "exactify" or "__cmp__" lead to maximum recursion errors.
If you want something faster than QQbar you can either:
 - do approximation earlier in the code
 - try to work with number fields

Note that your example can be simplified
{{{
z = polygen(ZZ)
f = z^2 + 3/4
g = f
for _ in range(5): g = f(g)
roots = (g-z).roots(QQbar, multiplicities=False)
}}}

Then instead of applying "d" I would suggest that you do the approximation now
{{{
R = ComplexIntervalField(256)
approx_roots = [r.interval_exact(R) for r in roots]
}}}
and start your computation from there.

By the way, I was not able to go through your example since "type" is
not defined. I tried with type=7 and get quite accurate results (the
diameter was < 10^-43).

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.

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

[Nils Bruin]

On Saturday, November 22, 2014 10:39:37 AM UTC-8, William wrote:
>
> I will start a new thread on sage-devel with a clear title "VOTE: code 
> of conduct", copy of the proposed code, and [ ] Yes/ [ ] No option, 
> and a time limit. 

Good job going for the edge case on the time limit:-) Does your Monday 
midnight come *before* Monday Noon or *after*?
That's why deadlines are usually at 23:59 or 0:01.

(as long as we don't get a large swath of "no" votes before the second 
Monday Midnight it doesn't affect the outcome luckily. Plus, I think most 
authoritative timekeeping sources will define midnight (being 0:00) coming 
before noon (being 12:00) of the same day, so the vote has closed already)

-- 
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 (missing dependencies)

[Thierry]

Hi,

On 24/11/2014 15:06, kcrisman wrote:
> It seemed to me that this was an attempt to provide some slightly less
> arbitrary measure than "the BDFL and whoever he likes" or "the release
> manager and his friends". I am pretty sure that there were calls to
> perhaps find a different measure. Naturally, it is still arbitrary, but
> in the end any such list would be arbitrary, which is why I don't see it
> as necessary or welcome. But the effort was honest enough, I believe. 

OK. From that perspective, it is better than worse. The Sage community
still deserves far better.

> It could have also been based on posts to sage-devel or changes on Trac
> or reputation on ask.sagemath (my favorite ;-) j/k) but in the end it
> was just a suggestion, and I don't think it went anywhere.  Did it?
> This thread is VERY long...

As for me, any such ranking is wrong, by its hierarchical essence.
"Objective ranking" does not means anything, the choice of criteria will
only reflect the well-established point of view. This does not fosters
diversity, since what is different does not score within the ranking. This
creates spam (e.g. going back and forth within dirty commits, use loops
instead of list comprehensions, taking even more place on sage-devel to
keep one's dominant position, and so on).

Let me tell a story. A vetcor of plague is a small jumping insect (flea)
that lives on rats (resp. squirrel in America) skin. Killing rats is an
efficient way to fight plague. During the plague epidemies of the previous
century, there has been sometimes a bounty offered for killing rats, the
population was paid by local government to bring dead rats. This makes
sense. Guess what ? The population grew rats ! Once a measurement becomes
an objective, it is no longer a measurement. We can see this phenomenon
with bibliometry, let us not let enter this into Sage.


>> [Edited because this should be a family show]
> Because of the linguistic issues you mentioned earlier, perhaps you were
> not aware that the insult you used for the list of names is considered
> fairly vulgar in the United States; I cannot speak to how it is
> perceived by English-speaking communities elsewhere, including those in
> the sciences using English as a lingua franca.  This (and various people
> doing similar things on Trac) may turn off as many people to Sage
> development by 'proving' it is unprofessional than any rules here.   I
> know that there are many who would disagree with me on whether "strong
> language" (whatever that means) should be used on sage-devel, or whether
> asking people to refrain even when angry is just censorship, but
> nonetheless it will also, incrementally (differential addition ala
> Tolstoy, maybe) do so.

I am sorry if you felt shocked, and i apologize for that. If "penis" is an
acceptable word, it works exactly the same in this case.

This sentence was not meant as an insult toward members of the list (they
did not chose to be here), i was just pointing the patriarchal nature of
such a ranking (not the people). The fact that no women appear in this
list is not random (btw, this is not better on ask.sagemath, nor
sage-devel). This list is related to power, normalization and domination ;
i can of course not speak for women, let me at least be sarchastic about
patriarchy. Size of code does not matter.

> Hopefully others will have more cogent discussion of this. Again, I
> don't think there is any proto-oligarchy forming - for the zillionth
> time, I will recommend reading about governance in open source and why
> it is so different than in other domains - but it's definitely worth
> discussing.

Of course this should be discussed, and this was the point of the "missing
dependencies" subject ! What could be said about governance models in free
software ? Perhaps just noticing that, according to flosspols 2006 study,
while there are 28% of women in proprietary software development (which
bias may be explained by the societal picture you rightly mentionned in a
previous post), they are only 1.5% in free software development (6% is the
highest estimation i found on the web), this difference can not be found
on societal picture, but within our developments models. So, while
learning about existing governance models is necessary, we have to find
our way.

Having a look to the Sage developper map may be pretty depressing at this
point :(

Ciao,
Thierry







On Mon, Nov 24, 2014 at 06:06:56AM -0800, kcrisman wrote:
> 
> >
> > Trac tickets and comments, however, are public. Thus, among the many 
> > good questions raised by Thierry which deserve an answer, I am also 
> > interested by the answer to the following question: 
> >
> > I consider myself as a Sage developer, i have never heard about this 
> > initiative before. Could you please tell us more about the context, e.g. 
> >  - who is on the short list ? 
> >  - with which motivation ? 
> >  - which concrete examples in mind ? 
> >
> >
> >
> I am also interested in this, and for the 

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

[William Stein]

I mean the time that is just over 12 hours from now...

- William Stein (cell phone)
On Nov 24, 2014 11:36 AM, "Nils Bruin"  wrote:

> On Saturday, November 22, 2014 10:39:37 AM UTC-8, William wrote:
>>
>> I will start a new thread on sage-devel with a clear title "VOTE: code
>> of conduct", copy of the proposed code, and [ ] Yes/ [ ] No option,
>> and a time limit.
>
> Good job going for the edge case on the time limit:-) Does your Monday
> midnight come *before* Monday Noon or *after*?
> That's why deadlines are usually at 23:59 or 0:01.
>
> (as long as we don't get a large swath of "no" votes before the second
> Monday Midnight it doesn't affect the outcome luckily. Plus, I think most
> authoritative timekeeping sources will define midnight (being 0:00) coming
> before noon (being 12:00) of the same day, so the vote has closed already)
>
> --
> 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] help with QQbar conversion to complex number

[Ben Hutz]

Thanks Vincent. I can give that a try. We did try to approximate earlier 
with CC and the errors were compounding too much (we do a bunch more stuff 
after this), but maybe approximating the roots with CIF will do a better 
job.

It sounds like the recursion depth error is actually expected for numbers 
like this,

(btw, type is defined in the example as 6, but it doesn't really matter)

On Monday, November 24, 2014 1:55:05 PM UTC-5, vdelecroix wrote:
>
> Hi Ben, 
>
> You are dealing with complicated numbers, it is not surprising that 
> things like "exactify" or "__cmp__" lead to maximum recursion errors. 
> If you want something faster than QQbar you can either: 
>  - do approximation earlier in the code 
>  - try to work with number fields 
>
> Note that your example can be simplified 
> {{{ 
> z = polygen(ZZ) 
> f = z^2 + 3/4 
> g = f 
> for _ in range(5): g = f(g) 
> roots = (g-z).roots(QQbar, multiplicities=False) 
> }}} 
>
> Then instead of applying "d" I would suggest that you do the approximation 
> now 
> {{{ 
> R = ComplexIntervalField(256) 
> approx_roots = [r.interval_exact(R) for r in roots] 
> }}} 
> and start your computation from there. 
>
> By the way, I was not able to go through your example since "type" is 
> not defined. I tried with type=7 and get quite accurate results (the 
> diameter was < 10^-43). 
>
> 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.

Re: [sage-devel] help with QQbar conversion to complex number

[Jonas Jermann]

Hi

In particular: Try .simplify()!

In my case that produced an improvement factor >1000 in some cases.

Best
Jonas

On 24.11.2014 20:54, Ben Hutz wrote:

Thanks Vincent. I can give that a try. We did try to approximate earlier
with CC and the errors were compounding too much (we do a bunch more
stuff after this), but maybe approximating the roots with CIF will do a
better job.

It sounds like the recursion depth error is actually expected for
numbers like this,

(btw, type is defined in the example as 6, but it doesn't really matter)

On Monday, November 24, 2014 1:55:05 PM UTC-5, vdelecroix wrote:

Hi Ben,

You are dealing with complicated numbers, it is not surprising that
things like "exactify" or "__cmp__" lead to maximum recursion errors.
If you want something faster than QQbar you can either:
  - do approximation earlier in the code
  - try to work with number fields

Note that your example can be simplified
{{{
z = polygen(ZZ)
f = z^2 + 3/4
g = f
for _ in range(5): g = f(g)
roots = (g-z).roots(QQbar, multiplicities=False)
}}}

Then instead of applying "d" I would suggest that you do the
approximation now
{{{
R = ComplexIntervalField(256)
approx_roots = [r.interval_exact(R) for r in roots]
}}}
and start your computation from there.

By the way, I was not able to go through your example since "type" is
not defined. I tried with type=7 and get quite accurate results (the
diameter was < 10^-43).

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.


--
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 22 November 2014 at 12:34, Ondřej Čertík  wrote:
> On Sat, Nov 22, 2014 at 7:23 AM, Bill Page  wrote:
>> ...
>> FriCAS currently does not implement a symbolic 'conjugate' operator.
>> The issue concerns whether adding 'conjugate' is a good idea and only
>> secondly how to differentiate it.
>
> Ah, I had no idea that FriCAS does not implement conjugate(x).
> How do you handle complex numbers then?

Sorry, I gave you the wrong impression. I specifically referred to the
lack of "symbolic 'conjugate operator".  By that I meant that the
'Expression' functor does not export a 'conjugate' operator.  My patch
adds such an operator to Expression.  But FriCAS has many domains of
computation besides those constructed by 'Expression' and some of them
do include 'conjugate'. For example the 'Complex' functor includes
'conjugate' so we can write:

(1) -> x:Complex Expression Integer := a + %i*b

   (1)  a + b %i
   Type: Complex(Expression(Integer))
(2) -> conjugate(x)

   (2)  a - b %i
   Type: Complex(Expression(Integer))

This effectively and implicitly treats symbols as real valued.

(3) -> D(x,a)

   (3)  1
   Type: Complex(Expression(Integer))
(4) -> D(x,b)

   (4)  %i
   Type: Complex(Expression(Integer))
(5) -> y:=log(x)

 22
log(b  + a )b
   (5)   + 2atan(--)%i
  2   +---+
  | 22
 \|b  + a   + a
   Type: Complex(Expression(Integer))
(6) -> conjugate(y)

 22
log(b  + a )b
   (6)   - 2atan(--)%i
  2   +---+
  | 22
 \|b  + a   + a
   Type: Complex(Expression(Integer))

But not this:

(7) -> D(y,x)
...
   Cannot find a definition or applicable library operation named D
  with argument type(s)
Complex(Expression(Integer))
Complex(Expression(Integer))

So there is no "complex derivative" as such.

We can also define things this way:

(8) -> z:Expression Complex Integer := a + %i*b

   (8)  %i b + a
   Type: Expression(Complex(Integer))
(9) -> D(z,a)

   (9)  1
   Type: Expression(Complex(Integer))
(10) -> D(z,b)

   (10)  %i
   Type: Expression(Complex(Integer))
(11) -> w:=log(z)

   (11)  log(%i b + a)
   Type: Expression(Complex(Integer))

But now we get:

(12) -> conjugate(z)
 ...
   Cannot find a definition or applicable library operation named
  conjugate with argument type(s)
Expression(Complex(Integer))

  Perhaps you should use "@" to indicate the required return type,
  or "$" to specify which version of the function you need.

(13) -> D(w,z)
...
   Cannot find a definition or applicable library operation named D
  with argument type(s)
Expression(Complex(Integer))
Expression(Complex(Integer))

The FriCAS 'Expression' functor extends multivariate rational
functions over a specified domain with a large number of
transcendental kernels (symbolic functions) as well as differentiation
and integration operators.  No explicit assumption is made about the
domain of the variables.  My proposed patch to FriCAS adds 'conjugate'
as another kernel function and provides a 'conjugate' as an operator.

> In SymPy and Sage, conjugate(x) is in it, so then adding a derivative
> of abs(x) does not make things worse.
>

In FriCAS 'abs' is already a kernel function and it implemented the
derivative of 'abs' even before my proposed patch but I think the
current definition is wrong:

(14) -> D(abs(x),x)

 abs(x)
   (14)  --
x
Type: Expression(Integer)


>>
>> In FriCAS with my patch functions defined by
>>
>>   f := operator 'f
>>
>> are currently assume to be holomorphic and log is holomorphic by definition 
>> so
>>
>> conjugate(log(x)) = log(conjugate(x))
>>
>> Perhaps you are considering the wrong branch.
>> ...
>> Complex 'log' is a multi-valued like 'sqrt' so you need to consider
>> more than one branch.
>
> Well, you are right that in theory you define log(z) as
> log(z)=log|z|+i*arg(z), and you define arg(z) as multivalued,
> i.e. you can add 2*pi*n to it, then you can add 2*pi*i*n to log(z).
> Since [6] and [7] differs by 2*pi*i, they are indeed the same number.

I would not say that they are the same "number".  Also I don't want to
define log(z) the way to suggest.  Rather, I think the correct
definition of 'log(z)'

[sage-devel] Re: VOTE: code of conduct - ends Monday at midnight, PST.

[Vincent Knight]

[X] Yes -- adopt the code of conduct stated below (*) 

Thanks,
Vince

-- 
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] help with QQbar conversion to complex number

[Ben Hutz]

hmm...one more question here then I'll stop, as this is turning into more 
like a sage-support discussion as opposed to sage-devel.

This does seem to be doing a good job with high enough precision specified. 
What is the best way to compare two such interval numbers? The multipliers 
(after applying d) will have a bunch of repeat values, but there will be 
some minor precision differences. We need to remove those duplicates.

On Monday, November 24, 2014 2:54:24 PM UTC-5, Ben Hutz wrote:
>
> Thanks Vincent. I can give that a try. We did try to approximate earlier 
> with CC and the errors were compounding too much (we do a bunch more stuff 
> after this), but maybe approximating the roots with CIF will do a better 
> job.
>
> It sounds like the recursion depth error is actually expected for numbers 
> like this,
>
> (btw, type is defined in the example as 6, but it doesn't really matter)
>
> On Monday, November 24, 2014 1:55:05 PM UTC-5, vdelecroix wrote:
>>
>> Hi Ben, 
>>
>> You are dealing with complicated numbers, it is not surprising that 
>> things like "exactify" or "__cmp__" lead to maximum recursion errors. 
>> If you want something faster than QQbar you can either: 
>>  - do approximation earlier in the code 
>>  - try to work with number fields 
>>
>> Note that your example can be simplified 
>> {{{ 
>> z = polygen(ZZ) 
>> f = z^2 + 3/4 
>> g = f 
>> for _ in range(5): g = f(g) 
>> roots = (g-z).roots(QQbar, multiplicities=False) 
>> }}} 
>>
>> Then instead of applying "d" I would suggest that you do the 
>> approximation now 
>> {{{ 
>> R = ComplexIntervalField(256) 
>> approx_roots = [r.interval_exact(R) for r in roots] 
>> }}} 
>> and start your computation from there. 
>>
>> By the way, I was not able to go through your example since "type" is 
>> not defined. I tried with type=7 and get quite accurate results (the 
>> diameter was < 10^-43). 
>>
>> 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: VOTE: code of conduct - ends Monday at midnight, PST.

[Ursula Whitcher]

[x ] Yes -- adopt the code of conduct stated below (*)

UAW

-- 
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] VOTE: code of conduct - ends Monday at midnight, PST.

[Don Winsor]

[ X] Yes -- adopt the code of conduct stated below (*)
-- Don Winsor


On Sat, Nov 22, 2014 at 7:47 PM, William Stein  wrote:

> Hello Sage Developers,
>
> This is a simple majority vote for the original proposed code of
> conduct.  I will close voting on Monday at midnight PST.  (If the vote
> is an exact tie, then that means "No" - there must be a simple
> majority for this to pass.)   Any member of the sage-devel mailing
> list may vote or abstain.I will delete any messages in this thread
> that is not a vote -- if you want to make further arguments for or
> against, do so elsewhere.
>
> [ ] Yes -- adopt the code of conduct stated below (*)
>
> [ ] No -- do not adopt the code of conduct stated below
>
> Thanks!   Note, I am not going to vote either way, but I will strongly
> support whatever the community decides.
>
> Code of Conduct
> ---
>
> The Sage community is comprised of an international mixture of
> mathematicians, computer scientists, engineers, researchers, teachers,
> amateurs, and others with varied backgrounds. This diversity is one of
> our strengths, but it can also lead to communication problems and
> unhappiness. People who love working on Sage can more effectively
> collaborate with others if they follow this code.
>
> If you believe someone is violating the code of conduct, we ask that
> you report it by emailing sage-ab...@googlegroups.com. The group
> administrators will consider the issue and explore resolutions. [See
> note below.] It is also possible to move heated discussions to the
> mailing list sage-fl...@googlegroups.com.
>
> 1)   Be friendly and patient.
>
> 2)   Be welcoming. We strive to be a community that welcomes and
> supports people of all backgrounds and identities.
>
> 3)   Be considerate. Your work will be used by other people and you in
> turn will depend on the work of others. Any decision you take will
> affect users and developers, so you should take those consequences
> into account when making decisions. Conversely, Sage is constantly
> evolving, and earlier decisions that were made in good faith may
> sometimes need to be reconsidered. Nonetheless, we should still
> appreciate the hard work done in the past.
>
> 4)   Be respectful and polite. Not all of us will agree all the time,
> but disagreement is no excuse for poor behavior and poor manners. We
> might all experience some frustration now and then, but we cannot
> allow that frustration to morph into personal attacks. It is important
> to remember that a community where people feel uncomfortable or
> threatened is not a productive one. Members of the Sage community
> should be respectful when dealing with other developers and users.
>
> When we disagree, we should try to understand why. Disagreements, both
> social and technical, happen all the time. It is important that we
> resolve disagreements and differing views constructively. Being unable
> to understand why someone holds a viewpoint does not mean that they
> are wrong. Do not forget that it is human to err. Blame alone gets us
> nowhere, it is better to help resolve issues so we can all learn from
> our mistakes.
>
> ---
>
> NOTE: There were questions on the list about who exactly would deal
> with sage-abuse complaints and how.  If you do not trust that we Sage
> developers can responsibly select people to be on that list, and that
> those members can find ways to sort out issues on a case-by-case
> basis, then you may vote "no" to this proposal.We are mostly not
> lawyers or politicians and are not going to make things more precise
> in this code regarding composition of the group or specific sanctions.
>
> --
> 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 Mon, Nov 24, 2014 at 1:57 PM, Bill Page  wrote:
> On 22 November 2014 at 12:34, Ondřej Čertík  wrote:
>> On Sat, Nov 22, 2014 at 7:23 AM, Bill Page  
>> wrote:
>>> ...
>>> FriCAS currently does not implement a symbolic 'conjugate' operator.
>>> The issue concerns whether adding 'conjugate' is a good idea and only
>>> secondly how to differentiate it.
>>
>> Ah, I had no idea that FriCAS does not implement conjugate(x).
>> How do you handle complex numbers then?
>
> Sorry, I gave you the wrong impression. I specifically referred to the
> lack of "symbolic 'conjugate operator".  By that I meant that the
> 'Expression' functor does not export a 'conjugate' operator.  My patch
> adds such an operator to Expression.  But FriCAS has many domains of
> computation besides those constructed by 'Expression' and some of them
> do include 'conjugate'. For example the 'Complex' functor includes
> 'conjugate' so we can write:
>
> (1) -> x:Complex Expression Integer := a + %i*b
>
>(1)  a + b %i
>Type: Complex(Expression(Integer))
> (2) -> conjugate(x)
>
>(2)  a - b %i
>Type: Complex(Expression(Integer))
>
> This effectively and implicitly treats symbols as real valued.
>
> (3) -> D(x,a)
>
>(3)  1
>Type: Complex(Expression(Integer))
> (4) -> D(x,b)
>
>(4)  %i
>Type: Complex(Expression(Integer))
> (5) -> y:=log(x)
>
>  22
> log(b  + a )b
>(5)   + 2atan(--)%i
>   2   +---+
>   | 22
>  \|b  + a   + a
>Type: Complex(Expression(Integer))
> (6) -> conjugate(y)
>
>  22
> log(b  + a )b
>(6)   - 2atan(--)%i
>   2   +---+
>   | 22
>  \|b  + a   + a
>Type: Complex(Expression(Integer))
>
> But not this:
>
> (7) -> D(y,x)
> ...
>Cannot find a definition or applicable library operation named D
>   with argument type(s)
> Complex(Expression(Integer))
> Complex(Expression(Integer))
>
> So there is no "complex derivative" as such.
>
> We can also define things this way:
>
> (8) -> z:Expression Complex Integer := a + %i*b
>
>(8)  %i b + a
>Type: Expression(Complex(Integer))
> (9) -> D(z,a)
>
>(9)  1
>Type: Expression(Complex(Integer))
> (10) -> D(z,b)
>
>(10)  %i
>Type: Expression(Complex(Integer))
> (11) -> w:=log(z)
>
>(11)  log(%i b + a)
>Type: Expression(Complex(Integer))
>
> But now we get:
>
> (12) -> conjugate(z)
>  ...
>Cannot find a definition or applicable library operation named
>   conjugate with argument type(s)
> Expression(Complex(Integer))
>
>   Perhaps you should use "@" to indicate the required return type,
>   or "$" to specify which version of the function you need.
>
> (13) -> D(w,z)
> ...
>Cannot find a definition or applicable library operation named D
>   with argument type(s)
> Expression(Complex(Integer))
> Expression(Complex(Integer))
>
> The FriCAS 'Expression' functor extends multivariate rational
> functions over a specified domain with a large number of
> transcendental kernels (symbolic functions) as well as differentiation
> and integration operators.  No explicit assumption is made about the
> domain of the variables.  My proposed patch to FriCAS adds 'conjugate'
> as another kernel function and provides a 'conjugate' as an operator.

Ok, thanks for the clarification.

>
>> In SymPy and Sage, conjugate(x) is in it, so then adding a derivative
>> of abs(x) does not make things worse.
>>
>
> In FriCAS 'abs' is already a kernel function and it implemented the
> derivative of 'abs' even before my proposed patch but I think the
> current definition is wrong:
>
> (14) -> D(abs(x),x)
>
>  abs(x)
>(14)  --
> x
> Type: Expression(Integer)

I think that's correct for real numbers, i.e. x/abs(x) = abs(x) / x.

>
>
>>>
>>> In FriCAS with my patch functions defined by
>>>
>>>   f := operator 'f
>>>
>>> are currently assume to be holomorphic and log is holomorphic by definition 
>>> so
>>>
>>> conjugate(log(x)) = log(conjugate(x))
>>>
>>> Perhaps you are considering the wrong branch.
>>> ...
>>> Complex 'log' is a multi-valued like 'sqrt' so you need to consider
>>> more than one branch.
>>
>> Well, you are right that in 

Re: [sage-devel] Code of Conduct (missing dependencies)

[Thierry]

> > [Edited because this should be a family show]

I was trying to be sarcastic and make visible a risk for machismo or
androcracy that could follow from establishing some kind of competition
within the community.

I realize that the way i wrote those two lines somehow strengthen such
theses. I am not good in this register, and i am sorry for this sentence
(which was not even my point).

I sincerely want to apologize for this.

Ciao,
Thierry


-- 
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: Documentation links

[Harald Schilly]

On Monday, November 24, 2014 10:22:24 AM UTC+1, Jeroen Demeyer wrote:
>
> In fact, I think the translations should be mentioned also on 
> http://www.sagemath.org/doc/index.html. 
>

I agree that external links to dead pages should go away. It piles up. I 
don't want to judge on relevancy, too.

However, fixing internal links should be easy. I've started to fix some 
links, but there is a long-standing bad situation. I agree that those 
translations should be mentioned, but the /doc page points immediately to 
the english translation. That dates back to times when there was just "en". 
I don't want to break the bookmarks of everyone, that's why /doc doesn't 
simply point to the directory listing, which is here:
http://www.sagemath.org/doc-html/

Ideas are welcome ;-)

-- 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: Documentation links

[David Roe]

On Mon, Nov 24, 2014 at 3:12 PM, Harald Schilly
 wrote:
>
>
> On Monday, November 24, 2014 10:22:24 AM UTC+1, Jeroen Demeyer wrote:
>>
>> In fact, I think the translations should be mentioned also on
>> http://www.sagemath.org/doc/index.html.
>
>
> I agree that external links to dead pages should go away. It piles up. I
> don't want to judge on relevancy, too.
>
> However, fixing internal links should be easy. I've started to fix some
> links, but there is a long-standing bad situation. I agree that those
> translations should be mentioned, but the /doc page points immediately to
> the english translation. That dates back to times when there was just "en".
> I don't want to break the bookmarks of everyone, that's why /doc doesn't
> simply point to the directory listing, which is here:
> http://www.sagemath.org/doc-html/
>
> Ideas are welcome ;-)

A documentation page with language tabs, that defaults to English?
David
>
> -- 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.

-- 
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: VOTE: code of conduct - ends Monday at midnight, PST.

[john_perry_usm]

[ X ] No -- do not adopt the code of conduct stated below

-- 
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 (missing dependencies)

[kcrisman]

> > > [Edited because this should be a family show] 
>
> I was trying to be sarcastic and make visible a risk for machismo or 
> androcracy that could follow from establishing some kind of competition 
> within the community. 
>
> I realize that the way i wrote those two lines somehow strengthen such 
> theses. I am not good in this register, and i am sorry for this sentence 
> (which was not even my point). 
>
> I sincerely want to apologize for this. 
>

No worries - I'm sure I watch more on this front and less on other 
potential flash points than I should, and of course many on this list won't 
care either way.  As you say, it was not at all the main point!   The risk 
for machismo etc. is definitely a real problem - to my eyes, more than 
simply not having a 50-50 ratio for sage-devel posts.  In fact, I think the 
proposal is partly intended to make it easier to call out evident events of 
that nature.

-- 
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: Documentation links

[kcrisman]

>
> > Ideas are welcome ;-) 
>
> A documentation page with language tabs, that defaults to English? 
>
>
Possible, but Harald might want some help then. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Code of Conduct (missing dependencies)

[Nathann Cohen]

Hello guys,

Once more, the rules make a point to enforce politeness but they seem
to avoid things like having the respect to answer a honest question.

Could we thus have an answer to the ones aked by Therry ? Not ignoring
anybody is also part of elementary "friendliness".

Nathann


On 25 November 2014 at 06:50, kcrisman  wrote:
>
>> > > [Edited because this should be a family show]
>>
>> I was trying to be sarcastic and make visible a risk for machismo or
>> androcracy that could follow from establishing some kind of competition
>> within the community.
>>
>> I realize that the way i wrote those two lines somehow strengthen such
>> theses. I am not good in this register, and i am sorry for this sentence
>> (which was not even my point).
>>
>> I sincerely want to apologize for this.
>
>
> No worries - I'm sure I watch more on this front and less on other potential
> flash points than I should, and of course many on this list won't care
> either way.  As you say, it was not at all the main point!   The risk for
> machismo etc. is definitely a real problem - to my eyes, more than simply
> not having a 50-50 ratio for sage-devel posts.  In fact, I think the
> proposal is partly intended to make it easier to call out evident events of
> that nature.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/iGxa2F01rFc/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Decision making (refuse to vote)

[Thierry]

Hi again,

I have serious concerns with the current situation.

What is wrong with the current call for vote ?


Let me summarize the situation : 

- An obscure group of self-appointed people wrote a text, they had the
  possibility to discuss and amend its content, with an unlimited amount
  of time. The estimated entropy of the text is larger than 1.

- This text can not be modified by the community and is submitted as is
  for a majority vote. Those that do not belong to the obscure group
  (which is still anonymous after various requests) can therefore only
  contribute 1/n bits, where n is the number of voters. They have less
  than two days to answer.


My point of view about this :

- This is paternalistic because it means that the community as a whole is
  not able to work together and write anything good. This looks also
  useless (or dangerous?) to take more time and let people think and
  exchange about this.

- This contradicts the contents of the text which claims about
  collaboration and respect, however it is not how the obscure group
  behaves. Hence, i doubt that the text will be used in other way than for
  repression.

- This is in complete contradiction with Sage community habits. Let me
  give an example: when someone writes some code, anyone can help during
  the review process. If one of the reviewers thinks something can be
  improved, it is discussed on trac, modifications are made until 
  everyone agree. We are all pointing toward a common goal. Discussing
  some big issues on sage-devel is a way to involve more people in
  important design discussions and mix more ideas together, it is not a
  way to enforce the approval by a majority vote.


There are strong issues with majority voting :

- A call for vote aims at closing a discussion. However, if there is an
  issue somewhere, the only way to reach a stable solution is precisely to
  let the discussion open until enough content is added into it and try to
  merge good ideas and objections. Regarding the current proposition, some
  objections were emitted by various people.

- Launching such a vote creates a division within the community, whatever
  the outcome, between those who belong to the "majority" and the others.
  This will result in oppression: the minority will have to behave
  according to what the majority decided.

- It is easy to raise an army of voters, especially on a public
  mailing-list. It can be as innocent as sending e-mails to people that
  are likely to agree with you and say "there is a vote going on, you
  should read it and make your own opinion".

- This is unlikely to attract future developers with diverse and original
  points of view and autonomous thinking.

- If the text is voted, the minority will have to conform to a text they
  could not even discuss. This is even more serious that the text is about
  individual behaviour. Was there with a particular minority in mind ?


Choosing among ideas or mixing them ? Competition or Collaboration ? Fight
or Solidarity ?

This e-mail is not ended, i encourage you to read and think about
"majority voting" and "consensus decision making".

We have a serious communication issue, and we need to discuss it, without
deadline. Following the previous thread, Vincent opened a page for this on
the wiki.

Ciao,
Thierry

-- 
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] VOTE: code of conduct - ends Monday at midnight, PST.

[Thierry]

NO !

I can not participate to this, this call for vote is both paternalistic
and violent.

Since i can not explain why here, please read more details at:
https://groups.google.com/forum/?fromgroups#!topic/sage-devel/PjU2YQn3ca4

Ciao,
Thierry


On Sat, Nov 22, 2014 at 04:47:33PM -0800, William Stein wrote:
> Hello Sage Developers,
> 
> This is a simple majority vote for the original proposed code of
> conduct.  I will close voting on Monday at midnight PST.  (If the vote
> is an exact tie, then that means "No" - there must be a simple
> majority for this to pass.)   Any member of the sage-devel mailing
> list may vote or abstain.I will delete any messages in this thread
> that is not a vote -- if you want to make further arguments for or
> against, do so elsewhere.
> 
> [ ] Yes -- adopt the code of conduct stated below (*)
> 
> [ ] No -- do not adopt the code of conduct stated below
> 
> Thanks!   Note, I am not going to vote either way, but I will strongly
> support whatever the community decides.
> 
> Code of Conduct
> ---
> 
> The Sage community is comprised of an international mixture of
> mathematicians, computer scientists, engineers, researchers, teachers,
> amateurs, and others with varied backgrounds. This diversity is one of
> our strengths, but it can also lead to communication problems and
> unhappiness. People who love working on Sage can more effectively
> collaborate with others if they follow this code.
> 
> If you believe someone is violating the code of conduct, we ask that
> you report it by emailing sage-ab...@googlegroups.com. The group
> administrators will consider the issue and explore resolutions. [See
> note below.] It is also possible to move heated discussions to the
> mailing list sage-fl...@googlegroups.com.
> 
> 1)   Be friendly and patient.
> 
> 2)   Be welcoming. We strive to be a community that welcomes and
> supports people of all backgrounds and identities.
> 
> 3)   Be considerate. Your work will be used by other people and you in
> turn will depend on the work of others. Any decision you take will
> affect users and developers, so you should take those consequences
> into account when making decisions. Conversely, Sage is constantly
> evolving, and earlier decisions that were made in good faith may
> sometimes need to be reconsidered. Nonetheless, we should still
> appreciate the hard work done in the past.
> 
> 4)   Be respectful and polite. Not all of us will agree all the time,
> but disagreement is no excuse for poor behavior and poor manners. We
> might all experience some frustration now and then, but we cannot
> allow that frustration to morph into personal attacks. It is important
> to remember that a community where people feel uncomfortable or
> threatened is not a productive one. Members of the Sage community
> should be respectful when dealing with other developers and users.
> 
> When we disagree, we should try to understand why. Disagreements, both
> social and technical, happen all the time. It is important that we
> resolve disagreements and differing views constructively. Being unable
> to understand why someone holds a viewpoint does not mean that they
> are wrong. Do not forget that it is human to err. Blame alone gets us
> nowhere, it is better to help resolve issues so we can all learn from
> our mistakes.
> 
> ---
> 
> NOTE: There were questions on the list about who exactly would deal
> with sage-abuse complaints and how.  If you do not trust that we Sage
> developers can responsibly select people to be on that list, and that
> those members can find ways to sort out issues on a case-by-case
> basis, then you may vote "no" to this proposal.We are mostly not
> lawyers or politicians and are not going to make things more precise
> in this code regarding composition of the group or specific sanctions.
> 
> -- 
> 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: Building Sage-6.4 Python module pynac-0.3.2

[kksurendran]

That's right. I was building in /usr/local as sudo. I used to always do 
that. And did upgrade to 6.2 which was running fine.

Now, I had a doubt about some strange way why this package alone was 
behaving so. Because distutils is part of the python distribution. And 
finding python and missing distutils!

So, I did $make in my home directory and it did find distutils. 
$sage
sage:notebook()
The notebook files are stored in: sage_notebook.sagenb
┌┐
││
│ Open your web browser to http://localhost:8080 │
││
└┘
Executing twistd  --pidfile="sage_notebook.sagenb/sagenb.pid" -ny 
"sage_notebook.sagenb/twistedconf.tac"
/usr/local/sage-6.4/local/lib/python2.7/site-packages/Crypto/Util/number.py:57: 
PowmInsecureWarning: Not using mpz_powm_sec.  You should rebuild using 
libgmp >= 5 to avoid timing attack vulnerability.
  _warn("Not using mpz_powm_sec.  You should rebuild using libgmp >= 5 to 
avoid timing attack vulnerability.", PowmInsecureWarning)

I suppose that is not a serious error.

But I had to copy/move 8.8GB to /usr/local where I have sage versions. I 
did not think  this is a very good thing to do. Moreover, an open-source 
software which does not take advantage of the libraries of open-source OS 
and creating a bulky tree is not consistent with the philosophy of open 
source computing. I have attached the file created after running the command

$ diff /usr/local/sage-6.4/local/lib/python2.7 /usr/lib/python2.7 > 
python2.7vsPython2.7

Best regards & thanks.
A typical installation of MATLAB takes 3-4 GB
Mathematica10 in Ubuntu 12-14  takes 8.8GB
MAPLE 18 in Ubuntu 12 takes 2GB 


On Saturday, 22 November 2014 23:58:25 UTC-5, John H Palmieri wrote:
>
> Looking at the log file, the error is actually
>
>sys:1: RuntimeWarning: not adding directory '' to sys.path since it's 
> writable by an untrusted group.
>Untrusted users could put files in this directory which might then be 
> imported by your Python code. As a general precaution from similar 
> exploits, you should not execute Python code from this directory
>
> Maybe you're trying to build as root? I don't think that will work.
>
>
>
> On Saturday, November 22, 2014 8:55:07 PM UTC-8, John H Palmieri wrote:
>>
>> The files in /usr/lib/python2.7 are not relevant. What is in the 
>> local/lib/python directory of the Sage installation? There should be a 
>> docutils directory there.
>>
>>
>> On Saturday, November 22, 2014 8:21:29 PM UTC-8, kksurendran wrote:
>>>
>>> Compilation of sage-6.4.tar.gz resulted in the error attached.
>>>
>>> On going to the subshell after executing
>>>
>>> $  cd '/usr/local/sage-6.4/local/var/tmp/sage/build/pynac-0.3.2' && 
>>> '/usr/local/sage-6.4/sage' --sh
>>>
>>> One can configure and make in the pynac-0.3.2/src directory provided one 
>>> runs the command
>>>
>>> subshell> autoreconf -i --force
>>>
>>> as advised by the source.
>>>
>>> However on returning to the main /usr/local/sage-6.4, 
>>>
>>> $ make
>>>
>>> removes all that from the pynac directory by the default behaviour of 
>>> make in sage.and the same error is reproduced!
>>>
>>> The error originates from :
>>>
>>>
>>> *checking for the distutils Python package... no   configure: error: 
>>> cannot import Python module "distutils".  * 
>>>
>>> However,
>>> $ ls -la /usr/lib/python2.7/distutils
>>> surendran@angeli-acer:/usr/local/sage-6.4$ ls -la 
>>> /usr/lib/python2.7/distutils
>>> total 812
>>> drwxr-xr-x  3 root root  4096 Apr 24  2014 .
>>> drwxr-xr-x 26 root root 24576 Apr 24  2014 ..
>>> -rw-r--r--  1 root root  7822 Mar 22  2014 archive_util.py
>>> -rw-r--r--  1 root root  7440 Apr 24  2014 archive_util.pyc
>>> -rw-r--r--  1 root root 14941 Mar 22  2014 bcppcompiler.py
>>> -rw-r--r--  1 root root  7864 Apr 24  2014 bcppcompiler.pyc
>>> -rw-r--r--  1 root root 46633 Mar 22  2014 ccompiler.py
>>> -rw-r--r--  1 root root 36714 Apr 24  2014 ccompiler.pyc
>>> -rw-r--r--  1 root root 19270 Mar 22  2014 cmd.py
>>> -rw-r--r--  1 root root 16730 Apr 24  2014 cmd.pyc
>>> drwxr-xr-x  2 root root  4096 Apr 24  2014 command
>>> -rw-r--r--  1 root root  4131 Mar 22  2014 config.py
>>> -rw-r--r--  1 root root  3556 Apr 24  2014 config.pyc
>>> -rw-r--r--  1 root root  9019 Mar 22  2014 core.py
>>> -rw-r--r--  1 root root  7595 Apr 24  2014 core.pyc
>>> -rw-r--r--  1 root root 17732 Mar 22  2014 cygwinccompiler.py
>>> -rw-r--r--  1 root root  9801 Apr 24  2014 cygwinccompiler.pyc
>>> -rw-r--r--  1 root root   162 Mar 22  2014 debug.py
>>> -rw-r--r--  1 root root   252 Apr 24  2014 debug.pyc
>>> -rw-r--r--  1 root root  3509 Mar 22  2014 dep_util.py
>>> -rw-r--r--  1 root root  3172 Apr 24  2014 dep_util.pyc
>>> -rw-r--r--  1 root root  7870 Mar 22  2014 dir_util.py
>>> -rw-r--r--  1 root root  6774 Apr 24  2014 dir_util.pyc
>>> -rw-r--r--  1 root root 50049 M

Re: [sage-devel] Decision making (refuse to vote)

[François Bissey]

Hi Thierry,

Well that has to be the fiercest reaction so far.

Volker proposed the text and he probably pinched most of it from 
somewhere else (fedora if I remember correctly).

I have to take issue with some of your characterization.
There was a long discussion thread and I'll admit I haven't
read the whole of it but a fair amount of it and no one
proposed a change of wording for it. The anti camp didn't want
amendment, they'd rather not have it.
The "for" camp has not put forward any alternative words as far
as I remember.

There was plenty of opportunity to get the text amended and
it didn't happen. Think what you will of it.

I personally think that whatever the result it has shown that 
the community is broadly well behaved while there seem to be
strong feelings, so far you are the one who pushed the envelop 
the furthest, the debate stayed quite polite.

I don't think we need the code but considering the general 
behavior here I don't think it will matter. We are a quite
well behaved community.

We'll have to deal with the occasional explosion with or without code.

Francois

On Tue, 25 Nov 2014 03:17:19 Thierry wrote:
> Hi again,
> 
> I have serious concerns with the current situation.
> 
> What is wrong with the current call for vote ?
> 
> 
> Let me summarize the situation :
> 
> - An obscure group of self-appointed people wrote a text, they had the
>   possibility to discuss and amend its content, with an unlimited amount
>   of time. The estimated entropy of the text is larger than 1.
> 
> - This text can not be modified by the community and is submitted as is
>   for a majority vote. Those that do not belong to the obscure group
>   (which is still anonymous after various requests) can therefore only
>   contribute 1/n bits, where n is the number of voters. They have less
>   than two days to answer.
> 
> 
> My point of view about this :
> 
> - This is paternalistic because it means that the community as a whole is
>   not able to work together and write anything good. This looks also
>   useless (or dangerous?) to take more time and let people think and
>   exchange about this.
> 
> - This contradicts the contents of the text which claims about
>   collaboration and respect, however it is not how the obscure group
>   behaves. Hence, i doubt that the text will be used in other way than for
>   repression.
> 
> - This is in complete contradiction with Sage community habits. Let me
>   give an example: when someone writes some code, anyone can help during
>   the review process. If one of the reviewers thinks something can be
>   improved, it is discussed on trac, modifications are made until
>   everyone agree. We are all pointing toward a common goal. Discussing
>   some big issues on sage-devel is a way to involve more people in
>   important design discussions and mix more ideas together, it is not a
>   way to enforce the approval by a majority vote.
> 
> 
> There are strong issues with majority voting :
> 
> - A call for vote aims at closing a discussion. However, if there is an
>   issue somewhere, the only way to reach a stable solution is precisely to
>   let the discussion open until enough content is added into it and try to
>   merge good ideas and objections. Regarding the current proposition, some
>   objections were emitted by various people.
> 
> - Launching such a vote creates a division within the community, whatever
>   the outcome, between those who belong to the "majority" and the others.
>   This will result in oppression: the minority will have to behave
>   according to what the majority decided.
> 
> - It is easy to raise an army of voters, especially on a public
>   mailing-list. It can be as innocent as sending e-mails to people that
>   are likely to agree with you and say "there is a vote going on, you
>   should read it and make your own opinion".
> 
> - This is unlikely to attract future developers with diverse and original
>   points of view and autonomous thinking.
> 
> - If the text is voted, the minority will have to conform to a text they
>   could not even discuss. This is even more serious that the text is about
>   individual behaviour. Was there with a particular minority in mind ?
> 
> 
> Choosing among ideas or mixing them ? Competition or Collaboration ? Fight
> or Solidarity ?
> 
> This e-mail is not ended, i encourage you to read and think about
> "majority voting" and "consensus decision making".
> 
> We have a serious communication issue, and we need to discuss it, without
> deadline. Following the previous thread, Vincent opened a page for this on
> the wiki.
> 
> Ciao,
> Thierry

-- 
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, v

Re: [sage-devel] Code of Conduct (missing dependencies)

[kcrisman]

>
> Once more, the rules make a point to enforce politeness but they seem 
> to avoid things like having the respect to answer a honest question. 
>
>  
Collated for ease of reply, though there were also implicit questions and 
examples of what was meant in the email.

- what is our commitment to free software ? 
- should we collaborate (fund, advertise,...) with closed proprietary 
  software ? 
- how do we take decisions (equality, transparency, collaboration, taking 
  care of minorities,...) ? 
- are there some reserved territories within the source code ? 
- is the acceptation of google terms of service a necessary condition for 
  a person to be allowed to take part to the decisions ? 
- who is on the short list ? 
- with which motivation ? 
- which concrete examples in mind ? 
- Should google's rules rule our policy ? 

Could we thus have an answer to the ones aked by Therry ? Not ignoring 
> anybody is also part of elementary "friendliness". 
>
>
Though to be fair, the right not to answer is probably also a right.

I'll comment briefly on a couple of these, with no claims to accuracy, just 
my impressions.  I do think it's fair for people to respond, though I also 
think a lot of this is pretty far from the code of conduct discussion.

* re: Google - I believe that on various occasions William has invited 
personal emails when it was appropriate to keep things off the record, and 
I am sure that if anyone asked, a proxy vote by such means would be 
accepted, though it would probably have to be from someone who didn't just 
say "Yeah, sure, I read sage-devel all the time without subscribing ... 
yeah, sure."

* re: free vs. proprietary - there is a VERY wide range of opinion on the 
appropriateness here, and healthy discussion of it.  It seems that Sage as 
an entity (insofar as such a thing exists) has the in practice position 
(not that any one actual human holds this position!) that a strong free 
license like GPL is necessary for mathematical reasons, but that depending 
on the situation it will remain agnostic as to collaboration with other 
software.  However, I don't think the current discussion impacts this 
either way - and in any case it would be in practice impossible to change 
the license, as William pointed out sometime earlier.

So in some ways Sage is "living the tension" of the open source community. 
 That isn't going to go away; there will never be a unified position on 
these points among Sage developers.

* re: reserved territory - I don't agree with Raymond on everything, but 
his point in "Homesteading the Noosphere" is still true that in projects 
like ours "authority follow[s] responsibility".  So there are people who 
have poured a lot of time into certain areas and really *understand* them, 
and so do have some de facto claim on what happens.  But this is not 
measurable in lines of code or commits or Trac edits or anything like that, 
and becomes fluid.  No one is incapable of being overruled on Trac, though 
typically practice has been that if something comes to sage-devel and then 
no one really responds, the conflicting parties need to work it out on 
their own - usually in such cases a ticket simply is abandoned, as a 
release manager would be pretty reluctant to intervene except in the case 
of a serious bug.

(For an example not related to most of the parties most aggrieved by this 
discussion, for a long time Burcin was "the" symbolics guy for this reason; 
yet even as he has moved to other responsibilities, newer folks like mjo 
and rws have been helping and gaining that authority.  It is totally 
organic, yet when Burcin makes a comment on this code now, naturally it's 
taken very seriously - and gratefully.)

-- 
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] Decision making (refuse to vote)

[Nathann Cohen]

Hello !

> Volker proposed the text and he probably pinched most of it from
> somewhere else (fedora if I remember correctly).

He probably participated indeed, but he begins his first post with that:

"Some of the Sage developers who are better with words than me went ahead
and stole a lot more, mostly from [...]"

> I have to take issue with some of your characterization.
> There was a long discussion thread and I'll admit I haven't
> read the whole of it but a fair amount of it and no one
> proposed a change of wording for it. The anti camp didn't want
> amendment, they'd rather not have it.

Several developpers mentionned making it an "advice" instead of a "code",
so you can see that even the title was an open question. Actually, some of
us have been surprised at the speed at which this has become a vote. If you
give us an occasion to discuss the actual text, we most surely will.

> The "for" camp has not put forward any alternative words as far
> as I remember.

Well. It may strike you as obvious that among those who were on the
short-list to write the code that will become sage-devel's law, everybody
will be in the "pro" side. We have been asking quite repeatedly who
organised this and when, so far without answer. I do not like this kind of
behaviour. This is exactly the "communication and unhappiness" problem
right at the top of of the code, and in contradiction with any claim that
sage is built as a community.

So can we oppose the code against how the code is being enforced right now
? Enforcing the code when so many people are against it is precisely the
kind of things you should not think of doing is you want a strong sense of
community.

Its most immediate effect, as you can see, is to divide us.

> I personally think that whatever the result it has shown that
> the community is broadly well behaved while there seem to be
> strong feelings, so far you are the one who pushed the envelop
> the furthest, the debate stayed quite polite.

Especially since somebody not being polite here will now be judged by "a
committee" in private.
>
> I don't think we need the code but considering the general
> behavior here I don't think it will matter. We are a quite
> well behaved community.
>
> We'll have to deal with the occasional explosion with or without code.
>
> Francois
>
> On Tue, 25 Nov 2014 03:17:19 Thierry wrote:
>> Hi again,
>>
>> I have serious concerns with the current situation.
>>
>> What is wrong with the current call for vote ?
>>
>>
>> Let me summarize the situation :
>>
>> - An obscure group of self-appointed people wrote a text, they had the
>>   possibility to discuss and amend its content, with an unlimited amount
>>   of time. The estimated entropy of the text is larger than 1.
>>
>> - This text can not be modified by the community and is submitted as is
>>   for a majority vote. Those that do not belong to the obscure group
>>   (which is still anonymous after various requests) can therefore only
>>   contribute 1/n bits, where n is the number of voters. They have less
>>   than two days to answer.
>>
>>
>> My point of view about this :
>>
>> - This is paternalistic because it means that the community as a whole is
>>   not able to work together and write anything good. This looks also
>>   useless (or dangerous?) to take more time and let people think and
>>   exchange about this.
>>
>> - This contradicts the contents of the text which claims about
>>   collaboration and respect, however it is not how the obscure group
>>   behaves. Hence, i doubt that the text will be used in other way than
for
>>   repression.
>>
>> - This is in complete contradiction with Sage community habits. Let me
>>   give an example: when someone writes some code, anyone can help during
>>   the review process. If one of the reviewers thinks something can be
>>   improved, it is discussed on trac, modifications are made until
>>   everyone agree. We are all pointing toward a common goal. Discussing
>>   some big issues on sage-devel is a way to involve more people in
>>   important design discussions and mix more ideas together, it is not a
>>   way to enforce the approval by a majority vote.
>>
>>
>> There are strong issues with majority voting :
>>
>> - A call for vote aims at closing a discussion. However, if there is an
>>   issue somewhere, the only way to reach a stable solution is precisely
to
>>   let the discussion open until enough content is added into it and try
to
>>   merge good ideas and objections. Regarding the current proposition,
some
>>   objections were emitted by various people.
>>
>> - Launching such a vote creates a division within the community, whatever
>>   the outcome, between those who belong to the "majority" and the others.
>>   This will result in oppression: the minority will have to behave
>>   according to what the majority decided.
>>
>> - It is easy to raise an army of voters, especially on a public
>>   mailing-list. It can be as innocent as sending e-mails to people that

Re: [sage-devel] Decision making (refuse to vote)

[Andrew]

> Several developpers mentionned making it an "advice" instead of a "code", 
> so you can see that even the title was an open question.
>

I voted for adopting the code but I would more comfortable with something 
like this being adopted as *guidelines* or *recommendations*, especially 
since the votes for and against seem to be roughly equal (please correct me 
if I am wrong as I haven't counted them recently). As with others, I am not 
particularly in favour of the idea that there be a committee to "enforce" a 
code of conduct.
 

> Actually, some of us have been surprised at the speed at which this has 
> become a vote. If you give us an occasion to discuss the actual text, we 
> most surely will.
>

Well,Volker's thread has been open for two weeks and it is THE most 
discussed thread in sage-dev for quite some time. Also, Vicent has created 
a wiki page 

 
with the express purpose of discussing and reaching consensus on the text.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Bill Page]

On 24 November 2014 at 17:43, Ondřej Čertík  wrote:
> On Mon, Nov 24, 2014 at 1:57 PM, Bill Page  wrote:
> ...
>>
>> In FriCAS 'abs' is already a kernel function and it implemented the
>> derivative of 'abs' even before my proposed patch but I think the
>> current definition is wrong:
>>
>> (14) -> D(abs(x),x)
>>
>>  abs(x)
>>(14)  --
>> x
>> Type: Expression(Integer)
>
> I think that's correct for real numbers, i.e. x/abs(x) = abs(x) / x.
>

I am not very interested in real numbers.  I am interested in the
algebra.  Would you say that

  sqrt(x^2).diff(x) = sqrt(x^2)/x

is OK?

>> Rather, I think the correct definition of 'log(z)' is the solution of
>>
>>   z = exp(?)
>>
>> So we can write z=exp(log(z)) by definition.
>
> Indeed, exp(log(z))=z always,

Not just "true always". It is the definition of 'log(z)'.

>
> In both (A) and (B),
> it is true that z = exp(log(z)). However, these are different:
>
> (A) log(exp(z)) = z + 2*pi*i*n
> (B) log(exp(z)) = z + 2*pi*i*floor((pi-Im z) / 2*pi)
>
> In (B), you get a single value, but in (A) you get multiple values,
> one for each "n".
>

Better to say (A) is true "\forall n \in Integer"

> I am very familiar with the approach (B) and I think I understand
> exactly what follows from what and how to derive all the formulas.

(B) is about choosing a particular "branch" of 'log' - the principal
value. But I don't want to be forced to make a choice of branch until
I actually need to evaluate an expression numerically.

> But I am not 100% sure with (A), I was hoping you can help, since
> that's the approach that you want to use in FriCAS.

(A) is not quite the approach I want to use for 'Expression' in
FriCAS.  I want 'log(exp(z))' to be the solution of

  exp(z) = exp(?)

The best way to say that algebraically (symbolically) is just
'log(exp(z))', i.e. without evaluation.  This is what FriCAS already
does in the case of

(1) -> z:Expression Complex Integer
   Type: Void
(2) -> exp(log(z))

   (2)  z
   Type: Expression(Complex(Integer))
(3) -> log(exp(z))

  z
   (3)  log(%e )
   Type: Expression(Complex(Integer))

but unfortunately not in the case of 'Expression Integer'.

(4) -> z:Expression Integer
   Type: Void
(5) -> log(exp(z))

   (5)  z
Type: Expression(Integer)

I think that what it currently does for 'Expression Integer' should be
considered a bug.

> I think what I wrote is correct for (A), but please correct me if I am wrong.
>
>> This is exactly analogous
>> to the treatment of 'sqrt(z)' as the solution to
>>
>>   z = ? * ?
>>

We have

  sqrt(z)^2 = z

but

  sqrt(z^2) = sqrt(z^2)

>>> However, this definition quickly becomes impractical, because you
>>> need to be able to numerically evaluate symbolic expressions, and
>>> you would need to carry the symbolic term 2*pi*i*n around.
>>
>> We do not need an extra term.  We only need axioms for the correct
>> behavior of the expression 'log(z)'. But 'log(z)' does not denote a
>> function in the sense of a many-to-one mapping.  The inverse of a
>> function is only a function (possibly partial) if the function is
>> injective (one-to-one).
>
> Sure, that's why you have "n" in the formula for log(z) in (A), and
> the function is multivalued over all "n".
>

No.  As you have written it, it is a function of two variables with
one value for each z and n.

  f(z,n) = z + 2*pi*i*n

I think what you are trying to say is

 (A) log(exp(z)) = { z + 2*pi*i*n | for all n in Integer}

and

  sqrt(z) = {  x | x^2 =z }

Although it may seem simple in this case, in general implementing sets
with comprehension like this requires logic and takes us outside of
algebra as such into the realm of theorem proving.

>>
>> The Riemann surface is an important tool in complex analysis but I
>> have yet to see it used explicitly in any computer algebra system as
>> a representation of complex functions.
>
> I thought the Riemann surface gives you a way to couple "n" in
> log(a*b), log(a) and log(b) in such a way that you get exactly
> log(a*b)-log(a)-log(b)=0. I.e. that the Riemann surface is (A).
> I agree that I haven't seen it used in CAS. But I think it must be
> implicitly used in FriCAS somehow. Maybe you can clarify that.

I don't think it is used in FriCAS at all.  A Riemann surface is a
manifold. At each point in the manifold we need to evaluate a
function, but how would you propose to represent this surface
algebraically?  For example, the surface of a sphere is a manifold.
For that we need a co-ordinate system that labels each point on the
surface.  In a sense the important thing about a Riemann surface is
its global topology and this is different for each complex holomorphic
func

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

[Ondřej Čertík]

On Mon, Nov 24, 2014 at 10:23 PM, Bill Page  wrote:
> On 24 November 2014 at 17:43, Ondřej Čertík  wrote:
>> On Mon, Nov 24, 2014 at 1:57 PM, Bill Page  
>> wrote:
>> ...
>>>
>>> In FriCAS 'abs' is already a kernel function and it implemented the
>>> derivative of 'abs' even before my proposed patch but I think the
>>> current definition is wrong:
>>>
>>> (14) -> D(abs(x),x)
>>>
>>>  abs(x)
>>>(14)  --
>>> x
>>> Type: 
>>> Expression(Integer)
>>
>> I think that's correct for real numbers, i.e. x/abs(x) = abs(x) / x.
>>
>
> I am not very interested in real numbers.  I am interested in the
> algebra.  Would you say that
>
>   sqrt(x^2).diff(x) = sqrt(x^2)/x
>
> is OK?

I think so, using the following calculation:

sqrt(x^2).diff(x) = exp(1/2*log(x^2)).diff(x) = exp(1/2*log(x^2)) *
1/2 * 1/x^2 * 2*x = sqrt(x^2)/x

The function exp(1/2*log(x^2)) that we differentiate is analytic, so I
don't see any issue here.

>
>>> Rather, I think the correct definition of 'log(z)' is the solution of
>>>
>>>   z = exp(?)
>>>
>>> So we can write z=exp(log(z)) by definition.
>>
>> Indeed, exp(log(z))=z always,
>
> Not just "true always". It is the definition of 'log(z)'.
>
>>
>> In both (A) and (B),
>> it is true that z = exp(log(z)). However, these are different:
>>
>> (A) log(exp(z)) = z + 2*pi*i*n
>> (B) log(exp(z)) = z + 2*pi*i*floor((pi-Im z) / 2*pi)
>>
>> In (B), you get a single value, but in (A) you get multiple values,
>> one for each "n".
>>
>
> Better to say (A) is true "\forall n \in Integer"

Yes.

>
>> I am very familiar with the approach (B) and I think I understand
>> exactly what follows from what and how to derive all the formulas.
>
> (B) is about choosing a particular "branch" of 'log' - the principal
> value.

Correct.

> But I don't want to be forced to make a choice of branch until
> I actually need to evaluate an expression numerically.

I understand that's what you want. I am just trying to understand how
exactly this works.

>
>> But I am not 100% sure with (A), I was hoping you can help, since
>> that's the approach that you want to use in FriCAS.
>
> (A) is not quite the approach I want to use for 'Expression' in
> FriCAS.  I want 'log(exp(z))' to be the solution of
>
>   exp(z) = exp(?)
>
> The best way to say that algebraically (symbolically) is just
> 'log(exp(z))', i.e. without evaluation.  This is what FriCAS already
> does in the case of
>
> (1) -> z:Expression Complex Integer
>Type: Void
> (2) -> exp(log(z))
>
>(2)  z
>Type: Expression(Complex(Integer))
> (3) -> log(exp(z))
>
>   z
>(3)  log(%e )
>Type: Expression(Complex(Integer))
>
> but unfortunately not in the case of 'Expression Integer'.
>
> (4) -> z:Expression Integer
>Type: Void
> (5) -> log(exp(z))
>
>(5)  z
> Type: Expression(Integer)
>
> I think that what it currently does for 'Expression Integer' should be
> considered a bug.
>
>> I think what I wrote is correct for (A), but please correct me if I am wrong.
>>
>>> This is exactly analogous
>>> to the treatment of 'sqrt(z)' as the solution to
>>>
>>>   z = ? * ?
>>>
>
> We have
>
>   sqrt(z)^2 = z
>
> but
>
>   sqrt(z^2) = sqrt(z^2)
>
 However, this definition quickly becomes impractical, because you
 need to be able to numerically evaluate symbolic expressions, and
 you would need to carry the symbolic term 2*pi*i*n around.
>>>
>>> We do not need an extra term.  We only need axioms for the correct
>>> behavior of the expression 'log(z)'. But 'log(z)' does not denote a
>>> function in the sense of a many-to-one mapping.  The inverse of a
>>> function is only a function (possibly partial) if the function is
>>> injective (one-to-one).
>>
>> Sure, that's why you have "n" in the formula for log(z) in (A), and
>> the function is multivalued over all "n".
>>
>
> No.  As you have written it, it is a function of two variables with
> one value for each z and n.
>
>   f(z,n) = z + 2*pi*i*n
>
> I think what you are trying to say is
>
>  (A) log(exp(z)) = { z + 2*pi*i*n | for all n in Integer}

Exactly, that's what I meant.

>
> and
>
>   sqrt(z) = {  x | x^2 =z }

Sure, though I would just define

sqrt(z) = exp(1/2 * log(z))

>
> Although it may seem simple in this case, in general implementing sets
> with comprehension like this requires logic and takes us outside of
> algebra as such into the realm of theorem proving.

Sure. But that's what you want, correct?

>
>>>
>>> The Riemann surface is an important tool in complex analysis but I
>>> have yet to see it used explicitly in any computer algebra system as
>>> a representation of complex functions.
>>
>> I thought the Riemann surface gives you a way to c

[sage-devel] Generating small posets of given size (ticket #14110)

[Jori Mantysalo]

Anyone interested in http://trac.sagemath.org/ticket/14110 ? Before 
continuing it would nice to know if the code compiles on Macintosh(es) at 
all.


Also there is a question about how this should be used.

--
Jori Mäntysalo

Re: [sage-devel] Re: VOTE: code of conduct - ends Monday at midnight, PST.

[Robert Bradshaw]

[ X ] No -- do not adopt the code of conduct stated below

I also share some of the sentiments of Thierry.

On Mon, Nov 24, 2014 at 4:29 PM, john_perry_usm  wrote:
> [ X ] No -- do not adopt the code of conduct stated below
>
> --
> 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.