From ralf.gommers at gmail.com Mon Oct 2 17:11:13 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 3 Oct 2017 10:11:13 +1300 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: On Thu, Sep 14, 2017 at 12:12 AM, Matthew Brett wrote: > Hi, > > On Wed, Sep 13, 2017 at 11:39 AM, Ralf Gommers > wrote: > > > > > > On Tue, Sep 12, 2017 at 12:08 PM, Stefan van der Walt < > stefanv at berkeley.edu> > > wrote: > >> > >> On Mon, Sep 11, 2017, at 14:08, Pauli Virtanen wrote: > >> > It can of course be useful to think about writing such things down > >> > explicitly to produce a document explaining (1), and I think the > Apache > >> > one gives good hints for keeping things productive. But it is less > >> > clear to me this is something for which formal moderator action would > >> > be necessary. > >> > > >> > However, if I understand correctly, the reason why people want these > >> > things is more about (2). Indeed, this is standard stuff in the > >> > workplace and in moderation of internet forums (usually in "Rules" in > >> > the latter). > > > > > > Agreed that many people want it for (2). There's an important difference > > though. Forum rules and workplace policies are usually not very visible, > > while with a CoC for an open source project one wants it to be quite > > visible. Therefore the importance of it having a positive tone and > > statements about what we value is a lot more important than for something > > like a workplace policy. > > Yes - I agree strongly. I think this does do dual service as a > statement of values as well as well as a threat of enforcement. > > >> It seems a good idea to structure this part so that it > >> > does not fail if someone acts in bad faith, and so that the moderation > >> > plan is reasonable to the reader and possible to implement. > >> > >> I feel it is important to mix in a bit of (1) with (2), the reason being > >> that almost every person reading the CoC will not ever act in bad faith. > >> You'd think that those people could simply ignore language related to > >> enforcement, but in previous discussions (e.g., around the Jupyter CoC) > >> that turned out not to be the case: it is all too easy to frighten > >> people into not speaking up. > >> > >> So, I'd recommend focusing on a description of the kind of community we > >> want, instead of what we're trying to avoid; and postponing the > >> enforcement language until later in the document, making it clear that > >> enforcement only comes through (somewhat wide) deliberation of trusted > >> community members (and, preferably, also after engagement with the > >> offending party). > >> > >> This way, we can hopefully instill trust in our CoC as a process, rather > >> than a set of rules. > > > > > > That sounds quite good to me. The process at a high level (for all but > the > > most severe cases) should be something like: > > > > 1. complaint > > 2. reasonable discussion/feedback > > 3. mediation (if feedback didn't help) > > 4. enforcement via transparent decision by CoC committee (if mediation > > failed) > > Yes, I like that list a lot. Although, I was proposing in the Jupyter > discussion, that informal mediation be triggered really early, to help > people get over the feeling of being isolated, that can easily arise > in on-line communication - see : > https://github.com/jupyter/governance/pull/23#issuecomment-269352416 . > This was partly based on my reading of [1] (see quote), which > suggested that one reason that women can find online forums > intimidating is the lack of a mentor to guide them through the > thickets of unfamiliar jargon, habits, and cliques. And partly > because, having read that, I realized I felt the same way. > > > And not what some people may be afraid of, and sometimes actually > happens in > > practice: > > 1. complaint > > 2. enforcement > > > > For a new CoC draft, taking most of the Apache doc and tacking the more > > rules/enforcement oriented content of the Contributor Covenant onto the > end > > seems like a good starting point. > > Yes, I agree with that too ... :) > Hi all, here is a new version of the CoC taking this approach: https://github.com/scipy/scipy/pull/7963 Please have a look and comment. Higher level discussion better on this list, detailed textual comments on the PR itself. Cheers, Ralf > Cheers, > > Matthew > > [1] https://suegardner.org/2011/02/19/nine-reasons-why-women- > dont-edit-wikipedia-in-their-own-words > > """ > The few times I?ve touched wikipedia, I?ve been struck by how > isolating it can feel. It?s a very fend for yourself kind of place for > me. Anywhere else online, my first impulse is to put out feelers. I > make friends, ask for links to FAQs and guides, and inevitably someone > takes me under their wing and shows me the ropes of whatever niche > culture I?m obsessed with that month. > """ > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bennet at umich.edu Mon Oct 2 19:28:38 2017 From: bennet at umich.edu (Bennet Fauber) Date: Mon, 2 Oct 2017 19:28:38 -0400 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: I am more a lurker than a contributor, but I would like to suggest caution with respect to item #5 in the proposed CoC. +5. Be concise. Keep in mind that what you write once will be read by hundreds + of persons. Writing a short email means people can understand the + conversation as efficiently as possible. Short emails should always strive + to be empathetic, welcoming, friendly and patient. When a long explanation + is necessary, consider adding a summary. I suggest that you should stress more that people should strive for clarity and completeness, and then say that brief and comprehensive is the desired goal. I think you're leaning on short too hard, and that will encourage incomplete more than real concision. There are my reasons: 1) one person's concise could well be another's incomplete. 2) There are many, many terms that have more than one use, or that have different meanings in different contexts, or may have connotations; sometimes being concise leads to use of seemingly unambiguous terms that do turn out to be ambiguous. For those who would reply that the definition of 'concise' implies completeness, as in the definition given: giving a lot of information clearly and in a few words; brief but comprehensive. In popular speech, and to those who may have been over-exposed to some kinds of management, concise is more likely to be interpreted as 'abbreviated', which highlights my second point above. I myself often interpret 'concise' to mean 'short' and often 'abbreviated', because that is what I have (alas) become accustomed to in my work environment. Language evolved to have a lot of redundancy built into it for a reason. Stripping it of too much is as bad as including too much. I hope I was sufficiently concise. ;-) On Mon, Oct 2, 2017 at 5:11 PM, Ralf Gommers wrote: > > > On Thu, Sep 14, 2017 at 12:12 AM, Matthew Brett > wrote: >> >> Hi, >> >> On Wed, Sep 13, 2017 at 11:39 AM, Ralf Gommers >> wrote: >> > >> > >> > On Tue, Sep 12, 2017 at 12:08 PM, Stefan van der Walt >> > >> > wrote: >> >> >> >> On Mon, Sep 11, 2017, at 14:08, Pauli Virtanen wrote: >> >> > It can of course be useful to think about writing such things down >> >> > explicitly to produce a document explaining (1), and I think the >> >> > Apache >> >> > one gives good hints for keeping things productive. But it is less >> >> > clear to me this is something for which formal moderator action would >> >> > be necessary. >> >> > >> >> > However, if I understand correctly, the reason why people want these >> >> > things is more about (2). Indeed, this is standard stuff in the >> >> > workplace and in moderation of internet forums (usually in "Rules" in >> >> > the latter). >> > >> > >> > Agreed that many people want it for (2). There's an important difference >> > though. Forum rules and workplace policies are usually not very visible, >> > while with a CoC for an open source project one wants it to be quite >> > visible. Therefore the importance of it having a positive tone and >> > statements about what we value is a lot more important than for >> > something >> > like a workplace policy. >> >> Yes - I agree strongly. I think this does do dual service as a >> statement of values as well as well as a threat of enforcement. >> >> >> It seems a good idea to structure this part so that it >> >> > does not fail if someone acts in bad faith, and so that the >> >> > moderation >> >> > plan is reasonable to the reader and possible to implement. >> >> >> >> I feel it is important to mix in a bit of (1) with (2), the reason >> >> being >> >> that almost every person reading the CoC will not ever act in bad >> >> faith. >> >> You'd think that those people could simply ignore language related to >> >> enforcement, but in previous discussions (e.g., around the Jupyter CoC) >> >> that turned out not to be the case: it is all too easy to frighten >> >> people into not speaking up. >> >> >> >> So, I'd recommend focusing on a description of the kind of community we >> >> want, instead of what we're trying to avoid; and postponing the >> >> enforcement language until later in the document, making it clear that >> >> enforcement only comes through (somewhat wide) deliberation of trusted >> >> community members (and, preferably, also after engagement with the >> >> offending party). >> >> >> >> This way, we can hopefully instill trust in our CoC as a process, >> >> rather >> >> than a set of rules. >> > >> > >> > That sounds quite good to me. The process at a high level (for all but >> > the >> > most severe cases) should be something like: >> > >> > 1. complaint >> > 2. reasonable discussion/feedback >> > 3. mediation (if feedback didn't help) >> > 4. enforcement via transparent decision by CoC committee (if mediation >> > failed) >> >> Yes, I like that list a lot. Although, I was proposing in the Jupyter >> discussion, that informal mediation be triggered really early, to help >> people get over the feeling of being isolated, that can easily arise >> in on-line communication - see : >> https://github.com/jupyter/governance/pull/23#issuecomment-269352416 . >> This was partly based on my reading of [1] (see quote), which >> suggested that one reason that women can find online forums >> intimidating is the lack of a mentor to guide them through the >> thickets of unfamiliar jargon, habits, and cliques. And partly >> because, having read that, I realized I felt the same way. >> >> > And not what some people may be afraid of, and sometimes actually >> > happens in >> > practice: >> > 1. complaint >> > 2. enforcement >> > >> > For a new CoC draft, taking most of the Apache doc and tacking the more >> > rules/enforcement oriented content of the Contributor Covenant onto the >> > end >> > seems like a good starting point. >> >> Yes, I agree with that too ... :) > > > Hi all, here is a new version of the CoC taking this approach: > https://github.com/scipy/scipy/pull/7963 > > Please have a look and comment. Higher level discussion better on this list, > detailed textual comments on the PR itself. > > Cheers, > Ralf > > > >> >> Cheers, >> >> Matthew >> >> [1] >> https://suegardner.org/2011/02/19/nine-reasons-why-women-dont-edit-wikipedia-in-their-own-words >> >> """ >> The few times I?ve touched wikipedia, I?ve been struck by how >> isolating it can feel. It?s a very fend for yourself kind of place for >> me. Anywhere else online, my first impulse is to put out feelers. I >> make friends, ask for links to FAQs and guides, and inevitably someone >> takes me under their wing and shows me the ropes of whatever niche >> culture I?m obsessed with that month. >> """ >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > From stefanv at berkeley.edu Mon Oct 2 19:57:36 2017 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Mon, 02 Oct 2017 16:57:36 -0700 Subject: [SciPy-Dev] the demise of SciPy Central In-Reply-To: References: <1506534155.3734638.1120303936.2A8549F4@webmail.messagingengine.com> Message-ID: <1506988656.1916094.1125689552.7748F638@webmail.messagingengine.com> On Thu, Sep 28, 2017, at 00:38, Ralf Gommers wrote: > > No plan yet. If I'd have to take a stab at it, I'd suggest: > > 1. Put the content > (https://github.com/scipy/SciPyCentral#backup-and-restore) > somewhere accessible> 2. Take the last version of each script/notebook, discard the history.> 3. Write some code to transform all of those into notebooks suitable > for inclusion in https://github.com/scipy/scipy-cookbook> 4. Go through by hand, see what's in good shape, and send PRs to > https://github.com/scipy/scipy-cookbook for those.> > That may be quite a bit of work though. At least (1) should be done > before decommissioning the server. This is a perfect student project; I'm going to try and find someone to work on it. Thanks for this outline, St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Oct 3 05:13:37 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 3 Oct 2017 10:13:37 +0100 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: On Tue, Oct 3, 2017 at 12:28 AM, Bennet Fauber wrote: > I am more a lurker than a contributor, but I would like to suggest > caution with respect to item #5 in the proposed CoC. > > +5. Be concise. Keep in mind that what you write once will be read by hundreds > + of persons. Writing a short email means people can understand the > + conversation as efficiently as possible. Short emails should always strive > + to be empathetic, welcoming, friendly and patient. When a long explanation > + is necessary, consider adding a summary. > > I suggest that you should stress more that people should strive for > clarity and completeness, and then say that brief and comprehensive is > the desired goal. I think you're leaning on short too hard, and that > will encourage incomplete more than real concision. > > There are my reasons: 1) one person's concise could well be another's > incomplete. 2) There are many, many terms that have more than one > use, or that have different meanings in different contexts, or may > have connotations; sometimes being concise leads to use of seemingly > unambiguous terms that do turn out to be ambiguous. > > For those who would reply that the definition of 'concise' implies > completeness, as in the definition given: > > giving a lot of information clearly and in a few words; brief but > comprehensive. > > In popular speech, and to those who may have been over-exposed to some > kinds of management, concise is more likely to be interpreted as > 'abbreviated', which highlights my second point above. I myself often > interpret 'concise' to mean 'short' and often 'abbreviated', because > that is what I have (alas) become accustomed to in my work > environment. > > Language evolved to have a lot of redundancy built into it for a > reason. Stripping it of too much is as bad as including too much. > > I hope I was sufficiently concise. ;-) I agree with the general idea. Concise emails can be very intimidating, as in "it's so obvious you are wrong I can't be bothered to explain why". It's can also be an alienating sign, as in "I'm so senior here that there is no need for me to explain my reasoning". Maybe a better way to put it, is something like "Try to help your audience; your email will be read by hundreds of people, and many people will read only a few lines to decide if they are interested. Do you best to get to the point as fast as you can, so people can see what the email will be about. It is often useful to put a summary of a few lines at the top and then explain your reasoning in more depth below, for people who want to learn more." We could point to a few good examples. Cheers, Matthew From bennet at umich.edu Tue Oct 3 07:48:14 2017 From: bennet at umich.edu (Bennet Fauber) Date: Tue, 3 Oct 2017 07:48:14 -0400 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: Matthew, Yes, precisely. I think this is in keeping with the desire to provide a positive tone, suggestive of desired behavior. > "Try to help your > audience; your email will be read by hundreds of people, and many > people will read only a few lines to decide if they are interested. > Do you best to get to the point as fast as you can, so people can see > what the email will be about. It is often useful to put a summary of > a few lines at the top and then explain your reasoning in more depth > below, for people who want to learn more." We could point to a few > good examples. I hope this modification gets closer to convergence. Help your audience. Your email will be read by hundreds of people. You may find summarizing at the beginning and providing fuller explanation of your reasoning below helpful, to yourself as well as your readers. Many people will scan the first few lines to see if the message is pertinent to their interests and expertise. Help them and future readers who may be sifting hundreds of search engine hits. See for a few select examples. On Tue, Oct 3, 2017 at 5:13 AM, Matthew Brett wrote: > On Tue, Oct 3, 2017 at 12:28 AM, Bennet Fauber wrote: >> I am more a lurker than a contributor, but I would like to suggest >> caution with respect to item #5 in the proposed CoC. >> >> +5. Be concise. Keep in mind that what you write once will be read by hundreds >> + of persons. Writing a short email means people can understand the >> + conversation as efficiently as possible. Short emails should always strive >> + to be empathetic, welcoming, friendly and patient. When a long explanation >> + is necessary, consider adding a summary. >> >> I suggest that you should stress more that people should strive for >> clarity and completeness, and then say that brief and comprehensive is >> the desired goal. I think you're leaning on short too hard, and that >> will encourage incomplete more than real concision. >> >> There are my reasons: 1) one person's concise could well be another's >> incomplete. 2) There are many, many terms that have more than one >> use, or that have different meanings in different contexts, or may >> have connotations; sometimes being concise leads to use of seemingly >> unambiguous terms that do turn out to be ambiguous. >> >> For those who would reply that the definition of 'concise' implies >> completeness, as in the definition given: >> >> giving a lot of information clearly and in a few words; brief but >> comprehensive. >> >> In popular speech, and to those who may have been over-exposed to some >> kinds of management, concise is more likely to be interpreted as >> 'abbreviated', which highlights my second point above. I myself often >> interpret 'concise' to mean 'short' and often 'abbreviated', because >> that is what I have (alas) become accustomed to in my work >> environment. >> >> Language evolved to have a lot of redundancy built into it for a >> reason. Stripping it of too much is as bad as including too much. >> >> I hope I was sufficiently concise. ;-) > > I agree with the general idea. Concise emails can be very > intimidating, as in "it's so obvious you are wrong I can't be bothered > to explain why". It's can also be an alienating sign, as in "I'm so > senior here that there is no need for me to explain my reasoning". > > Maybe a better way to put it, is something like "Try to help your > audience; your email will be read by hundreds of people, and many > people will read only a few lines to decide if they are interested. > Do you best to get to the point as fast as you can, so people can see > what the email will be about. It is often useful to put a summary of > a few lines at the top and then explain your reasoning in more depth > below, for people who want to learn more." We could point to a few > good examples. > > Cheers, > > Matthew > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev From ilhanpolat at gmail.com Tue Oct 3 08:07:29 2017 From: ilhanpolat at gmail.com (Ilhan Polat) Date: Tue, 3 Oct 2017 14:07:29 +0200 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: While I agree with Bennet and Matthew, I think the item should sound as much as its importance. If it starts to sound like a Terms and Conditions text it would defeat the purpose in my opinion. I would go along the lines of Help your audience by keeping the discussion focused. Your email will be read by hundreds of people on different media (including search engine hits). Many can only afford to skim through the mails to decide whether the subject is related to their expertise. Placing a brief summary is a good practice if the content does not allow for shortening. On the other hand, this should not be taken as a basis for terseness. "Things should be as simple as possible but not simpler." By the way, I think the numbering is off at item 3. On Tue, Oct 3, 2017 at 1:48 PM, Bennet Fauber wrote: > Matthew, > > Yes, precisely. I think this is in keeping with the desire to provide > a positive tone, suggestive of desired behavior. > > > "Try to help your > > audience; your email will be read by hundreds of people, and many > > people will read only a few lines to decide if they are interested. > > Do you best to get to the point as fast as you can, so people can see > > what the email will be about. It is often useful to put a summary of > > a few lines at the top and then explain your reasoning in more depth > > below, for people who want to learn more." We could point to a few > > good examples. > > I hope this modification gets closer to convergence. > > Help your audience. Your email will be read by hundreds of people. > You may find summarizing at the beginning and providing fuller > explanation of your reasoning below helpful, to yourself as well as > your readers. Many people will scan the first few lines to see if the > message is pertinent to their interests and expertise. Help them and > future readers who may be sifting hundreds of search engine hits. See > for a few select examples. > > > > On Tue, Oct 3, 2017 at 5:13 AM, Matthew Brett > wrote: > > On Tue, Oct 3, 2017 at 12:28 AM, Bennet Fauber wrote: > >> I am more a lurker than a contributor, but I would like to suggest > >> caution with respect to item #5 in the proposed CoC. > >> > >> +5. Be concise. Keep in mind that what you write once will be read by > hundreds > >> + of persons. Writing a short email means people can understand the > >> + conversation as efficiently as possible. Short emails should always > strive > >> + to be empathetic, welcoming, friendly and patient. When a long > explanation > >> + is necessary, consider adding a summary. > >> > >> I suggest that you should stress more that people should strive for > >> clarity and completeness, and then say that brief and comprehensive is > >> the desired goal. I think you're leaning on short too hard, and that > >> will encourage incomplete more than real concision. > >> > >> There are my reasons: 1) one person's concise could well be another's > >> incomplete. 2) There are many, many terms that have more than one > >> use, or that have different meanings in different contexts, or may > >> have connotations; sometimes being concise leads to use of seemingly > >> unambiguous terms that do turn out to be ambiguous. > >> > >> For those who would reply that the definition of 'concise' implies > >> completeness, as in the definition given: > >> > >> giving a lot of information clearly and in a few words; brief but > >> comprehensive. > >> > >> In popular speech, and to those who may have been over-exposed to some > >> kinds of management, concise is more likely to be interpreted as > >> 'abbreviated', which highlights my second point above. I myself often > >> interpret 'concise' to mean 'short' and often 'abbreviated', because > >> that is what I have (alas) become accustomed to in my work > >> environment. > >> > >> Language evolved to have a lot of redundancy built into it for a > >> reason. Stripping it of too much is as bad as including too much. > >> > >> I hope I was sufficiently concise. ;-) > > > > I agree with the general idea. Concise emails can be very > > intimidating, as in "it's so obvious you are wrong I can't be bothered > > to explain why". It's can also be an alienating sign, as in "I'm so > > senior here that there is no need for me to explain my reasoning". > > > > Maybe a better way to put it, is something like "Try to help your > > audience; your email will be read by hundreds of people, and many > > people will read only a few lines to decide if they are interested. > > Do you best to get to the point as fast as you can, so people can see > > what the email will be about. It is often useful to put a summary of > > a few lines at the top and then explain your reasoning in more depth > > below, for people who want to learn more." We could point to a few > > good examples. > > > > Cheers, > > > > Matthew > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Oct 3 08:45:22 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 3 Oct 2017 13:45:22 +0100 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: Hi, On Tue, Oct 3, 2017 at 1:07 PM, Ilhan Polat wrote: > While I agree with Bennet and Matthew, I think the item should sound as much > as its importance. If it starts to sound like a Terms and Conditions text it > would defeat the purpose in my opinion. I would go along the lines of > > Help your audience by keeping the discussion focused. Your email will be > read by hundreds of people on different media (including search engine > hits). Many can only afford to skim through the mails to decide whether the > subject is related to their expertise. Placing a brief summary is a good > practice if the content does not allow for shortening. On the other hand, > this should not be taken as a basis for terseness. "Things should be as > simple as possible but not simpler." > > By the way, I think the numbering is off at item 3. Terms and Conditions is rather in the eye of beholder though. Just for example, if you run these last 3 versions though readable.io you get grade level reading scores (lower = easier to read) of: Me: 4.4 Bennet: 6.6 Ilhan: 9.2 I highly recommend readable.io - I didn't run it on my stuff until just now, but I generally find it gives useful suggestions on improving clarity and readability. Cheers, Matthew From ralf.gommers at gmail.com Tue Oct 3 11:55:37 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 4 Oct 2017 04:55:37 +1300 Subject: [SciPy-Dev] the demise of SciPy Central In-Reply-To: <1506988656.1916094.1125689552.7748F638@webmail.messagingengine.com> References: <1506534155.3734638.1120303936.2A8549F4@webmail.messagingengine.com> <1506988656.1916094.1125689552.7748F638@webmail.messagingengine.com> Message-ID: On Tue, Oct 3, 2017 at 12:57 PM, Stefan van der Walt wrote: > On Thu, Sep 28, 2017, at 00:38, Ralf Gommers wrote: > > > No plan yet. If I'd have to take a stab at it, I'd suggest: > > 1. Put the content (https://github.com/scipy/SciPyCentral#backup-and- > restore) somewhere accessible > 2. Take the last version of each script/notebook, discard the history. > 3. Write some code to transform all of those into notebooks suitable for > inclusion in https://github.com/scipy/scipy-cookbook > 4. Go through by hand, see what's in good shape, and send PRs to > https://github.com/scipy/scipy-cookbook for those. > > That may be quite a bit of work though. At least (1) should be done before > decommissioning the server. > > > This is a perfect student project; I'm going to try and find someone to > work on it. > That would be awesome! @Pauli/Surya: can one of you do (1)? I think you're the only ones with server access? Cheers, Ralf > Thanks for this outline, > > St?fan > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilhanpolat at gmail.com Tue Oct 3 11:16:07 2017 From: ilhanpolat at gmail.com (Ilhan Polat) Date: Tue, 3 Oct 2017 17:16:07 +0200 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: Ah come on. What is this condescending nonsense "A score of around 10-12 is roughly the reading level on completion of high school. Text to be read by the general public should aim for a grade level of around 8."? On Tue, Oct 3, 2017 at 2:45 PM, Matthew Brett wrote: > Hi, > > On Tue, Oct 3, 2017 at 1:07 PM, Ilhan Polat wrote: > > While I agree with Bennet and Matthew, I think the item should sound as > much > > as its importance. If it starts to sound like a Terms and Conditions > text it > > would defeat the purpose in my opinion. I would go along the lines of > > > > Help your audience by keeping the discussion focused. Your email will be > > read by hundreds of people on different media (including search engine > > hits). Many can only afford to skim through the mails to decide whether > the > > subject is related to their expertise. Placing a brief summary is a good > > practice if the content does not allow for shortening. On the other hand, > > this should not be taken as a basis for terseness. "Things should be as > > simple as possible but not simpler." > > > > By the way, I think the numbering is off at item 3. > > Terms and Conditions is rather in the eye of beholder though. > > Just for example, if you run these last 3 versions though readable.io > you get grade level reading scores (lower = easier to read) of: > > Me: 4.4 > Bennet: 6.6 > Ilhan: 9.2 > > I highly recommend readable.io - I didn't run it on my stuff until > just now, but I generally find it gives useful suggestions on > improving clarity and readability. > > Cheers, > > Matthew > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Oct 3 12:26:39 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 3 Oct 2017 17:26:39 +0100 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: On Tue, Oct 3, 2017 at 4:16 PM, Ilhan Polat wrote: > Ah come on. What is this condescending nonsense "A score of around 10-12 is > roughly the reading level on completion of high school. Text to be read by > the general public should aim for a grade level of around 8."? I am sorry, I didn't mean it to be condescending. I just mean that most people feel that text they write is clearer than text other people write, on average, for the obvious reason that we tend to understand the things that we say better than things other people say. So I wasn't claiming that the metrics made my text better than your text, only that it's difficult to be objective about what is clear - or - as you said - what reads like "terms and conditions". As for the grade level - have a look at the comments that readability.io gives - it's good advice about avoiding long words and long sentences if possible (it usually is) and the passive tense. Text with a low grade level, when well written, does not seem patronizing, but is easy to read and say - conveying the same meaning with less effort to the reader. Best, Matthew From ilhanpolat at gmail.com Tue Oct 3 13:47:48 2017 From: ilhanpolat at gmail.com (Ilhan Polat) Date: Tue, 3 Oct 2017 19:47:48 +0200 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: I guess my second mail didn't make it to the server for some reason. I've written: "I should have probably put a smiley in the end. I mean it quite lightly by the way. " No problem at all, Matthew for one I'm not a native speaker and second you guys probably have seen more conflicts than I ever did. I just wanted to have the text a bit less formal. Best, On Tue, Oct 3, 2017 at 6:26 PM, Matthew Brett wrote: > On Tue, Oct 3, 2017 at 4:16 PM, Ilhan Polat wrote: > > Ah come on. What is this condescending nonsense "A score of around 10-12 > is > > roughly the reading level on completion of high school. Text to be read > by > > the general public should aim for a grade level of around 8."? > > I am sorry, I didn't mean it to be condescending. I just mean that > most people feel that text they write is clearer than text other > people write, on average, for the obvious reason that we tend to > understand the things that we say better than things other people say. > So I wasn't claiming that the metrics made my text better than your > text, only that it's difficult to be objective about what is clear - > or - as you said - what reads like "terms and conditions". > > As for the grade level - have a look at the comments that > readability.io gives - it's good advice about avoiding long words and > long sentences if possible (it usually is) and the passive tense. > Text with a low grade level, when well written, does not seem > patronizing, but is easy to read and say - conveying the same meaning > with less effort to the reader. > > Best, > > Matthew > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Oct 3 13:51:59 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 3 Oct 2017 18:51:59 +0100 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: Hi, On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat wrote: > I guess my second mail didn't make it to the server for some reason. I've > written: > > "I should have probably put a smiley in the end. I mean it quite lightly by > the way. " > > No problem at all, Matthew for one I'm not a native speaker and second you > guys probably have seen more conflicts than I ever did. I just wanted to > have the text a bit less formal. Sure - no problem from my side - I completely agree that less formal is better ... Cheers, Matthew From ilhanpolat at gmail.com Tue Oct 3 11:17:12 2017 From: ilhanpolat at gmail.com (Ilhan Polat) Date: Tue, 3 Oct 2017 17:17:12 +0200 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: I should have probably put a smiley in the end. I mean it quite lightly by the way. On Tue, Oct 3, 2017 at 5:16 PM, Ilhan Polat wrote: > Ah come on. What is this condescending nonsense "A score of around 10-12 > is roughly the reading level on completion of high school. Text to be read > by the general public should aim for a grade level of around 8."? > > On Tue, Oct 3, 2017 at 2:45 PM, Matthew Brett > wrote: > >> Hi, >> >> On Tue, Oct 3, 2017 at 1:07 PM, Ilhan Polat wrote: >> > While I agree with Bennet and Matthew, I think the item should sound as >> much >> > as its importance. If it starts to sound like a Terms and Conditions >> text it >> > would defeat the purpose in my opinion. I would go along the lines of >> > >> > Help your audience by keeping the discussion focused. Your email will be >> > read by hundreds of people on different media (including search engine >> > hits). Many can only afford to skim through the mails to decide whether >> the >> > subject is related to their expertise. Placing a brief summary is a good >> > practice if the content does not allow for shortening. On the other >> hand, >> > this should not be taken as a basis for terseness. "Things should be as >> > simple as possible but not simpler." >> > >> > By the way, I think the numbering is off at item 3. >> >> Terms and Conditions is rather in the eye of beholder though. >> >> Just for example, if you run these last 3 versions though readable.io >> you get grade level reading scores (lower = easier to read) of: >> >> Me: 4.4 >> Bennet: 6.6 >> Ilhan: 9.2 >> >> I highly recommend readable.io - I didn't run it on my stuff until >> just now, but I generally find it gives useful suggestions on >> improving clarity and readability. >> >> Cheers, >> >> Matthew >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.barbry at mailoo.org Wed Oct 4 09:45:01 2017 From: marc.barbry at mailoo.org (marc) Date: Wed, 4 Oct 2017 15:45:01 +0200 Subject: [SciPy-Dev] wrapper for Scalapack Message-ID: Dear Scipy developers, We are actually writing a python wrapper for Scalapack that seems to be cruelly missing for computational science with Python. Since Scipy has already wrappers for Blas and Lapack library we are hoping that you could be interested as well in a Scalapack wrapper. In this aim, we used f2py to wrap the routine as it is done in the Blas/Lapack wrapper of Scipy. The actual code can be found in the following repository, https://gitlab.com/mbarbry/python-scalapack Since the project just started, only few routines are implemented, but we manage to write a working test with sygv routine. We would like to know if the Scipy community would be interested to merge this wrapper in the Scipy code in the future? We believe that Scalapack is an important part of the Scientific tools for linear algebra, and that Scipy would only benefit of such wrapper as well than the Scientific community. Contributions to the code are obviously more than welcome. Best regards, Marc Barbry From josh.craig.wilson at gmail.com Wed Oct 4 10:59:01 2017 From: josh.craig.wilson at gmail.com (Joshua Wilson) Date: Wed, 4 Oct 2017 09:59:01 -0500 Subject: [SciPy-Dev] wrapper for Scalapack In-Reply-To: References: Message-ID: Just off the cuff I'd guess that the BLACS dependency would make it very difficult to support Scalapack in SciPy proper. On Wed, Oct 4, 2017 at 8:45 AM, marc wrote: > Dear Scipy developers, > > We are actually writing a python wrapper for Scalapack that seems to be > cruelly missing for computational science with Python. > Since Scipy has already wrappers for Blas and Lapack library we are hoping > that you could be interested as well in a Scalapack wrapper. > In this aim, we used f2py to wrap the routine as it is done in the > Blas/Lapack wrapper of Scipy. > > The actual code can be found in the following repository, > https://gitlab.com/mbarbry/python-scalapack > > Since the project just started, only few routines are implemented, but we > manage to write a working test with sygv routine. > We would like to know if the Scipy community would be interested to merge > this wrapper in the Scipy code in the future? > > We believe that Scalapack is an important part of the Scientific tools for > linear algebra, and that Scipy would only benefit of such wrapper as well > than the Scientific community. > Contributions to the code are obviously more than welcome. > > Best regards, > Marc Barbry > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev From marc.barbry at mailoo.org Wed Oct 4 11:17:45 2017 From: marc.barbry at mailoo.org (marc) Date: Wed, 4 Oct 2017 17:17:45 +0200 Subject: [SciPy-Dev] [gpaw-users] wrapper for Scalapack In-Reply-To: References: Message-ID: <57d2d270-9083-e1d6-6ed9-21de7f872154@mailoo.org> I guess this problem of dependency could be avoid with a custom installation. MPI code could be compile only if specify, in a similar fashion than the mkl library for Blas/Lapack wrappers. On 10/04/2017 04:59 PM, Joshua Wilson via gpaw-users wrote: > Just off the cuff I'd guess that the BLACS dependency would make it > very difficult to support Scalapack in SciPy proper. > > On Wed, Oct 4, 2017 at 8:45 AM, marc wrote: >> Dear Scipy developers, >> >> We are actually writing a python wrapper for Scalapack that seems to be >> cruelly missing for computational science with Python. >> Since Scipy has already wrappers for Blas and Lapack library we are hoping >> that you could be interested as well in a Scalapack wrapper. >> In this aim, we used f2py to wrap the routine as it is done in the >> Blas/Lapack wrapper of Scipy. >> >> The actual code can be found in the following repository, >> https://gitlab.com/mbarbry/python-scalapack >> >> Since the project just started, only few routines are implemented, but we >> manage to write a working test with sygv routine. >> We would like to know if the Scipy community would be interested to merge >> this wrapper in the Scipy code in the future? >> >> We believe that Scalapack is an important part of the Scientific tools for >> linear algebra, and that Scipy would only benefit of such wrapper as well >> than the Scientific community. >> Contributions to the code are obviously more than welcome. >> >> Best regards, >> Marc Barbry >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev > _______________________________________________ > gpaw-users mailing list > gpaw-users at listserv.fysik.dtu.dk > https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users From kasturi.surya at gmail.com Wed Oct 4 14:30:49 2017 From: kasturi.surya at gmail.com (Surya) Date: Wed, 4 Oct 2017 14:30:49 -0400 Subject: [SciPy-Dev] the demise of SciPy Central In-Reply-To: References: <1506534155.3734638.1120303936.2A8549F4@webmail.messagingengine.com> <1506988656.1916094.1125689552.7748F638@webmail.messagingengine.com> Message-ID: Hi guys, I can share database dump or access to the server platform. Let me see if I can bring back the site up. Reasons for server down: uWSGi is too long to respond and aborting its threads. I suspect version incompatibilities with the latest uWSGI and OpenSSL (our codebase uses older libraries for almost everything). I agree that the landscape has changed. Many people post GitHub gists instead of code on SciPy Central. SciPy Planet, Cookbook appears to have more interesting content. Thanks Surya On Tue, Oct 3, 2017 at 11:55 AM, Ralf Gommers wrote: > > > On Tue, Oct 3, 2017 at 12:57 PM, Stefan van der Walt > wrote: > >> On Thu, Sep 28, 2017, at 00:38, Ralf Gommers wrote: >> >> >> No plan yet. If I'd have to take a stab at it, I'd suggest: >> >> 1. Put the content (https://github.com/scipy/SciP >> yCentral#backup-and-restore) somewhere accessible >> 2. Take the last version of each script/notebook, discard the history. >> 3. Write some code to transform all of those into notebooks suitable for >> inclusion in https://github.com/scipy/scipy-cookbook >> 4. Go through by hand, see what's in good shape, and send PRs to >> https://github.com/scipy/scipy-cookbook for those. >> >> That may be quite a bit of work though. At least (1) should be done >> before decommissioning the server. >> >> >> This is a perfect student project; I'm going to try and find someone to >> work on it. >> > > That would be awesome! > > @Pauli/Surya: can one of you do (1)? I think you're the only ones with > server access? > > Cheers, > Ralf > > > >> Thanks for this outline, >> >> St?fan >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Thu Oct 5 01:48:06 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 5 Oct 2017 18:48:06 +1300 Subject: [SciPy-Dev] the demise of SciPy Central In-Reply-To: References: <1506534155.3734638.1120303936.2A8549F4@webmail.messagingengine.com> <1506988656.1916094.1125689552.7748F638@webmail.messagingengine.com> Message-ID: On Thu, Oct 5, 2017 at 7:30 AM, Surya wrote: > Hi guys, > > I can share database dump or access to the server platform. Let me see if > I can bring back the site up. > Awesome, thanks Surya. Ralf > Reasons for server down: uWSGi is too long to respond and aborting its > threads. > I suspect version incompatibilities with the latest uWSGI and OpenSSL (our > codebase uses older libraries for almost everything). > > I agree that the landscape has changed. Many people post GitHub gists > instead of code on SciPy Central. SciPy Planet, Cookbook appears to have > more interesting content. > > Thanks > Surya > > On Tue, Oct 3, 2017 at 11:55 AM, Ralf Gommers > wrote: > >> >> >> On Tue, Oct 3, 2017 at 12:57 PM, Stefan van der Walt < >> stefanv at berkeley.edu> wrote: >> >>> On Thu, Sep 28, 2017, at 00:38, Ralf Gommers wrote: >>> >>> >>> No plan yet. If I'd have to take a stab at it, I'd suggest: >>> >>> 1. Put the content (https://github.com/scipy/SciP >>> yCentral#backup-and-restore) somewhere accessible >>> 2. Take the last version of each script/notebook, discard the history. >>> 3. Write some code to transform all of those into notebooks suitable for >>> inclusion in https://github.com/scipy/scipy-cookbook >>> 4. Go through by hand, see what's in good shape, and send PRs to >>> https://github.com/scipy/scipy-cookbook for those. >>> >>> That may be quite a bit of work though. At least (1) should be done >>> before decommissioning the server. >>> >>> >>> This is a perfect student project; I'm going to try and find someone to >>> work on it. >>> >> >> That would be awesome! >> >> @Pauli/Surya: can one of you do (1)? I think you're the only ones with >> server access? >> >> Cheers, >> Ralf >> >> >> >>> Thanks for this outline, >>> >>> St?fan >>> >>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >>> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Thu Oct 5 13:42:47 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 6 Oct 2017 06:42:47 +1300 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett wrote: > Hi, > > On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat wrote: > > I guess my second mail didn't make it to the server for some reason. I've > > written: > > > > "I should have probably put a smiley in the end. I mean it quite lightly > by > > the way. " > > > > No problem at all, Matthew for one I'm not a native speaker and second > you > > guys probably have seen more conflicts than I ever did. I just wanted to > > have the text a bit less formal. > > Sure - no problem from my side - I completely agree that less formal > is better ... > Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be misunderstood if not worded right. Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to me, and less tied to principles. Consider cutting for the sake of brevity?". I think that's a good point, so would like to go with that. It also means we don't have to choose between your three versions of point 5:) Cheers, Ralf > Cheers, > > Matthew > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Thu Oct 5 13:54:40 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 6 Oct 2017 06:54:40 +1300 Subject: [SciPy-Dev] [gpaw-users] wrapper for Scalapack In-Reply-To: <57d2d270-9083-e1d6-6ed9-21de7f872154@mailoo.org> References: <57d2d270-9083-e1d6-6ed9-21de7f872154@mailoo.org> Message-ID: On Thu, Oct 5, 2017 at 4:17 AM, marc wrote: > I guess this problem of dependency could be avoid with a custom > installation. > MPI code could be compile only if specify, in a similar fashion than the > mkl library for Blas/Lapack wrappers. There's a major difference there: MKL is optional, but BLAS/LAPACK is not. We require a BLAS/LAPACK install, the implementations can be switched out. For ScaLAPACK it seems pretty clear we can't require it to be installed. Moreover, distributed computing is out of scope for SciPy. So developing your ScaLAPACK wrappers (which do seem very useful indeed) as a separate package looks like the better way to go. Cheers, Ralf > > On 10/04/2017 04:59 PM, Joshua Wilson via gpaw-users wrote: > >> Just off the cuff I'd guess that the BLACS dependency would make it >> very difficult to support Scalapack in SciPy proper. >> >> On Wed, Oct 4, 2017 at 8:45 AM, marc wrote: >> >>> Dear Scipy developers, >>> >>> We are actually writing a python wrapper for Scalapack that seems to be >>> cruelly missing for computational science with Python. >>> Since Scipy has already wrappers for Blas and Lapack library we are >>> hoping >>> that you could be interested as well in a Scalapack wrapper. >>> In this aim, we used f2py to wrap the routine as it is done in the >>> Blas/Lapack wrapper of Scipy. >>> >>> The actual code can be found in the following repository, >>> https://gitlab.com/mbarbry/python-scalapack >>> >>> Since the project just started, only few routines are implemented, but we >>> manage to write a working test with sygv routine. >>> We would like to know if the Scipy community would be interested to merge >>> this wrapper in the Scipy code in the future? >>> >>> We believe that Scalapack is an important part of the Scientific tools >>> for >>> linear algebra, and that Scipy would only benefit of such wrapper as well >>> than the Scientific community. >>> Contributions to the code are obviously more than welcome. >>> >>> Best regards, >>> Marc Barbry >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >> _______________________________________________ >> gpaw-users mailing list >> gpaw-users at listserv.fysik.dtu.dk >> https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Thu Oct 5 14:05:36 2017 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 5 Oct 2017 14:05:36 -0400 Subject: [SciPy-Dev] [gpaw-users] wrapper for Scalapack In-Reply-To: References: <57d2d270-9083-e1d6-6ed9-21de7f872154@mailoo.org> Message-ID: On Thu, Oct 5, 2017 at 1:54 PM, Ralf Gommers wrote: > > > On Thu, Oct 5, 2017 at 4:17 AM, marc wrote: > >> I guess this problem of dependency could be avoid with a custom >> installation. >> MPI code could be compile only if specify, in a similar fashion than the >> mkl library for Blas/Lapack wrappers. > > > There's a major difference there: MKL is optional, but BLAS/LAPACK is not. > We require a BLAS/LAPACK install, the implementations can be switched out. > > For ScaLAPACK it seems pretty clear we can't require it to be installed. > Moreover, distributed computing is out of scope for SciPy. So developing > your ScaLAPACK wrappers (which do seem very useful indeed) as a separate > package looks like the better way to go. > But does distributed computing stay out of scope for SciPy after 1.0? As a long term plan towards 2.0? (Not that MPI based solutions will help much on Windows, AFAICS.) Josef > > Cheers, > Ralf > > >> >> On 10/04/2017 04:59 PM, Joshua Wilson via gpaw-users wrote: >> >>> Just off the cuff I'd guess that the BLACS dependency would make it >>> very difficult to support Scalapack in SciPy proper. >>> >>> On Wed, Oct 4, 2017 at 8:45 AM, marc wrote: >>> >>>> Dear Scipy developers, >>>> >>>> We are actually writing a python wrapper for Scalapack that seems to be >>>> cruelly missing for computational science with Python. >>>> Since Scipy has already wrappers for Blas and Lapack library we are >>>> hoping >>>> that you could be interested as well in a Scalapack wrapper. >>>> In this aim, we used f2py to wrap the routine as it is done in the >>>> Blas/Lapack wrapper of Scipy. >>>> >>>> The actual code can be found in the following repository, >>>> https://gitlab.com/mbarbry/python-scalapack >>>> >>>> Since the project just started, only few routines are implemented, but >>>> we >>>> manage to write a working test with sygv routine. >>>> We would like to know if the Scipy community would be interested to >>>> merge >>>> this wrapper in the Scipy code in the future? >>>> >>>> We believe that Scalapack is an important part of the Scientific tools >>>> for >>>> linear algebra, and that Scipy would only benefit of such wrapper as >>>> well >>>> than the Scientific community. >>>> Contributions to the code are obviously more than welcome. >>>> >>>> Best regards, >>>> Marc Barbry >>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev at python.org >>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>> >>> _______________________________________________ >>> gpaw-users mailing list >>> gpaw-users at listserv.fysik.dtu.dk >>> https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users >>> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Oct 5 14:05:52 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 5 Oct 2017 19:05:52 +0100 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: On Thu, Oct 5, 2017 at 6:42 PM, Ralf Gommers wrote: > > > On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett > wrote: >> >> Hi, >> >> On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat wrote: >> > I guess my second mail didn't make it to the server for some reason. >> > I've >> > written: >> > >> > "I should have probably put a smiley in the end. I mean it quite lightly >> > by >> > the way. " >> > >> > No problem at all, Matthew for one I'm not a native speaker and second >> > you >> > guys probably have seen more conflicts than I ever did. I just wanted to >> > have the text a bit less formal. >> >> Sure - no problem from my side - I completely agree that less formal >> is better ... > > > Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be > misunderstood if not worded right. > > Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to me, > and less tied to principles. Consider cutting for the sake of brevity?". > I think that's a good point, so would like to go with that. It also means we > don't have to choose between your three versions of point 5:) Excellent outcome - more concise :) Cheers, Matthew From ralf.gommers at gmail.com Thu Oct 5 14:36:17 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 6 Oct 2017 07:36:17 +1300 Subject: [SciPy-Dev] [gpaw-users] wrapper for Scalapack In-Reply-To: References: <57d2d270-9083-e1d6-6ed9-21de7f872154@mailoo.org> Message-ID: On Fri, Oct 6, 2017 at 7:05 AM, wrote: > > > On Thu, Oct 5, 2017 at 1:54 PM, Ralf Gommers > wrote: > >> >> >> On Thu, Oct 5, 2017 at 4:17 AM, marc wrote: >> >>> I guess this problem of dependency could be avoid with a custom >>> installation. >>> MPI code could be compile only if specify, in a similar fashion than the >>> mkl library for Blas/Lapack wrappers. >> >> >> There's a major difference there: MKL is optional, but BLAS/LAPACK is >> not. We require a BLAS/LAPACK install, the implementations can be switched >> out. >> >> For ScaLAPACK it seems pretty clear we can't require it to be installed. >> Moreover, distributed computing is out of scope for SciPy. So developing >> your ScaLAPACK wrappers (which do seem very useful indeed) as a separate >> package looks like the better way to go. >> > > > But does distributed computing stay out of scope for SciPy after 1.0? > As a long term plan towards 2.0? > Such changes are worth discussing once in a while, usually sharpens the focus:) My first thoughts: - traditional stuff like MPI, BLACS, ScaLAPACK will likely always remain out of scope - we can consider new dependencies, but only if they do not make it harder to install SciPy - a few more likely changes would be to start allowing/supporting pandas data frames as inputs, broader use of simple (optional) parallelization with joblib or threading, and using dask under the hood. Ralf > (Not that MPI based solutions will help much on Windows, AFAICS.) > > Josef > > >> >> Cheers, >> Ralf >> >> >>> >>> On 10/04/2017 04:59 PM, Joshua Wilson via gpaw-users wrote: >>> >>>> Just off the cuff I'd guess that the BLACS dependency would make it >>>> very difficult to support Scalapack in SciPy proper. >>>> >>>> On Wed, Oct 4, 2017 at 8:45 AM, marc wrote: >>>> >>>>> Dear Scipy developers, >>>>> >>>>> We are actually writing a python wrapper for Scalapack that seems to be >>>>> cruelly missing for computational science with Python. >>>>> Since Scipy has already wrappers for Blas and Lapack library we are >>>>> hoping >>>>> that you could be interested as well in a Scalapack wrapper. >>>>> In this aim, we used f2py to wrap the routine as it is done in the >>>>> Blas/Lapack wrapper of Scipy. >>>>> >>>>> The actual code can be found in the following repository, >>>>> https://gitlab.com/mbarbry/python-scalapack >>>>> >>>>> Since the project just started, only few routines are implemented, but >>>>> we >>>>> manage to write a working test with sygv routine. >>>>> We would like to know if the Scipy community would be interested to >>>>> merge >>>>> this wrapper in the Scipy code in the future? >>>>> >>>>> We believe that Scalapack is an important part of the Scientific tools >>>>> for >>>>> linear algebra, and that Scipy would only benefit of such wrapper as >>>>> well >>>>> than the Scientific community. >>>>> Contributions to the code are obviously more than welcome. >>>>> >>>>> Best regards, >>>>> Marc Barbry >>>>> _______________________________________________ >>>>> SciPy-Dev mailing list >>>>> SciPy-Dev at python.org >>>>> https://mail.python.org/mailman/listinfo/scipy-dev >>>>> >>>> _______________________________________________ >>>> gpaw-users mailing list >>>> gpaw-users at listserv.fysik.dtu.dk >>>> https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users >>>> >>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haberland at ucla.edu Thu Oct 5 15:01:36 2017 From: haberland at ucla.edu (Matt Haberland) Date: Thu, 5 Oct 2017 12:01:36 -0700 Subject: [SciPy-Dev] support for solving integer programming problems In-Reply-To: References: Message-ID: Yes. I wrote the new interior point method for linprog because the existing simplex implementation was having trouble with relaxed LPs from my (branch and bound) binary integer LP solver. The BILP solver is basically ready for a PR, but some suggested that I should shoot for a full mixed integer LP solver before submitting. I did plan to work on this. You interested, Phillip? Matt On Sep 29, 2017 8:32 PM, "Phillip Feldman" wrote: I'm wondering whether anyone has been thinking of adding capability to `scipy.optimize` for solving low-dimensionality integer programming problems. In particular, I'm thinking of such methods as local search or tabu search. Phillip _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Thu Oct 5 15:24:21 2017 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 05 Oct 2017 21:24:21 +0200 Subject: [SciPy-Dev] [Numpy-discussion] Sustainability In-Reply-To: References: <1507131114.14730.6.camel@gmail.com> Message-ID: <1507231461.2367.19.camel@iki.fi> to, 2017-10-05 kello 00:08 +0200, Ilhan Polat kirjoitti: [clip] > 2. Feature completeness of basic modules. I think those judgments can be subjective, but it is true many things have been organically grown, and this becomes even more so as the number of contributors grows (fielding other people's PRs already takes a lot of time). I think most people send something that they need there and then, and it is not possible to tell them to go do something else instead. So even if there are many contributors, it's less clear how available they are for implementing "the plan". Regardless, I would recommend anyone who knows something obvious is missing that obviously should be included, to send a PR adding it to the roadmap: https://github.com/scipy/scipy/blob/master/doc/ROADMAP.rst.txt This document has not really been updated significantly since the single brainstorm in a Scipy conference many years ago, and we did not go through the contents then in great detail. Pauli From ralf.gommers at gmail.com Thu Oct 5 17:14:15 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 6 Oct 2017 10:14:15 +1300 Subject: [SciPy-Dev] [Numpy-discussion] Sustainability In-Reply-To: <1507231461.2367.19.camel@iki.fi> References: <1507131114.14730.6.camel@gmail.com> <1507231461.2367.19.camel@iki.fi> Message-ID: On Fri, Oct 6, 2017 at 8:24 AM, Pauli Virtanen wrote: > to, 2017-10-05 kello 00:08 +0200, Ilhan Polat kirjoitti: > [clip] > > 2. Feature completeness of basic modules. > > I think those judgments can be subjective, but it is true many things > have been organically grown, and this becomes even more so as the > number of contributors grows (fielding other people's PRs already takes > a lot of time). I think most people send something that they need there > and then, and it is not possible to tell them to go do something else > instead. So even if there are many contributors, it's less clear how > available they are for implementing "the plan". > > Regardless, I would recommend anyone who knows something obvious is > missing that obviously should be included, to send a PR adding it to > the roadmap: > > https://github.com/scipy/scipy/blob/master/doc/ROADMAP.rst.txt > > This document has not really been updated significantly since the > single brainstorm in a Scipy conference many years ago, and we did not > go through the contents then in great detail. > I did update it several times, removing things that were implemented or no longer relevant. However you're right that especially on the new features front it could use more inputs. Ralf > Pauli > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillip.m.feldman at gmail.com Fri Oct 6 01:19:36 2017 From: phillip.m.feldman at gmail.com (Phillip Feldman) Date: Thu, 5 Oct 2017 22:19:36 -0700 Subject: [SciPy-Dev] support for solving integer programming problems In-Reply-To: References: Message-ID: I am. On Thu, Oct 5, 2017 at 12:01 PM, Matt Haberland wrote: > Yes. I wrote the new interior point method for linprog because the > existing simplex implementation was having trouble with relaxed LPs from my > (branch and bound) binary integer LP solver. The BILP solver is basically > ready for a PR, but some suggested that I should shoot for a full mixed > integer LP solver before submitting. I did plan to work on this. You > interested, Phillip? > > Matt > > > > On Sep 29, 2017 8:32 PM, "Phillip Feldman" > wrote: > > I'm wondering whether anyone has been thinking of adding capability to > `scipy.optimize` for solving low-dimensionality integer programming > problems. In particular, I'm thinking of such methods as local search or > tabu search. > > > Phillip > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peridot.faceted at gmail.com Fri Oct 6 05:37:30 2017 From: peridot.faceted at gmail.com (Anne Archibald) Date: Fri, 06 Oct 2017 09:37:30 +0000 Subject: [SciPy-Dev] [gpaw-users] wrapper for Scalapack In-Reply-To: References: <57d2d270-9083-e1d6-6ed9-21de7f872154@mailoo.org> Message-ID: On Thu, Oct 5, 2017 at 8:36 PM Ralf Gommers wrote: > On Fri, Oct 6, 2017 at 7:05 AM, wrote: > >> >> But does distributed computing stay out of scope for SciPy after 1.0? >> As a long term plan towards 2.0? >> > > Such changes are worth discussing once in a while, usually sharpens the > focus:) > > My first thoughts: > - traditional stuff like MPI, BLACS, ScaLAPACK will likely always remain > out of scope > - we can consider new dependencies, but only if they do not make it harder > to install SciPy > - a few more likely changes would be to start allowing/supporting pandas > data frames as inputs, broader use of simple (optional) parallelization > with joblib or threading, and using dask under the hood. > There seems to be a profusion of tools for parallelization, so choosing just one to use as a basis for scipy's parallelization could be really frustrating for users who have a reason to need a different one. The exception, I would say, is the concurrent.futures interface. This is part of python (3), and it allows a limited but manageable and useful amount of parallelization. It is also an interface other tools can and do implement. For example, emcee is capable of taking advantage of parallelization, but that parallelization happens entirely in one place: a map is done to compute log-probabilities for a list of candidates. emcee is agnostic about how this map works; by default it can use python's built-in map, but emcee provides an "MPIPool" object that supplies a parallel map that uses MPI, python's ThreadPoolExecutor and ProcessPoolExecutor also provide such a parallel map, and (for example) dask provides an Executor interface that allows such a map across a collection of dask instances. So: I think it would be good if scipy could incorporate the use of Executors to achieve parallelism where that's available from the underlying algorithms. From the user's point of view, this just means one or two more optional arguments, in particular a "pool" argument from which futures are generated. In turn, it might make sense to implement a few new algorithms that can use parallelism effectively. The global optimizers spring to mind as candidates for this process, but in fact any local optimizer that needs a gradient but has to compute it numerically can probably benefit from computing the derivative in parallel. This sort of opportunistic parallelization is no substitute for something like Scalapack or PaGMO, dedicated distributed computing algorithms, but it is a way for scipy to allow easy parallelization where possible. Anne -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffmanvillejr at gmail.com Fri Oct 6 13:04:03 2017 From: jeffmanvillejr at gmail.com (Jeffrey Manville) Date: Fri, 6 Oct 2017 13:04:03 -0400 Subject: [SciPy-Dev] support for solving integer programming problems Message-ID: I would also be interested in contributing to this. I have some classwork experience with IP and at the least would enjoy contributing more testing. Jeff >I am. > >On Thu, Oct 5, 2017 at 12:01 PM, Matt Haberland wrote: > >> Yes. I wrote the new interior point method for linprog because the >> existing simplex implementation was having trouble with relaxed LPs from my >> (branch and bound) binary integer LP solver. The BILP solver is basically >> ready for a PR, but some suggested that I should shoot for a full mixed >> integer LP solver before submitting. I did plan to work on this. You >> interested, Phillip? >> >> Matt >> >> >> >> On Sep 29, 2017 8:32 PM, "Phillip Feldman" >> wrote: >> >> I'm wondering whether anyone has been thinking of adding capability to >> `scipy.optimize` for solving low-dimensionality integer programming >> problems. In particular, I'm thinking of such methods as local search or >> tabu search. >> >> >> Phillip -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillip.m.feldman at gmail.com Fri Oct 6 21:30:31 2017 From: phillip.m.feldman at gmail.com (Phillip Feldman) Date: Fri, 6 Oct 2017 18:30:31 -0700 Subject: [SciPy-Dev] support for solving integer programming problems In-Reply-To: References: Message-ID: For this specific problem, I might not be qualified to develop, but should be able to test. On Fri, Oct 6, 2017 at 10:04 AM, Jeffrey Manville wrote: > I would also be interested in contributing to this. I have some classwork > experience with IP and at the least would enjoy contributing more testing. > > Jeff > > >I am. > > > >On Thu, Oct 5, 2017 at 12:01 PM, Matt Haberland > wrote: > > > >> Yes. I wrote the new interior point method for linprog because the > >> existing simplex implementation was having trouble with relaxed LPs > from my > >> (branch and bound) binary integer LP solver. The BILP solver is > basically > >> ready for a PR, but some suggested that I should shoot for a full mixed > >> integer LP solver before submitting. I did plan to work on this. You > >> interested, Phillip? > >> > >> Matt > >> > >> > >> > >> On Sep 29, 2017 8:32 PM, "Phillip Feldman" > > >> wrote: > >> > >> I'm wondering whether anyone has been thinking of adding capability to > >> `scipy.optimize` for solving low-dimensionality integer programming > >> problems. In particular, I'm thinking of such methods as local search > or > >> tabu search. > >> > >> > >> Phillip > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Mon Oct 9 16:41:42 2017 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 09 Oct 2017 22:41:42 +0200 Subject: [SciPy-Dev] [Numpy-discussion] Sustainability In-Reply-To: References: <1507131114.14730.6.camel@gmail.com> <1507231461.2367.19.camel@iki.fi> Message-ID: <1507581702.2592.14.camel@iki.fi> pe, 2017-10-06 kello 10:14 +1300, Ralf Gommers kirjoitti: [clip] > > https://github.com/scipy/scipy/blob/master/doc/ROADMAP.rst.txt > > > > This document has not really been updated significantly since the > > single brainstorm in a Scipy conference many years ago, and we did > > not > > go through the contents then in great detail. > > > > I did update it several times, removing things that were implemented > or no > longer relevant. However you're right that especially on the new > features > front it could use more inputs. Sorry, I should have checked my memory before writing. Maybe the more correct statement is that I haven't remembered to update it... Pauli From neuhaus at spectro.jussieu.fr Tue Oct 10 08:24:16 2017 From: neuhaus at spectro.jussieu.fr (Leonhard Neuhaus) Date: Tue, 10 Oct 2017 14:24:16 +0200 Subject: [SciPy-Dev] scipy.signal.residue function - extension to z, p, k input Message-ID: <55bbf428-f3d3-7a6c-a8f8-6b4f16bb012d@spectro.jussieu.fr> Hi all, I have written a function residues() which does the same as scipy.signal.residue, but that accepts an input in the form (zeros, poles, k) - k is the global prefactor - instead of the usual (b, a)-Polynomial form of the transfer function to transform. This was necessary since I wanted to do the partial fraction expansion of an transfer function of roughly 10th order (given in the zero-pole-form) and numerical imprecision issues prevented me from passing through the (b, a)-form. The partial fraction expansion was necessary in my case to decompose the transfer function into parallel biquads (opposed to the more common serial biquad decomposition). The way I implemented the transformation can be found here: https://github.com/lneuhaus/pyrpl/blob/55cb112a50e221f11eb28f106ba11272890c3b7f/pyrpl/hardware_modules/iir/iir_theory.py#L145 This implementation does not suffer from the typical numerical imprecision issues associated with higher-order polynomials since the coefficients (i.e. the prefactors of x^n in the numerator/denominator of the transfer function) are never explicitly calculated. I would be happy to prepare a proper pull-request that extends the residue function with the (zero, pole, k)-input option if this is desired. Please let me know and I will get to work. Cheers, Leo From antoniy.py at gmail.com Wed Oct 11 13:35:01 2017 From: antoniy.py at gmail.com (Ant) Date: Wed, 11 Oct 2017 19:35:01 +0200 Subject: [SciPy-Dev] Hide real name on mail list Message-ID: <16bbfa19-92ed-4e87-9edf-951a7796e8f0@Spark> Hi, I have recently sent an email to the scipy-user mailing list, and my real name was displayed, even if I made sure to set my username to something else during the subscription process. I would really like this to be changed; my real name to be removed and the made-up username to be shown instead (or nothing!). I find it confusing to choose a username that is not displayed anywhere, displaying instead my real name taken from the email account. I would really appreciate it if you could remove my name from the previous post. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilhanpolat at gmail.com Wed Oct 11 19:03:07 2017 From: ilhanpolat at gmail.com (Ilhan Polat) Date: Thu, 12 Oct 2017 01:03:07 +0200 Subject: [SciPy-Dev] Hide real name on mail list In-Reply-To: <16bbfa19-92ed-4e87-9edf-951a7796e8f0@Spark> References: <16bbfa19-92ed-4e87-9edf-951a7796e8f0@Spark> Message-ID: It's because of the email address you are using includes your info in the header. Please also use an anonymous email address for which you haven't filled in your personal details (if this is a concern). Best Ilhan On Oct 11, 2017 21:37, "Ant" wrote: > Hi, > > I have recently sent an email to the scipy-user mailing list, and my real > name was displayed, even if I made sure to set my username to something > else during the subscription process. > > I would really like this to be changed; my real name to be removed and the > made-up username to be shown instead (or nothing!). I find it confusing to > choose a username that is not displayed anywhere, displaying instead my > real name taken from the email account. > > I would really appreciate it if you could remove my name from the previous > post. > > Thank you > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Wed Oct 11 19:04:27 2017 From: njs at pobox.com (Nathaniel Smith) Date: Wed, 11 Oct 2017 18:04:27 -0500 Subject: [SciPy-Dev] Hide real name on mail list In-Reply-To: <16bbfa19-92ed-4e87-9edf-951a7796e8f0@Spark> References: <16bbfa19-92ed-4e87-9edf-951a7796e8f0@Spark> Message-ID: The mailing list is hosted by python.org, so if you want any change to the archives you'll have to contact their list admin team -- I think you can do that by emailing mailman at python.org. -n On Wed, Oct 11, 2017 at 12:35 PM, Ant wrote: > Hi, > > I have recently sent an email to the scipy-user mailing list, and my real > name was displayed, even if I made sure to set my username to something else > during the subscription process. > > I would really like this to be changed; my real name to be removed and the > made-up username to be shown instead (or nothing!). I find it confusing to > choose a username that is not displayed anywhere, displaying instead my real > name taken from the email account. > > I would really appreciate it if you could remove my name from the previous > post. > > Thank you > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -- Nathaniel J. Smith -- https://vorpus.org From antoniy.py at gmail.com Thu Oct 12 05:11:05 2017 From: antoniy.py at gmail.com (Ant) Date: Thu, 12 Oct 2017 11:11:05 +0200 Subject: [SciPy-Dev] Hide real name on mail list In-Reply-To: References: <16bbfa19-92ed-4e87-9edf-951a7796e8f0@Spark> Message-ID: <920e5ea4-e057-43ed-8ba7-29f623b59ca8@Spark> Thank you, I have sent an email to python.org. I have since changed the email informations, but if you ask me it is still confusing to ask for an user name during the signup process and then use the information from the email headers. In any case, thank you for the quick reply and have a nice day! :) On 12 Oct 2017, 01:06 +0200, Nathaniel Smith , wrote: > The mailing list is hosted by python.org, so if you want any change to > the archives you'll have to contact their list admin team -- I think > you can do that by emailing mailman at python.org. > > -n > > On Wed, Oct 11, 2017 at 12:35 PM, Ant wrote: > > Hi, > > > > I have recently sent an email to the scipy-user mailing list, and my real > > name was displayed, even if I made sure to set my username to something else > > during the subscription process. > > > > I would really like this to be changed; my real name to be removed and the > > made-up username to be shown instead (or nothing!). I find it confusing to > > choose a username that is not displayed anywhere, displaying instead my real > > name taken from the email account. > > > > I would really appreciate it if you could remove my name from the previous > > post. > > > > Thank you > > > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > -- > Nathaniel J. Smith -- https://vorpus.org > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmtac at LIVE.COM Thu Oct 12 16:19:25 2017 From: kmtac at LIVE.COM (. kt) Date: Thu, 12 Oct 2017 20:19:25 +0000 Subject: [SciPy-Dev] Code of conduct: 12 Oct blog featured on planet scipy Message-ID: Hello, I don't usually post to this list, but I check the blogs at planet.scipy.org regularly. They generally have useful, interesting and appropriate content. The 12 October 2017 post by Philip Herron seems to be a glaring exception. By the post's title -- something about "sex toys for men" -- the material seems to be inappropriate for a scientific python blog aggregator. (I didn't read the post, it could be satire or something -- but a blog post with that title should never appear on planet.scipy.org.) It also seems to be the type of thing that could give scientific python a bad name, on a high visibility website, a link to which is on the scipy.org main page. Perhaps a good time to test the proposed code of conduct. Meanwhile, perhaps someone who can edit planet.scipy.org should remove the post -- sooner, rather than later. Thanks, kmtac -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Fri Oct 13 02:45:04 2017 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 12 Oct 2017 23:45:04 -0700 Subject: [SciPy-Dev] [SciPy-User] Code of conduct: 12 Oct blog featured on planet scipy In-Reply-To: References: Message-ID: On Thu, Oct 12, 2017 at 1:19 PM, . kt wrote: > > Hello, > > I don't usually post to this list, but I check the blogs at planet.scipy.org regularly. They generally have useful, interesting and appropriate content. > > The 12 October 2017 post by Philip Herron seems to be a glaring exception. By the post's title -- something about "sex toys for men" -- the material seems to be inappropriate for a scientific python blog aggregator. (I didn't read the post, it could be satire or something -- but a blog post with that title should never appear on planet.scipy.org.) It also seems to be the type of thing that could give scientific python a bad name, on a high visibility website, a link to which is on the scipy.org main page. > > Perhaps a good time to test the proposed code of conduct. FWIW, it seems more likely to me that the site got hacked and taken over by a spammer. > Meanwhile, perhaps someone who can edit planet.scipy.org should remove the post -- sooner, rather than later. It already seems to be gone. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Fri Oct 13 03:47:41 2017 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 13 Oct 2017 09:47:41 +0200 Subject: [SciPy-Dev] [SciPy-User] Code of conduct: 12 Oct blog featured on planet scipy In-Reply-To: References: Message-ID: <20171013074741.GZ3536894@phare.normalesup.org> On Thu, Oct 12, 2017 at 11:45:04PM -0700, Robert Kern wrote: > On Thu, Oct 12, 2017 at 1:19 PM, . kt wrote: > > Perhaps a good time to test the proposed code of conduct. > FWIW, it seems more likely to me that the site got hacked and taken over by a > spammer. Indeed. > > Meanwhile, perhaps someone who can edit planet.scipy.org should remove the post -- sooner, rather than later. > It already seems to be gone. Removing the feed is the first thing that I did when I woke up this morning (Paris time zone). I have admin rights on the planet. My name is listed there as an administrator. People should not hesitate to contact me if something is wrong with the planet and I haven't noticed. I'll take action as quickly as possible. Ga?l From ralf.gommers at gmail.com Fri Oct 13 11:50:17 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 13 Oct 2017 10:50:17 -0500 Subject: [SciPy-Dev] release schedule update Message-ID: Hi all, Here's an update on the release schedule for scipy 1.0. We will need another release candidate, and are falling a little behind - here's my plan for the new dates: Sep 16: Branch 1.0.x --> done Sep 17: beta1 --> done Sep 27: rc1 --> done Oct 7: rc2 --> move to Oct 17 Oct 17: final release --> move to Oct 24 Here is the list of things that have to go into rc2: 1. https://github.com/scipy/scipy/pulls?q=is%3Apr+label%3Abackport-candidate+is%3Aclosed 2. Ensure we pick up the fix for https://github.com/scipy/scipy/issues/7969 to get the Windows wheels right. There are no unsolved blocking issues; the only reason for Oct 17 for rc2 is that I'm traveling now and didn't/don't have the bandwidth to do it this week. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Fri Oct 13 12:45:03 2017 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 13 Oct 2017 18:45:03 +0200 Subject: [SciPy-Dev] release schedule update In-Reply-To: References: Message-ID: <5d3ba0b0-81c9-921c-f6fc-066cc8f67914@iki.fi> Hi, Ralf Gommers kirjoitti 13.10.2017 klo 17:50: > Here's an update on the release schedule for scipy 1.0. We will need > another release candidate, and are falling a little behind - here's my plan > for the new dates: > > Sep 16: Branch 1.0.x --> done > Sep 17: beta1 --> done > Sep 27: rc1 --> done > Oct 7: rc2 --> move to Oct 17 > Oct 17: final release --> move to Oct 24 Thanks, looks fine to me. > Here is the list of things that have to go into rc2: > 1. > https://github.com/scipy/scipy/pulls?q=is%3Apr+label%3Abackport-candidate+is%3Aclosed > 2. Ensure we pick up the fix for https://github.com/scipy/scipy/issues/7969 > to get the Windows wheels right. The part 2. should require no further action, the wheels built with scipy-wheels appveyor should come out ok. Pauli From larson.eric.d at gmail.com Fri Oct 13 15:01:41 2017 From: larson.eric.d at gmail.com (Eric Larson) Date: Fri, 13 Oct 2017 15:01:41 -0400 Subject: [SciPy-Dev] scipy.signal.residue function - extension to z, p, k input In-Reply-To: <55bbf428-f3d3-7a6c-a8f8-6b4f16bb012d@spectro.jussieu.fr> References: <55bbf428-f3d3-7a6c-a8f8-6b4f16bb012d@spectro.jussieu.fr> Message-ID: This sounds like a useful complement to our existing residue/residuez functions. For consistency with our other ZPK functions, a name like residue_zpk would fit better than residues. Eric On Tue, Oct 10, 2017 at 8:24 AM, Leonhard Neuhaus < neuhaus at spectro.jussieu.fr> wrote: > Hi all, > > I have written a function residues() which does the same as > scipy.signal.residue, but that accepts an input in the form (zeros, poles, > k) - k is the global prefactor - instead of the usual (b, a)-Polynomial > form of the transfer function to transform. This was necessary since I > wanted to do the partial fraction expansion of an transfer function of > roughly 10th order (given in the zero-pole-form) and numerical imprecision > issues prevented me from passing through the (b, a)-form. The partial > fraction expansion was necessary in my case to decompose the transfer > function into parallel biquads (opposed to the more common serial biquad > decomposition). The way I implemented the transformation can be found here: > > https://github.com/lneuhaus/pyrpl/blob/55cb112a50e221f11eb28 > f106ba11272890c3b7f/pyrpl/hardware_modules/iir/iir_theory.py#L145 > > This implementation does not suffer from the typical numerical imprecision > issues associated with higher-order polynomials since the coefficients > (i.e. the prefactors of x^n in the numerator/denominator of the transfer > function) are never explicitly calculated. > > I would be happy to prepare a proper pull-request that extends the residue > function with the (zero, pole, k)-input option if this is desired. Please > let me know and I will get to work. > > Cheers, Leo > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Mon Oct 16 04:51:58 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 16 Oct 2017 21:51:58 +1300 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: On Fri, Oct 6, 2017 at 7:05 AM, Matthew Brett wrote: > On Thu, Oct 5, 2017 at 6:42 PM, Ralf Gommers > wrote: > > > > > > On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett > > wrote: > >> > >> Hi, > >> > >> On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat > wrote: > >> > I guess my second mail didn't make it to the server for some reason. > >> > I've > >> > written: > >> > > >> > "I should have probably put a smiley in the end. I mean it quite > lightly > >> > by > >> > the way. " > >> > > >> > No problem at all, Matthew for one I'm not a native speaker and second > >> > you > >> > guys probably have seen more conflicts than I ever did. I just wanted > to > >> > have the text a bit less formal. > >> > >> Sure - no problem from my side - I completely agree that less formal > >> is better ... > > > > > > Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be > > misunderstood if not worded right. > > > > Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to > me, > > and less tied to principles. Consider cutting for the sake of brevity?". > > I think that's a good point, so would like to go with that. It also > means we > > don't have to choose between your three versions of point 5:) > > Excellent outcome - more concise :) > Hi all, there haven't been more comments on the PR in the last 10 days and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd still like to do that. So here's a proposal: Thursday 19 Oct at 7pm UCT on Google Hangouts We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast. Also, it would be great to get a few volunteers for the CoC committee. Any takers? Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Mon Oct 16 05:15:24 2017 From: njs at pobox.com (Nathaniel Smith) Date: Mon, 16 Oct 2017 02:15:24 -0700 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers wrote: > > Hi all, there haven't been more comments on the PR in the last 10 days and > so far it seems everyone is happy. I said earlier that I'd organise a public > conference call in order to give another venue for input, and I'd still like > to do that. So here's a proposal: > > Thursday 19 Oct at 7pm UCT on Google Hangouts > > We've puzzled with time zones before, the best one was very early morning in > Australia and late evening in Russia. This time will be 6am in Sydney, 10pm > in Moscow, 8pm CET, 3pm US east cost, noon US west coast. I can attend the first half hour, anyway... and I'll try to comment on the PR before then too. > Also, it would be great to get a few volunteers for the CoC committee. Any > takers? Sure. -n -- Nathaniel J. Smith -- https://vorpus.org From andyfaff at gmail.com Mon Oct 16 05:28:30 2017 From: andyfaff at gmail.com (Andrew Nelson) Date: Mon, 16 Oct 2017 20:28:30 +1100 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: I can't make it on Thursday morning if that makes a difference to the timing. On 16 Oct 2017 7:52 pm, "Ralf Gommers" wrote: On Fri, Oct 6, 2017 at 7:05 AM, Matthew Brett wrote: > On Thu, Oct 5, 2017 at 6:42 PM, Ralf Gommers > wrote: > > > > > > On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett > > wrote: > >> > >> Hi, > >> > >> On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat > wrote: > >> > I guess my second mail didn't make it to the server for some reason. > >> > I've > >> > written: > >> > > >> > "I should have probably put a smiley in the end. I mean it quite > lightly > >> > by > >> > the way. " > >> > > >> > No problem at all, Matthew for one I'm not a native speaker and second > >> > you > >> > guys probably have seen more conflicts than I ever did. I just wanted > to > >> > have the text a bit less formal. > >> > >> Sure - no problem from my side - I completely agree that less formal > >> is better ... > > > > > > Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be > > misunderstood if not worded right. > > > > Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to > me, > > and less tied to principles. Consider cutting for the sake of brevity?". > > I think that's a good point, so would like to go with that. It also > means we > > don't have to choose between your three versions of point 5:) > > Excellent outcome - more concise :) > Hi all, there haven't been more comments on the PR in the last 10 days and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd still like to do that. So here's a proposal: Thursday 19 Oct at 7pm UCT on Google Hangouts We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast. Also, it would be great to get a few volunteers for the CoC committee. Any takers? Cheers, Ralf _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyfaff at gmail.com Mon Oct 16 05:28:31 2017 From: andyfaff at gmail.com (Andrew Nelson) Date: Mon, 16 Oct 2017 20:28:31 +1100 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: I can't make it on Thursday morning if that makes a difference to the timing. On 16 Oct 2017 7:52 pm, "Ralf Gommers" wrote: On Fri, Oct 6, 2017 at 7:05 AM, Matthew Brett wrote: > On Thu, Oct 5, 2017 at 6:42 PM, Ralf Gommers > wrote: > > > > > > On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett > > wrote: > >> > >> Hi, > >> > >> On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat > wrote: > >> > I guess my second mail didn't make it to the server for some reason. > >> > I've > >> > written: > >> > > >> > "I should have probably put a smiley in the end. I mean it quite > lightly > >> > by > >> > the way. " > >> > > >> > No problem at all, Matthew for one I'm not a native speaker and second > >> > you > >> > guys probably have seen more conflicts than I ever did. I just wanted > to > >> > have the text a bit less formal. > >> > >> Sure - no problem from my side - I completely agree that less formal > >> is better ... > > > > > > Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be > > misunderstood if not worded right. > > > > Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to > me, > > and less tied to principles. Consider cutting for the sake of brevity?". > > I think that's a good point, so would like to go with that. It also > means we > > don't have to choose between your three versions of point 5:) > > Excellent outcome - more concise :) > Hi all, there haven't been more comments on the PR in the last 10 days and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd still like to do that. So here's a proposal: Thursday 19 Oct at 7pm UCT on Google Hangouts We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast. Also, it would be great to get a few volunteers for the CoC committee. Any takers? Cheers, Ralf _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Mon Oct 16 05:35:07 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 16 Oct 2017 22:35:07 +1300 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: On Mon, Oct 16, 2017 at 10:28 PM, Andrew Nelson wrote: > I can't make it on Thursday morning if that makes a difference to the > timing. > Hi Andrew, it's Friday morning for you. Either way, doesn't make too much of a difference because I'm in New Zealand which is only 2 hours ahead of Australia. But we could shift it forward one or two hours if needed. Ralf > On 16 Oct 2017 7:52 pm, "Ralf Gommers" wrote: > > > > On Fri, Oct 6, 2017 at 7:05 AM, Matthew Brett > wrote: > >> On Thu, Oct 5, 2017 at 6:42 PM, Ralf Gommers >> wrote: >> > >> > >> > On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett >> > wrote: >> >> >> >> Hi, >> >> >> >> On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat >> wrote: >> >> > I guess my second mail didn't make it to the server for some reason. >> >> > I've >> >> > written: >> >> > >> >> > "I should have probably put a smiley in the end. I mean it quite >> lightly >> >> > by >> >> > the way. " >> >> > >> >> > No problem at all, Matthew for one I'm not a native speaker and >> second >> >> > you >> >> > guys probably have seen more conflicts than I ever did. I just >> wanted to >> >> > have the text a bit less formal. >> >> >> >> Sure - no problem from my side - I completely agree that less formal >> >> is better ... >> > >> > >> > Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be >> > misunderstood if not worded right. >> > >> > Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to >> me, >> > and less tied to principles. Consider cutting for the sake of brevity?". >> > I think that's a good point, so would like to go with that. It also >> means we >> > don't have to choose between your three versions of point 5:) >> >> Excellent outcome - more concise :) >> > > > Hi all, there haven't been more comments on the PR in the last 10 days and > so far it seems everyone is happy. I said earlier that I'd organise a > public conference call in order to give another venue for input, and I'd > still like to do that. So here's a proposal: > > Thursday 19 Oct at 7pm UCT on Google Hangouts > > We've puzzled with time zones before, the best one was very early morning > in Australia and late evening in Russia. This time will be 6am in Sydney, > 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast. > > > Also, it would be great to get a few volunteers for the CoC committee. Any > takers? > > Cheers, > Ralf > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyfaff at gmail.com Mon Oct 16 15:39:57 2017 From: andyfaff at gmail.com (Andrew Nelson) Date: Tue, 17 Oct 2017 06:39:57 +1100 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: I'm travelling for work on Friday. On 16 Oct 2017 8:35 pm, "Ralf Gommers" wrote: On Mon, Oct 16, 2017 at 10:28 PM, Andrew Nelson wrote: > I can't make it on Thursday morning if that makes a difference to the > timing. > Hi Andrew, it's Friday morning for you. Either way, doesn't make too much of a difference because I'm in New Zealand which is only 2 hours ahead of Australia. But we could shift it forward one or two hours if needed. Ralf > On 16 Oct 2017 7:52 pm, "Ralf Gommers" wrote: > > > > On Fri, Oct 6, 2017 at 7:05 AM, Matthew Brett > wrote: > >> On Thu, Oct 5, 2017 at 6:42 PM, Ralf Gommers >> wrote: >> > >> > >> > On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett >> > wrote: >> >> >> >> Hi, >> >> >> >> On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat >> wrote: >> >> > I guess my second mail didn't make it to the server for some reason. >> >> > I've >> >> > written: >> >> > >> >> > "I should have probably put a smiley in the end. I mean it quite >> lightly >> >> > by >> >> > the way. " >> >> > >> >> > No problem at all, Matthew for one I'm not a native speaker and >> second >> >> > you >> >> > guys probably have seen more conflicts than I ever did. I just >> wanted to >> >> > have the text a bit less formal. >> >> >> >> Sure - no problem from my side - I completely agree that less formal >> >> is better ... >> > >> > >> > Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be >> > misunderstood if not worded right. >> > >> > Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to >> me, >> > and less tied to principles. Consider cutting for the sake of brevity?". >> > I think that's a good point, so would like to go with that. It also >> means we >> > don't have to choose between your three versions of point 5:) >> >> Excellent outcome - more concise :) >> > > > Hi all, there haven't been more comments on the PR in the last 10 days and > so far it seems everyone is happy. I said earlier that I'd organise a > public conference call in order to give another venue for input, and I'd > still like to do that. So here's a proposal: > > Thursday 19 Oct at 7pm UCT on Google Hangouts > > We've puzzled with time zones before, the best one was very early morning > in Australia and late evening in Russia. This time will be 6am in Sydney, > 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast. > > > Also, it would be great to get a few volunteers for the CoC committee. Any > takers? > > Cheers, > Ralf > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Tue Oct 17 02:18:02 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 17 Oct 2017 19:18:02 +1300 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: On Mon, Oct 16, 2017 at 10:15 PM, Nathaniel Smith wrote: > On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers > wrote: > > > > Hi all, there haven't been more comments on the PR in the last 10 days > and > > so far it seems everyone is happy. I said earlier that I'd organise a > public > > conference call in order to give another venue for input, and I'd still > like > > to do that. So here's a proposal: > > > > Thursday 19 Oct at 7pm UCT on Google Hangouts > > > > We've puzzled with time zones before, the best one was very early > morning in > > Australia and late evening in Russia. This time will be 6am in Sydney, > 10pm > > in Moscow, 8pm CET, 3pm US east cost, noon US west coast. > > I can attend the first half hour, anyway... and I'll try to comment on > the PR before then too. > > > Also, it would be great to get a few volunteers for the CoC committee. > Any > > takers? > > Sure. > Thanks! Anyone else? Note that (I think) it's not essential that all committee members are part of the core developer team. If you're part of the community and are interested in being on this commitee, please let us know (offline questions or expressions of interest also welcome). If you have experience with CoCs and/or can increase the diversity of experiences and viewpoints on the committee, that would be doubly welcome. Cheers, Ralf > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler.je.reddy at gmail.com Tue Oct 17 12:54:08 2017 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Tue, 17 Oct 2017 10:54:08 -0600 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: I put the Thursday meeting on my calendar -- should be able to listen in at least. Tyler On 17 October 2017 at 00:18, Ralf Gommers wrote: > > > On Mon, Oct 16, 2017 at 10:15 PM, Nathaniel Smith wrote: > >> On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers >> wrote: >> > >> > Hi all, there haven't been more comments on the PR in the last 10 days >> and >> > so far it seems everyone is happy. I said earlier that I'd organise a >> public >> > conference call in order to give another venue for input, and I'd still >> like >> > to do that. So here's a proposal: >> > >> > Thursday 19 Oct at 7pm UCT on Google Hangouts >> > >> > We've puzzled with time zones before, the best one was very early >> morning in >> > Australia and late evening in Russia. This time will be 6am in Sydney, >> 10pm >> > in Moscow, 8pm CET, 3pm US east cost, noon US west coast. >> >> I can attend the first half hour, anyway... and I'll try to comment on >> the PR before then too. >> >> > Also, it would be great to get a few volunteers for the CoC committee. >> Any >> > takers? >> >> Sure. >> > > Thanks! > > Anyone else? Note that (I think) it's not essential that all committee > members are part of the core developer team. If you're part of the > community and are interested in being on this commitee, please let us know > (offline questions or expressions of interest also welcome). If you have > experience with CoCs and/or can increase the diversity of experiences and > viewpoints on the committee, that would be doubly welcome. > > Cheers, > Ralf > > > >> -n >> >> -- >> Nathaniel J. Smith -- https://vorpus.org >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Oct 18 06:04:40 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 18 Oct 2017 23:04:40 +1300 Subject: [SciPy-Dev] ANN: second SciPy 1.0.0 release candidate Message-ID: Hi all, I'm excited to be able to announce the availability of the second (and hopefully last) release candidate of Scipy 1.0. This is a big release, and a version number that has been 16 years in the making. It contains a few more deprecations and backwards incompatible changes than an average release. Therefore please do test it on your own code, and report any issues on the Github issue tracker or on the scipy-dev mailing list. Sources and binary wheels can be found at https://pypi.python.org/pypi/scipy and https://github.com/scipy/scipy/releases/tag/v1.0.0rc2. To install with pip: pip install --pre --upgrade scipy The most important issues fixed after v1.0.0rc1 is https://github.com/scipy/scipy/issues/7969 (missing DLL in Windows wheel). Pull requests merged after v1.0.0rc1: - `#7948 `__: DOC: add note on checking for deprecations before upgrade to... - `#7952 `__: DOC: update SciPy Roadmap for 1.0 release and recent discussions. - `#7960 `__: BUG: optimize: revert changes to bfgs in gh-7165 - `#7962 `__: TST: special: mark a failing hyp2f1 test as xfail - `#7973 `__: BUG: fixed keyword in 'info' in ``_get_mem_available`` utility - `#7986 `__: TST: Relax test_trsm precision to 5 decimals - `#8001 `__: TST: fix test failures from Matplotlib 2.1 update - `#8010 `__: BUG: signal: fix crash in lfilter - `#8019 `__: MAINT: fix test failures with NumPy master Thanks to everyone who contributed to this release! Ralf ========================== SciPy 1.0.0 Release Notes ========================== .. note:: Scipy 1.0.0 is not released yet! .. contents:: SciPy 1.0.0 is the culmination of 8 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. There have been a number of deprecations and API changes in this release, which are documented below. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Moreover, our development attention will now shift to bug-fix releases on the 1.0.x branch, and on adding new features on the master branch. Some of the highlights of this release are: - Major build improvements. Windows wheels are available on PyPI for the first time, and continuous integration has been set up on Windows and OS X in addition to Linux. - A set of new ODE solvers and a unified interface to them (`scipy.integrate.solve_ivp`). - Two new trust region optimizers and a new linear programming method, with improved performance compared to what `scipy.optimize` offered previously. - Many new BLAS and LAPACK functions were wrapped. The BLAS wrappers are now complete. This release requires Python 2.7 or 3.4+ and NumPy 1.8.2 or greater. This is also the last release to support LAPACK 3.1.x - 3.3.x. Moving the lowest supported LAPACK version to >3.2.x was long blocked by Apple Accelerate providing the LAPACK 3.2.1 API. We have decided that it's time to either drop Accelerate or, if there is enough interest, provide shims for functions added in more recent LAPACK versions so it can still be used. New features ============ `scipy.cluster` improvements ---------------------------- `scipy.cluster.hierarchy.optimal_leaf_ordering`, a function to reorder a linkage matrix to minimize distances between adjacent leaves, was added. `scipy.fftpack` improvements ---------------------------- N-dimensional versions of the discrete sine and cosine transforms and their inverses were added as ``dctn``, ``idctn``, ``dstn`` and ``idstn``. `scipy.integrate` improvements ------------------------------ A set of new ODE solvers have been added to `scipy.integrate`. The convenience function `scipy.integrate.solve_ivp` allows uniform access to all solvers. The individual solvers (``RK23``, ``RK45``, ``Radau``, ``BDF`` and ``LSODA``) can also be used directly. `scipy.linalg` improvements ---------------------------- The BLAS wrappers in `scipy.linalg.blas` have been completed. Added functions are ``*gbmv``, ``*hbmv``, ``*hpmv``, ``*hpr``, ``*hpr2``, ``*spmv``, ``*spr``, ``*tbmv``, ``*tbsv``, ``*tpmv``, ``*tpsv``, ``*trsm``, ``*trsv``, ``*sbmv``, ``*spr2``, Wrappers for the LAPACK functions ``*gels``, ``*stev``, ``*sytrd``, ``*hetrd``, ``*sytf2``, ``*hetrf``, ``*sytrf``, ``*sycon``, ``*hecon``, ``*gglse``, ``*stebz``, ``*stemr``, ``*sterf``, and ``*stein`` have been added. The function `scipy.linalg.subspace_angles` has been added to compute the subspace angles between two matrices. The function `scipy.linalg.clarkson_woodruff_transform` has been added. It finds low-rank matrix approximation via the Clarkson-Woodruff Transform. The functions `scipy.linalg.eigh_tridiagonal` and `scipy.linalg.eigvalsh_tridiagonal`, which find the eigenvalues and eigenvectors of tridiagonal hermitian/symmetric matrices, were added. `scipy.ndimage` improvements ---------------------------- Support for homogeneous coordinate transforms has been added to `scipy.ndimage.affine_transform`. The ``ndimage`` C code underwent a significant refactoring, and is now a lot easier to understand and maintain. `scipy.optimize` improvements ----------------------------- The methods ``trust-region-exact`` and ``trust-krylov`` have been added to the function `scipy.optimize.minimize`. These new trust-region methods solve the subproblem with higher accuracy at the cost of more Hessian factorizations (compared to dogleg) or more matrix vector products (compared to ncg) but usually require less nonlinear iterations and are able to deal with indefinite Hessians. They seem very competitive against the other Newton methods implemented in scipy. `scipy.optimize.linprog` gained an interior point method. Its performance is superior (both in accuracy and speed) to the older simplex method. `scipy.signal` improvements --------------------------- An argument ``fs`` (sampling frequency) was added to the following functions: ``firwin``, ``firwin2``, ``firls``, and ``remez``. This makes these functions consistent with many other functions in `scipy.signal` in which the sampling frequency can be specified. `scipy.signal.freqz` has been sped up significantly for FIR filters. `scipy.sparse` improvements --------------------------- Iterating over and slicing of CSC and CSR matrices is now faster by up to ~35%. The ``tocsr`` method of COO matrices is now several times faster. The ``diagonal`` method of sparse matrices now takes a parameter, indicating which diagonal to return. `scipy.sparse.linalg` improvements ---------------------------------- A new iterative solver for large-scale nonsymmetric sparse linear systems, `scipy.sparse.linalg.gcrotmk`, was added. It implements ``GCROT(m,k)``, a flexible variant of ``GCROT``. `scipy.sparse.linalg.lsmr` now accepts an initial guess, yielding potentially faster convergence. SuperLU was updated to version 5.2.1. `scipy.spatial` improvements ---------------------------- Many distance metrics in `scipy.spatial.distance` gained support for weights. The signatures of `scipy.spatial.distance.pdist` and `scipy.spatial.distance.cdist` were changed to ``*args, **kwargs`` in order to support a wider range of metrics (e.g. string-based metrics that need extra keywords). Also, an optional ``out`` parameter was added to ``pdist`` and ``cdist`` allowing the user to specify where the resulting distance matrix is to be stored `scipy.stats` improvements -------------------------- The methods ``cdf`` and ``logcdf`` were added to `scipy.stats.multivariate_normal`, providing the cumulative distribution function of the multivariate normal distribution. New statistical distance functions were added, namely `scipy.stats.wasserstein_distance` for the first Wasserstein distance and `scipy.stats.energy_distance` for the energy distance. Deprecated features =================== The following functions in `scipy.misc` are deprecated: ``bytescale``, ``fromimage``, ``imfilter``, ``imread``, ``imresize``, ``imrotate``, ``imsave``, ``imshow`` and ``toimage``. Most of those functions have unexpected behavior (like rescaling and type casting image data without the user asking for that). Other functions simply have better alternatives. ``scipy.interpolate.interpolate_wrapper`` and all functions in that submodule are deprecated. This was a never finished set of wrapper functions which is not relevant anymore. The ``fillvalue`` of `scipy.signal.convolve2d` will be cast directly to the dtypes of the input arrays in the future and checked that it is a scalar or an array with a single element. ``scipy.spatial.distance.matching`` is deprecated. It is an alias of `scipy.spatial.distance.hamming`, which should be used instead. Implementation of `scipy.spatial.distance.wminkowski` was based on a wrong interpretation of the metric definition. In scipy 1.0 it has been just deprecated in the documentation to keep retro-compatibility but is recommended to use the new version of `scipy.spatial.distance.minkowski` that implements the correct behaviour. Positional arguments of `scipy.spatial.distance.pdist` and `scipy.spatial.distance.cdist` should be replaced with their keyword version. Backwards incompatible changes ============================== The following deprecated functions have been removed from `scipy.stats`: ``betai``, ``chisqprob``, ``f_value``, ``histogram``, ``histogram2``, ``pdf_fromgamma``, ``signaltonoise``, ``square_of_sums``, ``ss`` and ``threshold``. The following deprecated functions have been removed from `scipy.stats.mstats`: ``betai``, ``f_value_wilks_lambda``, ``signaltonoise`` and ``threshold``. The deprecated ``a`` and ``reta`` keywords have been removed from `scipy.stats.shapiro`. The deprecated functions ``sparse.csgraph.cs_graph_components`` and ``sparse.linalg.symeig`` have been removed from `scipy.sparse`. The following deprecated keywords have been removed in `scipy.sparse.linalg`: ``drop_tol`` from ``splu``, and ``xtype`` from ``bicg``, ``bicgstab``, ``cg``, ``cgs``, ``gmres``, ``qmr`` and ``minres``. The deprecated functions ``expm2`` and ``expm3`` have been removed from `scipy.linalg`. The deprecated keyword ``q`` was removed from `scipy.linalg.expm`. And the deprecated submodule ``linalg.calc_lwork`` was removed. The deprecated functions ``C2K``, ``K2C``, ``F2C``, ``C2F``, ``F2K`` and ``K2F`` have been removed from `scipy.constants`. The deprecated ``ppform`` class was removed from `scipy.interpolate`. The deprecated keyword ``iprint`` was removed from `scipy.optimize.fmin_cobyla`. The default value for the ``zero_phase`` keyword of `scipy.signal.decimate` has been changed to True. The ``kmeans`` and ``kmeans2`` functions in `scipy.cluster.vq` changed the method used for random initialization, so using a fixed random seed will not necessarily produce the same results as in previous versions. `scipy.special.gammaln` does not accept complex arguments anymore. The deprecated functions ``sph_jn``, ``sph_yn``, ``sph_jnyn``, ``sph_in``, ``sph_kn``, and ``sph_inkn`` have been removed. Users should instead use the functions ``spherical_jn``, ``spherical_yn``, ``spherical_in``, and ``spherical_kn``. Be aware that the new functions have different signatures. The cross-class properties of `scipy.signal.lti` systems have been removed. The following properties/setters have been removed: Name - (accessing/setting has been removed) - (setting has been removed) * StateSpace - (``num``, ``den``, ``gain``) - (``zeros``, ``poles``) * TransferFunction (``A``, ``B``, ``C``, ``D``, ``gain``) - (``zeros``, ``poles``) * ZerosPolesGain (``A``, ``B``, ``C``, ``D``, ``num``, ``den``) - () ``signal.freqz(b, a)`` with ``b`` or ``a`` >1-D raises a ``ValueError``. This was a corner case for which it was unclear that the behavior was well-defined. The method ``var`` of `scipy.stats.dirichlet` now returns a scalar rather than an ndarray when the length of alpha is 1. Other changes ============= SciPy now has a formal governance structure. It consists of a BDFL (Pauli Virtanen) and a Steering Committee. See `the governance document `_ for details. It is now possible to build SciPy on Windows with MSVC + gfortran! Continuous integration has been set up for this build configuration on Appveyor, building against OpenBLAS. Continuous integration for OS X has been set up on TravisCI. The SciPy test suite has been migrated from ``nose`` to ``pytest``. ``scipy/_distributor_init.py`` was added to allow redistributors of SciPy to add custom code that needs to run when importing SciPy (e.g. checks for hardware, DLL search paths, etc.). Support for PEP 518 (specifying build system requirements) was added - see ``pyproject.toml`` in the root of the SciPy repository. In order to have consistent function names, the function ``scipy.linalg.solve_lyapunov`` is renamed to `scipy.linalg.solve_continuous_lyapunov`. The old name is kept for backwards-compatibility. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilhanpolat at gmail.com Wed Oct 18 07:49:35 2017 From: ilhanpolat at gmail.com (Ilhan Polat) Date: Wed, 18 Oct 2017 13:49:35 +0200 Subject: [SciPy-Dev] ANN: second SciPy 1.0.0 release candidate In-Reply-To: References: Message-ID: Much appreciated Ralf! Hats off to maintaining this organized chaos. On Wed, Oct 18, 2017 at 12:04 PM, Ralf Gommers wrote: > Hi all, > > I'm excited to be able to announce the availability of the second (and > hopefully last) release candidate of Scipy 1.0. This is a big release, > and a version number that has been 16 years in the making. It contains a > few more deprecations and backwards incompatible changes than an average > release. Therefore please do test it on your own code, and report any > issues on the Github issue tracker or on the scipy-dev mailing list. > > Sources and binary wheels can be found at https://pypi.python.org/pypi/s > cipy and https://github.com/scipy/scipy/releases/tag/v1.0.0rc2. To > install with pip: > > pip install --pre --upgrade scipy > > The most important issues fixed after v1.0.0rc1 is > https://github.com/scipy/scipy/issues/7969 (missing DLL in Windows wheel). > > Pull requests merged after v1.0.0rc1: > > - `#7948 `__: DOC: add note on > checking for deprecations before upgrade to... > - `#7952 `__: DOC: update SciPy > Roadmap for 1.0 release and recent discussions. > - `#7960 `__: BUG: optimize: > revert changes to bfgs in gh-7165 > - `#7962 `__: TST: special: > mark a failing hyp2f1 test as xfail > - `#7973 `__: BUG: fixed > keyword in 'info' in ``_get_mem_available`` utility > - `#7986 `__: TST: Relax > test_trsm precision to 5 decimals > - `#8001 `__: TST: fix test > failures from Matplotlib 2.1 update > - `#8010 `__: BUG: signal: fix > crash in lfilter > - `#8019 `__: MAINT: fix test > failures with NumPy master > > Thanks to everyone who contributed to this release! > > Ralf > > > > ========================== > SciPy 1.0.0 Release Notes > ========================== > > .. note:: Scipy 1.0.0 is not released yet! > > .. contents:: > > SciPy 1.0.0 is the culmination of 8 months of hard work. It contains > many new features, numerous bug-fixes, improved test coverage and > better documentation. There have been a number of deprecations and > API changes in this release, which are documented below. All users > are encouraged to upgrade to this release, as there are a large number > of bug-fixes and optimizations. Moreover, our development attention > will now shift to bug-fix releases on the 1.0.x branch, and on adding > new features on the master branch. > > Some of the highlights of this release are: > > - Major build improvements. Windows wheels are available on PyPI for the > first time, and continuous integration has been set up on Windows and OS > X > in addition to Linux. > - A set of new ODE solvers and a unified interface to them > (`scipy.integrate.solve_ivp`). > - Two new trust region optimizers and a new linear programming method, with > improved performance compared to what `scipy.optimize` offered > previously. > - Many new BLAS and LAPACK functions were wrapped. The BLAS wrappers are > now > complete. > > This release requires Python 2.7 or 3.4+ and NumPy 1.8.2 or greater. > > This is also the last release to support LAPACK 3.1.x - 3.3.x. Moving the > lowest supported LAPACK version to >3.2.x was long blocked by Apple > Accelerate > providing the LAPACK 3.2.1 API. We have decided that it's time to either > drop > Accelerate or, if there is enough interest, provide shims for functions > added > in more recent LAPACK versions so it can still be used. > > > New features > ============ > > `scipy.cluster` improvements > ---------------------------- > > `scipy.cluster.hierarchy.optimal_leaf_ordering`, a function to reorder a > linkage matrix to minimize distances between adjacent leaves, was added. > > > `scipy.fftpack` improvements > ---------------------------- > > N-dimensional versions of the discrete sine and cosine transforms and their > inverses were added as ``dctn``, ``idctn``, ``dstn`` and ``idstn``. > > > `scipy.integrate` improvements > ------------------------------ > > A set of new ODE solvers have been added to `scipy.integrate`. The > convenience > function `scipy.integrate.solve_ivp` allows uniform access to all solvers. > The individual solvers (``RK23``, ``RK45``, ``Radau``, ``BDF`` and > ``LSODA``) > can also be used directly. > > > `scipy.linalg` improvements > ---------------------------- > > The BLAS wrappers in `scipy.linalg.blas` have been completed. Added > functions > are ``*gbmv``, ``*hbmv``, ``*hpmv``, ``*hpr``, ``*hpr2``, ``*spmv``, > ``*spr``, > ``*tbmv``, ``*tbsv``, ``*tpmv``, ``*tpsv``, ``*trsm``, ``*trsv``, > ``*sbmv``, > ``*spr2``, > > Wrappers for the LAPACK functions ``*gels``, ``*stev``, ``*sytrd``, > ``*hetrd``, > ``*sytf2``, ``*hetrf``, ``*sytrf``, ``*sycon``, ``*hecon``, ``*gglse``, > ``*stebz``, ``*stemr``, ``*sterf``, and ``*stein`` have been added. > > The function `scipy.linalg.subspace_angles` has been added to compute the > subspace angles between two matrices. > > The function `scipy.linalg.clarkson_woodruff_transform` has been added. > It finds low-rank matrix approximation via the Clarkson-Woodruff Transform. > > The functions `scipy.linalg.eigh_tridiagonal` and > `scipy.linalg.eigvalsh_tridiagonal`, which find the eigenvalues and > eigenvectors of tridiagonal hermitian/symmetric matrices, were added. > > > `scipy.ndimage` improvements > ---------------------------- > > Support for homogeneous coordinate transforms has been added to > `scipy.ndimage.affine_transform`. > > The ``ndimage`` C code underwent a significant refactoring, and is now > a lot easier to understand and maintain. > > > `scipy.optimize` improvements > ----------------------------- > > The methods ``trust-region-exact`` and ``trust-krylov`` have been added to > the > function `scipy.optimize.minimize`. These new trust-region methods solve > the > subproblem with higher accuracy at the cost of more Hessian factorizations > (compared to dogleg) or more matrix vector products (compared to ncg) but > usually require less nonlinear iterations and are able to deal with > indefinite > Hessians. They seem very competitive against the other Newton methods > implemented in scipy. > > `scipy.optimize.linprog` gained an interior point method. Its performance > is > superior (both in accuracy and speed) to the older simplex method. > > > `scipy.signal` improvements > --------------------------- > > An argument ``fs`` (sampling frequency) was added to the following > functions: > ``firwin``, ``firwin2``, ``firls``, and ``remez``. This makes these > functions > consistent with many other functions in `scipy.signal` in which the > sampling > frequency can be specified. > > `scipy.signal.freqz` has been sped up significantly for FIR filters. > > > `scipy.sparse` improvements > --------------------------- > > Iterating over and slicing of CSC and CSR matrices is now faster by up to > ~35%. > > The ``tocsr`` method of COO matrices is now several times faster. > > The ``diagonal`` method of sparse matrices now takes a parameter, > indicating > which diagonal to return. > > > `scipy.sparse.linalg` improvements > ---------------------------------- > > A new iterative solver for large-scale nonsymmetric sparse linear systems, > `scipy.sparse.linalg.gcrotmk`, was added. It implements ``GCROT(m,k)``, a > flexible variant of ``GCROT``. > > `scipy.sparse.linalg.lsmr` now accepts an initial guess, yielding > potentially > faster convergence. > > SuperLU was updated to version 5.2.1. > > > `scipy.spatial` improvements > ---------------------------- > > Many distance metrics in `scipy.spatial.distance` gained support for > weights. > > The signatures of `scipy.spatial.distance.pdist` and > `scipy.spatial.distance.cdist` were changed to ``*args, **kwargs`` in > order to > support a wider range of metrics (e.g. string-based metrics that need extra > keywords). Also, an optional ``out`` parameter was added to ``pdist`` and > ``cdist`` allowing the user to specify where the resulting distance matrix > is > to be stored > > > `scipy.stats` improvements > -------------------------- > > The methods ``cdf`` and ``logcdf`` were added to > `scipy.stats.multivariate_normal`, providing the cumulative distribution > function of the multivariate normal distribution. > > New statistical distance functions were added, namely > `scipy.stats.wasserstein_distance` for the first Wasserstein distance and > `scipy.stats.energy_distance` for the energy distance. > > > Deprecated features > =================== > > The following functions in `scipy.misc` are deprecated: ``bytescale``, > ``fromimage``, ``imfilter``, ``imread``, ``imresize``, ``imrotate``, > ``imsave``, ``imshow`` and ``toimage``. Most of those functions have > unexpected > behavior (like rescaling and type casting image data without the user > asking > for that). Other functions simply have better alternatives. > > ``scipy.interpolate.interpolate_wrapper`` and all functions in that > submodule > are deprecated. This was a never finished set of wrapper functions which > is > not relevant anymore. > > The ``fillvalue`` of `scipy.signal.convolve2d` will be cast directly to the > dtypes of the input arrays in the future and checked that it is a scalar or > an array with a single element. > > ``scipy.spatial.distance.matching`` is deprecated. It is an alias of > `scipy.spatial.distance.hamming`, which should be used instead. > > Implementation of `scipy.spatial.distance.wminkowski` was based on a wrong > interpretation of the metric definition. In scipy 1.0 it has been just > deprecated in the documentation to keep retro-compatibility but is > recommended > to use the new version of `scipy.spatial.distance.minkowski` that > implements > the correct behaviour. > > Positional arguments of `scipy.spatial.distance.pdist` and > `scipy.spatial.distance.cdist` should be replaced with their keyword > version. > > > Backwards incompatible changes > ============================== > > The following deprecated functions have been removed from `scipy.stats`: > ``betai``, ``chisqprob``, ``f_value``, ``histogram``, ``histogram2``, > ``pdf_fromgamma``, ``signaltonoise``, ``square_of_sums``, ``ss`` and > ``threshold``. > > The following deprecated functions have been removed from > `scipy.stats.mstats`: > ``betai``, ``f_value_wilks_lambda``, ``signaltonoise`` and ``threshold``. > > The deprecated ``a`` and ``reta`` keywords have been removed from > `scipy.stats.shapiro`. > > The deprecated functions ``sparse.csgraph.cs_graph_components`` and > ``sparse.linalg.symeig`` have been removed from `scipy.sparse`. > > The following deprecated keywords have been removed in > `scipy.sparse.linalg`: > ``drop_tol`` from ``splu``, and ``xtype`` from ``bicg``, ``bicgstab``, > ``cg``, > ``cgs``, ``gmres``, ``qmr`` and ``minres``. > > The deprecated functions ``expm2`` and ``expm3`` have been removed from > `scipy.linalg`. The deprecated keyword ``q`` was removed from > `scipy.linalg.expm`. And the deprecated submodule ``linalg.calc_lwork`` > was > removed. > > The deprecated functions ``C2K``, ``K2C``, ``F2C``, ``C2F``, ``F2K`` and > ``K2F`` have been removed from `scipy.constants`. > > The deprecated ``ppform`` class was removed from `scipy.interpolate`. > > The deprecated keyword ``iprint`` was removed from > `scipy.optimize.fmin_cobyla`. > > The default value for the ``zero_phase`` keyword of `scipy.signal.decimate` > has been changed to True. > > The ``kmeans`` and ``kmeans2`` functions in `scipy.cluster.vq` changed the > method used for random initialization, so using a fixed random seed will > not necessarily produce the same results as in previous versions. > > `scipy.special.gammaln` does not accept complex arguments anymore. > > The deprecated functions ``sph_jn``, ``sph_yn``, ``sph_jnyn``, ``sph_in``, > ``sph_kn``, and ``sph_inkn`` have been removed. Users should instead use > the functions ``spherical_jn``, ``spherical_yn``, ``spherical_in``, and > ``spherical_kn``. Be aware that the new functions have different > signatures. > > The cross-class properties of `scipy.signal.lti` systems have been removed. > The following properties/setters have been removed: > > Name - (accessing/setting has been removed) - (setting has been removed) > > * StateSpace - (``num``, ``den``, ``gain``) - (``zeros``, ``poles``) > * TransferFunction (``A``, ``B``, ``C``, ``D``, ``gain``) - (``zeros``, > ``poles``) > * ZerosPolesGain (``A``, ``B``, ``C``, ``D``, ``num``, ``den``) - () > > ``signal.freqz(b, a)`` with ``b`` or ``a`` >1-D raises a ``ValueError``. > This > was a corner case for which it was unclear that the behavior was > well-defined. > > The method ``var`` of `scipy.stats.dirichlet` now returns a scalar rather > than > an ndarray when the length of alpha is 1. > > > Other changes > ============= > > SciPy now has a formal governance structure. It consists of a BDFL (Pauli > Virtanen) and a Steering Committee. See `the governance document > governance/governance.rst>`_ > for details. > > It is now possible to build SciPy on Windows with MSVC + gfortran! > Continuous > integration has been set up for this build configuration on Appveyor, > building > against OpenBLAS. > > Continuous integration for OS X has been set up on TravisCI. > > The SciPy test suite has been migrated from ``nose`` to ``pytest``. > > ``scipy/_distributor_init.py`` was added to allow redistributors of SciPy > to > add custom code that needs to run when importing SciPy (e.g. checks for > hardware, DLL search paths, etc.). > > Support for PEP 518 (specifying build system requirements) was added - see > ``pyproject.toml`` in the root of the SciPy repository. > > In order to have consistent function names, the function > ``scipy.linalg.solve_lyapunov`` is renamed to > `scipy.linalg.solve_continuous_lyapunov`. The old name is kept for > backwards-compatibility. > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Wed Oct 18 14:58:28 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 18 Oct 2017 19:58:28 +0100 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: Hi, On Tue, Oct 17, 2017 at 7:18 AM, Ralf Gommers wrote: > > > On Mon, Oct 16, 2017 at 10:15 PM, Nathaniel Smith wrote: >> >> On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers >> wrote: >> > >> > Hi all, there haven't been more comments on the PR in the last 10 days >> > and >> > so far it seems everyone is happy. I said earlier that I'd organise a >> > public >> > conference call in order to give another venue for input, and I'd still >> > like >> > to do that. So here's a proposal: >> > >> > Thursday 19 Oct at 7pm UCT on Google Hangouts >> > >> > We've puzzled with time zones before, the best one was very early >> > morning in >> > Australia and late evening in Russia. This time will be 6am in Sydney, >> > 10pm >> > in Moscow, 8pm CET, 3pm US east cost, noon US west coast. >> >> I can attend the first half hour, anyway... and I'll try to comment on >> the PR before then too. >> >> > Also, it would be great to get a few volunteers for the CoC committee. >> > Any >> > takers? >> >> Sure. > > > Thanks! > > Anyone else? Note that (I think) it's not essential that all committee > members are part of the core developer team. If you're part of the community > and are interested in being on this commitee, please let us know (offline > questions or expressions of interest also welcome). If you have experience > with CoCs and/or can increase the diversity of experiences and viewpoints on > the committee, that would be doubly welcome. I can make it, and would like to join. Cheers, Matthew From Former at physicist.net Wed Oct 18 19:47:42 2017 From: Former at physicist.net (Adam) Date: Wed, 18 Oct 2017 16:47:42 -0700 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 Message-ID: <1508370462.5994.94.camel@physicist.net> Hello guys, I've found a small region in the complex plane where scipy's implementation of the hypergeometric function hyp2f1 fails. I've documented this error in?issue 8054?on github.? I am willing to submit a PR that fixes this issue.?My PR would basically implement the analytic continuation formula given in this paper: (Buhring, An Analytic Continuation of the Hypergeometric Series). I've already implemented this series in some prototype code written in Fortran and it agrees well with the values returned by mpmath's implementation of hyp2f1. Before I attempt a PR, I just wanted to touch base and ask the group the following: 1)?Does this sound like a worthwhile PR??The failure region is somewhat small and I don't know with what urgency people would want this fixed. 2)?Does the implementation sound reasonable??My background is physics and so I haven't done a complete literature search looking for the *fastest* algorithm. All I can say that the Buhring's formula works and my implementation only seems to be about %50 slower than the current hyp2f1 (at points in the complex plane where both methods converge). I would only apply Buhring's series in the region where hyp2f1 currently diverges. 3)?Can the PR implement formulas/methods that don't appear in the literature??Buhring's paper *only* gives the analytic continuation for the case where the difference between the a/b parameters is NOT an integer. When a-b=m, the limit case of his series can be derived using a method described in "The Special Functions and Their Approximations" by Y. Luke (as Buhling mentions in his paper). I've derived the formula for this limit case and have an implementation of it that produces values in agreement with mpmath. ?Is it going to be a problem if I implement this limit case in the PR??I ask because I don't what reference I would place hyp2f1's doc string. I would be wiling to maybe add a latex doc to the PR (placed somewhere in the doc folder?) that contains the formula so that future scipy devs have something to reference when reviewing hyp2f1's source code. Anyways, let me know if my idea for a PR sounds like a good idea! I apologize for the longish email, but this is my first time trying to contribute to scipy... --Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From haberland at ucla.edu Wed Oct 18 22:59:07 2017 From: haberland at ucla.edu (Matt Haberland) Date: Wed, 18 Oct 2017 19:59:07 -0700 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: I can make it. On Wed, Oct 18, 2017 at 11:58 AM, Matthew Brett wrote: > Hi, > > On Tue, Oct 17, 2017 at 7:18 AM, Ralf Gommers > wrote: > > > > > > On Mon, Oct 16, 2017 at 10:15 PM, Nathaniel Smith wrote: > >> > >> On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers > >> wrote: > >> > > >> > Hi all, there haven't been more comments on the PR in the last 10 days > >> > and > >> > so far it seems everyone is happy. I said earlier that I'd organise a > >> > public > >> > conference call in order to give another venue for input, and I'd > still > >> > like > >> > to do that. So here's a proposal: > >> > > >> > Thursday 19 Oct at 7pm UCT on Google Hangouts > >> > > >> > We've puzzled with time zones before, the best one was very early > >> > morning in > >> > Australia and late evening in Russia. This time will be 6am in Sydney, > >> > 10pm > >> > in Moscow, 8pm CET, 3pm US east cost, noon US west coast. > >> > >> I can attend the first half hour, anyway... and I'll try to comment on > >> the PR before then too. > >> > >> > Also, it would be great to get a few volunteers for the CoC committee. > >> > Any > >> > takers? > >> > >> Sure. > > > > > > Thanks! > > > > Anyone else? Note that (I think) it's not essential that all committee > > members are part of the core developer team. If you're part of the > community > > and are interested in being on this commitee, please let us know (offline > > questions or expressions of interest also welcome). If you have > experience > > with CoCs and/or can increase the diversity of experiences and > viewpoints on > > the committee, that would be doubly welcome. > > I can make it, and would like to join. > > Cheers, > > Matthew > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -- Matt Haberland Assistant Adjunct Professor in the Program in Computing Department of Mathematics 7620E Math Sciences Building, UCLA -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Oct 19 05:11:11 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 19 Oct 2017 10:11:11 +0100 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: Hi, Back to the code of conduct discussion, Nathaniel has raised a pertinent theme over at the Scipy PR - main comment at: https://github.com/scipy/scipy/pull/7963#discussion_r145580285 Nathaniel's basic point, as I understand it, is that one common type of behavior that we should be able to deal with, is flagrant and aggressive abuse, likely from people otherwise not involved in Scipy. He gives this example "Last night someone logged into the #scipy channel on Freenode and started pasting racial slurs in giant letters.". Nathaniel then goes on to argue that the language and procedures in the CoC as stands don't apply to that case. I think that's reasonable, but I think we have to be careful to distinguish: 1) obvious flagrant abuse, likely from someone who does not contribute, possibly from someone who does contribute who is having a breakdown of some sort and 2) discussions that started in good faith and have gone out of control. It's true that the current code of conduct is aimed more or less squarely at the second. I don't personally think we're going to have too much trouble distinguishing these two cases, so I'm going to suggest that, instead of switching the doc to aiming at case 1 rather than case 2, we have a safely-valve mechanism for case 1. This would go something like: """ As a special case, we know that it is painfully common for internet communication to start at or devolve into obvious and flagrant abuse including violent, racist and sexist language. In the specific case of violent, racist or sexist language, these {named moderators} will use the following procedure: * immediately disconnect the person from all Scipy communication channels; * if the originator appears to be a previous contributor, the moderator may try to contact the contributor by some other means to check whether their account has been hacked. * if the originator is in fact a previous contributor, and the contributor wants to be reconnected to the Scipy channels, then {consider some cooling off period, an agreement not to repeat the behavior, and email moderation. A previous contributor also has the right to an appeal to the code of conduct committee}. * in every case, the moderator should make a reasonable effort to contact the originator, and tell them specifically how their language qualifies as "violent, racist or sexist language", and they should copy this explanation to the code of conduct committee. The code of conduct committee should formally review and sign off on these cases every year to make sure this mechanism is not being used to control ordinary heated disagreement. """ I've argued before [1] that the best way to think about these documents, is in terms of specific use-cases. In Nathaniel's case above, I think it's fairly obvious how the mechanism above would work. Next we consider the famous case of the sexist joke on the Ubuntu mailing list [2]. I think that would also qualify for the mechanism above, but where we would expect the resolution to be that the originator would have to agree not to post sexist material to that list, and be moderated for a while, Last we consider the SpacedGirl Software Carpentry Case [1], where this procedure could not reasonably be invoked, and the rest of the current code of conduct would apply. Cheers, Matthew [1] https://github.com/jupyter/governance/pull/23#issuecomment-269244281 [2] http://geekfeminism.wikia.com/wiki/Ubuntu_Code_of_Conduct_incident From josh.craig.wilson at gmail.com Thu Oct 19 12:35:51 2017 From: josh.craig.wilson at gmail.com (Joshua Wilson) Date: Thu, 19 Oct 2017 11:35:51 -0500 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: <1508370462.5994.94.camel@physicist.net> References: <1508370462.5994.94.camel@physicist.net> Message-ID: Hey Adam, > Does this sound like a worthwhile PR? Yes, definitely > Does the implementation sound reasonable? It's been a while since I've thought about this, but if I recall correctly the problematic region you've found is one that comes up quite frequently--see e.g. page 14 in http://fredrikj.net/math/hypgeom.pdf Floating around in the ether is a method credited to Bill Gosper for handling that region which also uses a recurrence relation (maybe related to/the same as in the paper you cited)? I can never seem to find the original reference (dead link), but I've attached someone's writeup of it. So, your implementation sounds reasonable, but if you really want to dig into it you could check out the Gosper stuff and see how they compare. > Can the PR implement formulas/methods that don't appear in the literature? > Is it going to be a problem if I implement this limit case in the PR? It's implicit in the literature, so I think it's fine. > I don't what reference I would place hyp2f1's doc string The Buhring paper. The formula is something that an informed reader could figure out after reading it. > I would be wiling to maybe add a latex doc to the PR (placed somewhere in the doc folder?) If I recall correctly people were opposed to adding LaTeX docs. (But maybe I recall incorrectly; if so please someone correct me.) I also have various special function write ups that might be handy for future devs... maybe in a separate repo? On Wed, Oct 18, 2017 at 6:47 PM, Adam wrote: > Hello guys, > > I've found a small region in the complex plane where scipy's implementation > of the hypergeometric function hyp2f1 fails. I've documented this error in > issue 8054 on github. > > I am willing to submit a PR that fixes this issue. My PR would basically > implement the analytic continuation formula given in this paper: (Buhring, > An Analytic Continuation of the Hypergeometric Series). I've already > implemented this series in some prototype code written in Fortran and it > agrees well with the values returned by mpmath's implementation of hyp2f1. > > Before I attempt a PR, I just wanted to touch base and ask the group the > following: > > 1) Does this sound like a worthwhile PR? The failure region is somewhat > small and I don't know with what urgency people would want this fixed. > > 2) Does the implementation sound reasonable? My background is physics and so > I haven't done a complete literature search looking for the *fastest* > algorithm. All I can say that the Buhring's formula works and my > implementation only seems to be about %50 slower than the current hyp2f1 (at > points in the complex plane where both methods converge). I would only apply > Buhring's series in the region where hyp2f1 currently diverges. > > 3) Can the PR implement formulas/methods that don't appear in the > literature? Buhring's paper *only* gives the analytic continuation for the > case where the difference between the a/b parameters is NOT an integer. When > a-b=m, the limit case of his series can be derived using a method described > in "The Special Functions and Their Approximations" by Y. Luke (as Buhling > mentions in his paper). I've derived the formula for this limit case and > have an implementation of it that produces values in agreement with mpmath. > Is it going to be a problem if I implement this limit case in the PR? I ask > because I don't what reference I would place hyp2f1's doc string. I would be > wiling to maybe add a latex doc to the PR (placed somewhere in the doc > folder?) that contains the formula so that future scipy devs have something > to reference when reviewing hyp2f1's source code. > > Anyways, let me know if my idea for a PR sounds like a good idea! I > apologize for the longish email, but this is my first time trying to > contribute to scipy... > > --Adam > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: Vogt-Hypergeometric_2F1_Using_a_Recipe_of_Gosper.pdf Type: application/pdf Size: 61277 bytes Desc: not available URL: From ralf.gommers at gmail.com Thu Oct 19 14:06:06 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 19 Oct 2017 11:06:06 -0700 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: On Wed, Oct 18, 2017 at 7:59 PM, Matt Haberland wrote: > I can make it. > > On Wed, Oct 18, 2017 at 11:58 AM, Matthew Brett > wrote: > >> Hi, >> >> On Tue, Oct 17, 2017 at 7:18 AM, Ralf Gommers >> wrote: >> > >> > >> > On Mon, Oct 16, 2017 at 10:15 PM, Nathaniel Smith >> wrote: >> >> >> >> On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers >> >> wrote: >> >> > >> >> > Hi all, there haven't been more comments on the PR in the last 10 >> days >> >> > and >> >> > so far it seems everyone is happy. I said earlier that I'd organise a >> >> > public >> >> > conference call in order to give another venue for input, and I'd >> still >> >> > like >> >> > to do that. So here's a proposal: >> >> > >> >> > Thursday 19 Oct at 7pm UCT on Google Hangouts >> > Link for the call starting in an hour: https://hangouts.google.com/call/KRDkcjS3HQl-LMI6hbpzAAEM This will work best with Chrome. Recent versions of Firefox, IE, etc. will also work but keep in mind that outdated browser versions may not connect. Cheers, Ralf > >> > >> >> > We've puzzled with time zones before, the best one was very early >> >> > morning in >> >> > Australia and late evening in Russia. This time will be 6am in >> Sydney, >> >> > 10pm >> >> > in Moscow, 8pm CET, 3pm US east cost, noon US west coast. >> >> >> >> I can attend the first half hour, anyway... and I'll try to comment on >> >> the PR before then too. >> >> >> >> > Also, it would be great to get a few volunteers for the CoC >> committee. >> >> > Any >> >> > takers? >> >> >> >> Sure. >> > >> > >> > Thanks! >> > >> > Anyone else? Note that (I think) it's not essential that all committee >> > members are part of the core developer team. If you're part of the >> community >> > and are interested in being on this commitee, please let us know >> (offline >> > questions or expressions of interest also welcome). If you have >> experience >> > with CoCs and/or can increase the diversity of experiences and >> viewpoints on >> > the committee, that would be doubly welcome. >> >> I can make it, and would like to join. >> >> Cheers, >> >> Matthew >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > > > > -- > Matt Haberland > Assistant Adjunct Professor in the Program in Computing > Department of Mathematics > 7620E Math Sciences Building, UCLA > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Thu Oct 19 14:09:23 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 19 Oct 2017 11:09:23 -0700 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: On Thu, Oct 19, 2017 at 2:11 AM, Matthew Brett wrote: > Hi, > > Back to the code of conduct discussion, Nathaniel has raised a > pertinent theme over at the Scipy PR - main comment at: > > https://github.com/scipy/scipy/pull/7963#discussion_r145580285 > > Nathaniel's basic point, as I understand it, is that one common type > of behavior that we should be able to deal with, is flagrant and > aggressive abuse, likely from people otherwise not involved in Scipy. > He gives this example "Last night someone logged into the #scipy > channel on Freenode and started pasting racial slurs in giant > letters.". > > Nathaniel then goes on to argue that the language and procedures in > the CoC as stands don't apply to that case. > > I think that's reasonable, but I think we have to be careful to > distinguish: > > 1) obvious flagrant abuse, likely from someone who does not > contribute, possibly from someone who does contribute who is having a > breakdown of some sort and > 2) discussions that started in good faith and have gone out of control. > > It's true that the current code of conduct is aimed more or less > squarely at the second. > > I don't personally think we're going to have too much trouble > distinguishing these two cases, so I'm going to suggest that, instead > of switching the doc to aiming at case 1 rather than case 2, we have a > safely-valve mechanism for case 1. This would go something like: > > """ > As a special case, Your suggestions all make sense, but I suggest not calling one of possible types of cases a "special case". Ralf we know that it is painfully common for internet > communication to start at or devolve into obvious and flagrant abuse > including violent, racist and sexist language. In the specific case > of violent, racist or sexist language, these {named moderators} will > use the following procedure: > > * immediately disconnect the person from all Scipy communication channels; > * if the originator appears to be a previous contributor, the > moderator may try to contact the contributor by some other means to > check whether their account has been hacked. > * if the originator is in fact a previous contributor, and the > contributor wants to be reconnected to the Scipy channels, then > {consider some cooling off period, an agreement not to repeat the > behavior, and email moderation. A previous contributor also has the > right to an appeal to the code of conduct committee}. > * in every case, the moderator should make a reasonable effort to > contact the originator, and tell them specifically how their language > qualifies as "violent, racist or sexist language", and they should > copy this explanation to the code of conduct committee. The code of > conduct committee should formally review and sign off on these cases > every year to make sure this mechanism is not being used to control > ordinary heated disagreement. > """ > > I've argued before [1] that the best way to think about these > documents, is in terms of specific use-cases. In Nathaniel's case > above, I think it's fairly obvious how the mechanism above would work. > Next we consider the famous case of the sexist joke on the Ubuntu > mailing list [2]. I think that would also qualify for the mechanism > above, but where we would expect the resolution to be that the > originator would have to agree not to post sexist material to that > list, and be moderated for a while, Last we consider the SpacedGirl > Software Carpentry Case [1], where this procedure could not reasonably > be invoked, and the rest of the current code of conduct would apply. > > Cheers, > > Matthew > > [1] https://github.com/jupyter/governance/pull/23#issuecomment-269244281 > [2] http://geekfeminism.wikia.com/wiki/Ubuntu_Code_of_Conduct_incident > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Former at physicist.net Thu Oct 19 14:58:59 2017 From: Former at physicist.net (Adam) Date: Thu, 19 Oct 2017 11:58:59 -0700 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: References: <1508370462.5994.94.camel@physicist.net> Message-ID: Okay cool; thanks for the helpful reply! I'll look at Gosper's method and see how it compares with Buhring's method. For now I'll plan on doing a PR that implements one of these two methods. I was just worried that I might end up doing a lot of work on a PR that implements Buhring's series only to have a reviewer reject it saying "Well, you should have used such-and-such's algorithm which is must faster, much more accurate, etc." I'll also hold off on adding a latex doc to the repo of the actual formulas used for the b-a=integer special case (unless I hear otherwise). Thanks again! --Adam -----Original Message----- From: Joshua Wilson Sent: Thursday, October 19, 2017 9:35 AM To: SciPy Developers List Subject: Re: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 Hey Adam, > Does this sound like a worthwhile PR? Yes, definitely > Does the implementation sound reasonable? It's been a while since I've thought about this, but if I recall correctly the problematic region you've found is one that comes up quite frequently--see e.g. page 14 in http://fredrikj.net/math/hypgeom.pdf Floating around in the ether is a method credited to Bill Gosper for handling that region which also uses a recurrence relation (maybe related to/the same as in the paper you cited)? I can never seem to find the original reference (dead link), but I've attached someone's writeup of it. So, your implementation sounds reasonable, but if you really want to dig into it you could check out the Gosper stuff and see how they compare. > Can the PR implement formulas/methods that don't appear in the literature? > Is it going to be a problem if I implement this limit case in the PR? It's implicit in the literature, so I think it's fine. > I don't what reference I would place hyp2f1's doc string The Buhring paper. The formula is something that an informed reader could figure out after reading it. > I would be wiling to maybe add a latex doc to the PR (placed somewhere in > the doc folder?) If I recall correctly people were opposed to adding LaTeX docs. (But maybe I recall incorrectly; if so please someone correct me.) I also have various special function write ups that might be handy for future devs... maybe in a separate repo? On Wed, Oct 18, 2017 at 6:47 PM, Adam wrote: > Hello guys, > > I've found a small region in the complex plane where scipy's > implementation > of the hypergeometric function hyp2f1 fails. I've documented this error in > issue 8054 on github. > > I am willing to submit a PR that fixes this issue. My PR would basically > implement the analytic continuation formula given in this paper: (Buhring, > An Analytic Continuation of the Hypergeometric Series). I've already > implemented this series in some prototype code written in Fortran and it > agrees well with the values returned by mpmath's implementation of hyp2f1. > > Before I attempt a PR, I just wanted to touch base and ask the group the > following: > > 1) Does this sound like a worthwhile PR? The failure region is somewhat > small and I don't know with what urgency people would want this fixed. > > 2) Does the implementation sound reasonable? My background is physics and > so > I haven't done a complete literature search looking for the *fastest* > algorithm. All I can say that the Buhring's formula works and my > implementation only seems to be about %50 slower than the current hyp2f1 > (at > points in the complex plane where both methods converge). I would only > apply > Buhring's series in the region where hyp2f1 currently diverges. > > 3) Can the PR implement formulas/methods that don't appear in the > literature? Buhring's paper *only* gives the analytic continuation for the > case where the difference between the a/b parameters is NOT an integer. > When > a-b=m, the limit case of his series can be derived using a method > described > in "The Special Functions and Their Approximations" by Y. Luke (as Buhling > mentions in his paper). I've derived the formula for this limit case and > have an implementation of it that produces values in agreement with > mpmath. > Is it going to be a problem if I implement this limit case in the PR? I > ask > because I don't what reference I would place hyp2f1's doc string. I would > be > wiling to maybe add a latex doc to the PR (placed somewhere in the doc > folder?) that contains the formula so that future scipy devs have > something > to reference when reviewing hyp2f1's source code. > > Anyways, let me know if my idea for a PR sounds like a good idea! I > apologize for the longish email, but this is my first time trying to > contribute to scipy... > > --Adam > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev From ralf.gommers at gmail.com Thu Oct 19 15:00:52 2017 From: ralf.gommers at gmail.com (ralf.gommers at gmail.com) Date: Fri, 20 Oct 2017 08:00:52 +1300 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> Message-ID: <3AA0546E-C9E6-49E9-83D2-A48298E84753@gmail.com> Sorry I might be a bit late, IT issues (windows machine:( ) Sent from my iPhone > On 20/10/2017, at 7:06 AM, Ralf Gommers wrote: > > > >> On Wed, Oct 18, 2017 at 7:59 PM, Matt Haberland wrote: >> I can make it. >> >>> On Wed, Oct 18, 2017 at 11:58 AM, Matthew Brett wrote: >>> Hi, >>> >>> On Tue, Oct 17, 2017 at 7:18 AM, Ralf Gommers wrote: >>> > >>> > >>> > On Mon, Oct 16, 2017 at 10:15 PM, Nathaniel Smith wrote: >>> >> >>> >> On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers >>> >> wrote: >>> >> > >>> >> > Hi all, there haven't been more comments on the PR in the last 10 days >>> >> > and >>> >> > so far it seems everyone is happy. I said earlier that I'd organise a >>> >> > public >>> >> > conference call in order to give another venue for input, and I'd still >>> >> > like >>> >> > to do that. So here's a proposal: >>> >> > >>> >> > Thursday 19 Oct at 7pm UCT on Google Hangouts > > Link for the call starting in an hour: https://hangouts.google.com/call/KRDkcjS3HQl-LMI6hbpzAAEM > > This will work best with Chrome. Recent versions of Firefox, IE, etc. will also work but keep in mind that outdated browser versions may not connect. > > Cheers, > Ralf > > > > >>> >> > >>> >> > We've puzzled with time zones before, the best one was very early >>> >> > morning in >>> >> > Australia and late evening in Russia. This time will be 6am in Sydney, >>> >> > 10pm >>> >> > in Moscow, 8pm CET, 3pm US east cost, noon US west coast. >>> >> >>> >> I can attend the first half hour, anyway... and I'll try to comment on >>> >> the PR before then too. >>> >> >>> >> > Also, it would be great to get a few volunteers for the CoC committee. >>> >> > Any >>> >> > takers? >>> >> >>> >> Sure. >>> > >>> > >>> > Thanks! >>> > >>> > Anyone else? Note that (I think) it's not essential that all committee >>> > members are part of the core developer team. If you're part of the community >>> > and are interested in being on this commitee, please let us know (offline >>> > questions or expressions of interest also welcome). If you have experience >>> > with CoCs and/or can increase the diversity of experiences and viewpoints on >>> > the committee, that would be doubly welcome. >>> >>> I can make it, and would like to join. >>> >>> Cheers, >>> >>> Matthew >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >> >> >> >> -- >> Matt Haberland >> Assistant Adjunct Professor in the Program in Computing >> Department of Mathematics >> 7620E Math Sciences Building, UCLA >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Oct 19 19:00:17 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 20 Oct 2017 00:00:17 +0100 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: <3AA0546E-C9E6-49E9-83D2-A48298E84753@gmail.com> References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> <3AA0546E-C9E6-49E9-83D2-A48298E84753@gmail.com> Message-ID: Hi, I tried to distill the results of the discussion into a PR to Ralf's PR: https://github.com/rgommers/scipy/pull/14 Nathaniel - I probably didn't convey this well over the broken line we were on, but I do fully accept that we have to be careful about subtle discrimination, against women in particular, and I have added that as a specific concern in the PR, but please feel free to insist if I haven't captured what you meant. Cheers, Matthew From matthew.brett at gmail.com Thu Oct 19 19:32:57 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 20 Oct 2017 00:32:57 +0100 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> <3AA0546E-C9E6-49E9-83D2-A48298E84753@gmail.com> Message-ID: On Fri, Oct 20, 2017 at 12:00 AM, Matthew Brett wrote: > Hi, > > I tried to distill the results of the discussion into a PR to Ralf's PR: > > https://github.com/rgommers/scipy/pull/14 > > Nathaniel - I probably didn't convey this well over the broken line we > were on, but I do fully accept that we have to be careful about subtle > discrimination, against women in particular, and I have added that as > a specific concern in the PR, but please feel free to insist if I > haven't captured what you meant. Also - here is the work I was referring to about the uses to which labeling is put to in order to damage and exclude: http://kwesthues.com/diffprof.htm In this case above it is 'difficult' as applied to a professor, but I'd add 'asshole' or 'jerk' as applied to a contributor. Cheers, Matthew From tpudlik at gmail.com Thu Oct 19 23:04:37 2017 From: tpudlik at gmail.com (Ted Pudlik) Date: Fri, 20 Oct 2017 03:04:37 +0000 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: References: <1508370462.5994.94.camel@physicist.net> Message-ID: Concerning the actual formulas: there's a compromise between leaving them implicit and creating a separate LaTeX doc. You could add the formulas to the docstring . The LaTeX will render in the HTML version of the documentation (example ). I'm not sure how the maintainers feel about this, though (this is just a suggestion from a "private citizen"). On Thu, Oct 19, 2017 at 11:59 AM Adam wrote: > Okay cool; thanks for the helpful reply! > > I'll look at Gosper's method and see how it compares with Buhring's method. > For now I'll plan on doing a PR that implements one of these two methods. > I > was just worried that I might end up doing a lot of work on a PR that > implements Buhring's series only to have a reviewer reject it saying "Well, > you should have used such-and-such's algorithm which is must faster, much > more accurate, etc." > > I'll also hold off on adding a latex doc to the repo of the actual formulas > used for the b-a=integer special case (unless I hear otherwise). > > Thanks again! > > --Adam > > -----Original Message----- > From: Joshua Wilson > Sent: Thursday, October 19, 2017 9:35 AM > To: SciPy Developers List > Subject: Re: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function > hyp2f1 > > Hey Adam, > > > Does this sound like a worthwhile PR? > > Yes, definitely > > > Does the implementation sound reasonable? > > It's been a while since I've thought about this, but if I recall > correctly the problematic region you've found is one that comes up > quite frequently--see e.g. page 14 in > > http://fredrikj.net/math/hypgeom.pdf > > Floating around in the ether is a method credited to Bill Gosper for > handling that region which also uses a recurrence relation (maybe > related to/the same as in the paper you cited)? I can never seem to > find the original reference (dead link), but I've attached someone's > writeup of it. > > So, your implementation sounds reasonable, but if you really want to > dig into it you could check out the Gosper stuff and see how they > compare. > > > Can the PR implement formulas/methods that don't appear in the > literature? > > Is it going to be a problem if I implement this limit case in the PR? > > It's implicit in the literature, so I think it's fine. > > > I don't what reference I would place hyp2f1's doc string > > The Buhring paper. The formula is something that an informed reader > could figure out after reading it. > > > I would be wiling to maybe add a latex doc to the PR (placed somewhere in > > the doc folder?) > > If I recall correctly people were opposed to adding LaTeX docs. (But > maybe I recall incorrectly; if so please someone correct me.) I also > have various special function write ups that might be handy for future > devs... maybe in a separate repo? > > On Wed, Oct 18, 2017 at 6:47 PM, Adam wrote: > > Hello guys, > > > > I've found a small region in the complex plane where scipy's > > implementation > > of the hypergeometric function hyp2f1 fails. I've documented this error > in > > issue 8054 on github. > > > > I am willing to submit a PR that fixes this issue. My PR would basically > > implement the analytic continuation formula given in this paper: > (Buhring, > > An Analytic Continuation of the Hypergeometric Series). I've already > > implemented this series in some prototype code written in Fortran and it > > agrees well with the values returned by mpmath's implementation of > hyp2f1. > > > > Before I attempt a PR, I just wanted to touch base and ask the group the > > following: > > > > 1) Does this sound like a worthwhile PR? The failure region is somewhat > > small and I don't know with what urgency people would want this fixed. > > > > 2) Does the implementation sound reasonable? My background is physics and > > so > > I haven't done a complete literature search looking for the *fastest* > > algorithm. All I can say that the Buhring's formula works and my > > implementation only seems to be about %50 slower than the current hyp2f1 > > (at > > points in the complex plane where both methods converge). I would only > > apply > > Buhring's series in the region where hyp2f1 currently diverges. > > > > 3) Can the PR implement formulas/methods that don't appear in the > > literature? Buhring's paper *only* gives the analytic continuation for > the > > case where the difference between the a/b parameters is NOT an integer. > > When > > a-b=m, the limit case of his series can be derived using a method > > described > > in "The Special Functions and Their Approximations" by Y. Luke (as > Buhling > > mentions in his paper). I've derived the formula for this limit case and > > have an implementation of it that produces values in agreement with > > mpmath. > > Is it going to be a problem if I implement this limit case in the PR? I > > ask > > because I don't what reference I would place hyp2f1's doc string. I would > > be > > wiling to maybe add a latex doc to the PR (placed somewhere in the doc > > folder?) that contains the formula so that future scipy devs have > > something > > to reference when reviewing hyp2f1's source code. > > > > Anyways, let me know if my idea for a PR sounds like a good idea! I > > apologize for the longish email, but this is my first time trying to > > contribute to scipy... > > > > --Adam > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Fri Oct 20 01:47:40 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 19 Oct 2017 22:47:40 -0700 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> <3AA0546E-C9E6-49E9-83D2-A48298E84753@gmail.com> Message-ID: On Thu, Oct 19, 2017 at 4:00 PM, Matthew Brett wrote: > Hi, > > I tried to distill the results of the discussion into a PR to Ralf's PR: > > https://github.com/rgommers/scipy/pull/14 Great, thanks Matthew. That PR is related to the longest discussion we had. Here I'll also briefly summarize the other things we discussed: 1. A question on the CoC PR on whether we need a separate CoC committee or can make do with either a single person or letting the SciPy steering committee handle the job. The outcome was that we do want a CoC committee, ideally 3-5 people in size. 2. The discussion about different cases that Matthew's PR responds to. Discussion started from this comment: https://github.com/scipy/scipy/pull/7963#discussion_r145582715, and a couple of previous emails on this mailing list also were related to that comment. 3. Timeline for merging the CoC. I will incorporate Matthew's PR and address other open comments tonight. Then I'll be offline until Monday evening. Hopefully by then the remaining points for discussion have been converged. I'd like to merge the CoC on Tuesday and release 1.0 on Wednesday. Cheers, Ralf > > Nathaniel - I probably didn't convey this well over the broken line we > were on, but I do fully accept that we have to be careful about subtle > discrimination, against women in particular, and I have added that as > a specific concern in the PR, but please feel free to insist if I > haven't captured what you meant. > > Cheers, > > Matthew > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Fri Oct 20 02:01:10 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 19 Oct 2017 23:01:10 -0700 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: References: <1508370462.5994.94.camel@physicist.net> Message-ID: On Thu, Oct 19, 2017 at 8:04 PM, Ted Pudlik wrote: > Concerning the actual formulas: there's a compromise between leaving them > implicit and creating a separate LaTeX doc. You could add the formulas to > the docstring > . > The LaTeX will render in the HTML version of the documentation (example > ). > I'm not sure how the maintainers feel about this, though (this is just a > suggestion from a "private citizen"). > In general: using LaTeX can be a good idea, the one thing that has to be kept in mind is readability as plain text (important both for reading docstrings in IPython terminal and when working on the code in an editor). Best to add LaTeX formulas to the Notes section rather than in the first sentences. And avoid usage of things like \left[ that make the rendered html slightly prettier but the actual math much harder to read as plain text. Here's a recent PR with discussion about various LaTeX styles: https://github.com/scipy/scipy/pull/7756. The style that got merged is about right. Cheers, Ralf > > > On Thu, Oct 19, 2017 at 11:59 AM Adam wrote: > >> Okay cool; thanks for the helpful reply! >> >> I'll look at Gosper's method and see how it compares with Buhring's >> method. >> For now I'll plan on doing a PR that implements one of these two >> methods. I >> was just worried that I might end up doing a lot of work on a PR that >> implements Buhring's series only to have a reviewer reject it saying >> "Well, >> you should have used such-and-such's algorithm which is must faster, much >> more accurate, etc." >> >> I'll also hold off on adding a latex doc to the repo of the actual >> formulas >> used for the b-a=integer special case (unless I hear otherwise). >> >> Thanks again! >> >> --Adam >> >> -----Original Message----- >> From: Joshua Wilson >> Sent: Thursday, October 19, 2017 9:35 AM >> To: SciPy Developers List >> Subject: Re: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function >> hyp2f1 >> >> Hey Adam, >> >> > Does this sound like a worthwhile PR? >> >> Yes, definitely >> >> > Does the implementation sound reasonable? >> >> It's been a while since I've thought about this, but if I recall >> correctly the problematic region you've found is one that comes up >> quite frequently--see e.g. page 14 in >> >> http://fredrikj.net/math/hypgeom.pdf >> >> Floating around in the ether is a method credited to Bill Gosper for >> handling that region which also uses a recurrence relation (maybe >> related to/the same as in the paper you cited)? I can never seem to >> find the original reference (dead link), but I've attached someone's >> writeup of it. >> >> So, your implementation sounds reasonable, but if you really want to >> dig into it you could check out the Gosper stuff and see how they >> compare. >> >> > Can the PR implement formulas/methods that don't appear in the >> literature? >> > Is it going to be a problem if I implement this limit case in the PR? >> >> It's implicit in the literature, so I think it's fine. >> >> > I don't what reference I would place hyp2f1's doc string >> >> The Buhring paper. The formula is something that an informed reader >> could figure out after reading it. >> >> > I would be wiling to maybe add a latex doc to the PR (placed somewhere >> in >> > the doc folder?) >> >> If I recall correctly people were opposed to adding LaTeX docs. (But >> maybe I recall incorrectly; if so please someone correct me.) I also >> have various special function write ups that might be handy for future >> devs... maybe in a separate repo? >> >> On Wed, Oct 18, 2017 at 6:47 PM, Adam wrote: >> > Hello guys, >> > >> > I've found a small region in the complex plane where scipy's >> > implementation >> > of the hypergeometric function hyp2f1 fails. I've documented this error >> in >> > issue 8054 on github. >> > >> > I am willing to submit a PR that fixes this issue. My PR would basically >> > implement the analytic continuation formula given in this paper: >> (Buhring, >> > An Analytic Continuation of the Hypergeometric Series). I've already >> > implemented this series in some prototype code written in Fortran and it >> > agrees well with the values returned by mpmath's implementation of >> hyp2f1. >> > >> > Before I attempt a PR, I just wanted to touch base and ask the group the >> > following: >> > >> > 1) Does this sound like a worthwhile PR? The failure region is somewhat >> > small and I don't know with what urgency people would want this fixed. >> > >> > 2) Does the implementation sound reasonable? My background is physics >> and >> > so >> > I haven't done a complete literature search looking for the *fastest* >> > algorithm. All I can say that the Buhring's formula works and my >> > implementation only seems to be about %50 slower than the current hyp2f1 >> > (at >> > points in the complex plane where both methods converge). I would only >> > apply >> > Buhring's series in the region where hyp2f1 currently diverges. >> > >> > 3) Can the PR implement formulas/methods that don't appear in the >> > literature? Buhring's paper *only* gives the analytic continuation for >> the >> > case where the difference between the a/b parameters is NOT an integer. >> > When >> > a-b=m, the limit case of his series can be derived using a method >> > described >> > in "The Special Functions and Their Approximations" by Y. Luke (as >> Buhling >> > mentions in his paper). I've derived the formula for this limit case and >> > have an implementation of it that produces values in agreement with >> > mpmath. >> > Is it going to be a problem if I implement this limit case in the PR? I >> > ask >> > because I don't what reference I would place hyp2f1's doc string. I >> would >> > be >> > wiling to maybe add a latex doc to the PR (placed somewhere in the doc >> > folder?) that contains the formula so that future scipy devs have >> > something >> > to reference when reviewing hyp2f1's source code. >> > >> > Anyways, let me know if my idea for a PR sounds like a good idea! I >> > apologize for the longish email, but this is my first time trying to >> > contribute to scipy... >> > >> > --Adam >> > >> > _______________________________________________ >> > SciPy-Dev mailing list >> > SciPy-Dev at python.org >> > https://mail.python.org/mailman/listinfo/scipy-dev >> > >> >> >> >> >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Fri Oct 20 08:54:23 2017 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 20 Oct 2017 08:54:23 -0400 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: References: <1508370462.5994.94.camel@physicist.net> Message-ID: One possibility: Currently the only more extensive Latex based documentation is in the tutorial. I think it would be possible to add a technical appendix or something like that to the scipy.special tutorial, a bit similar to the distributions formulas attached to the stats tutorial. For example Boost, last time I checked, had long documentation for the special functions, which might be too long to fit in docstrings. I don't know how much there would be for special functions and whether it is difficult to maintain those notes. However, I think it would be good to have notes that developers have already written available for future developers and users that are interested in technical details. Josef On Fri, Oct 20, 2017 at 2:01 AM, Ralf Gommers wrote: > > > On Thu, Oct 19, 2017 at 8:04 PM, Ted Pudlik wrote: > >> Concerning the actual formulas: there's a compromise between leaving them >> implicit and creating a separate LaTeX doc. You could add the formulas to >> the docstring >> . >> The LaTeX will render in the HTML version of the documentation (example >> ). >> I'm not sure how the maintainers feel about this, though (this is just a >> suggestion from a "private citizen"). >> > > In general: using LaTeX can be a good idea, the one thing that has to be > kept in mind is readability as plain text (important both for reading > docstrings in IPython terminal and when working on the code in an editor). > Best to add LaTeX formulas to the Notes section rather than in the first > sentences. And avoid usage of things like \left[ that make the rendered > html slightly prettier but the actual math much harder to read as plain > text. > > Here's a recent PR with discussion about various LaTeX styles: > https://github.com/scipy/scipy/pull/7756. The style that got merged is > about right. > > Cheers, > Ralf > > >> >> >> On Thu, Oct 19, 2017 at 11:59 AM Adam wrote: >> >>> Okay cool; thanks for the helpful reply! >>> >>> I'll look at Gosper's method and see how it compares with Buhring's >>> method. >>> For now I'll plan on doing a PR that implements one of these two >>> methods. I >>> was just worried that I might end up doing a lot of work on a PR that >>> implements Buhring's series only to have a reviewer reject it saying >>> "Well, >>> you should have used such-and-such's algorithm which is must faster, much >>> more accurate, etc." >>> >>> I'll also hold off on adding a latex doc to the repo of the actual >>> formulas >>> used for the b-a=integer special case (unless I hear otherwise). >>> >>> Thanks again! >>> >>> --Adam >>> >>> -----Original Message----- >>> From: Joshua Wilson >>> Sent: Thursday, October 19, 2017 9:35 AM >>> To: SciPy Developers List >>> Subject: Re: [SciPy-Dev] Fixing a bug with scipy's hypergeometric >>> function >>> hyp2f1 >>> >>> Hey Adam, >>> >>> > Does this sound like a worthwhile PR? >>> >>> Yes, definitely >>> >>> > Does the implementation sound reasonable? >>> >>> It's been a while since I've thought about this, but if I recall >>> correctly the problematic region you've found is one that comes up >>> quite frequently--see e.g. page 14 in >>> >>> http://fredrikj.net/math/hypgeom.pdf >>> >>> Floating around in the ether is a method credited to Bill Gosper for >>> handling that region which also uses a recurrence relation (maybe >>> related to/the same as in the paper you cited)? I can never seem to >>> find the original reference (dead link), but I've attached someone's >>> writeup of it. >>> >>> So, your implementation sounds reasonable, but if you really want to >>> dig into it you could check out the Gosper stuff and see how they >>> compare. >>> >>> > Can the PR implement formulas/methods that don't appear in the >>> literature? >>> > Is it going to be a problem if I implement this limit case in the PR? >>> >>> It's implicit in the literature, so I think it's fine. >>> >>> > I don't what reference I would place hyp2f1's doc string >>> >>> The Buhring paper. The formula is something that an informed reader >>> could figure out after reading it. >>> >>> > I would be wiling to maybe add a latex doc to the PR (placed somewhere >>> in >>> > the doc folder?) >>> >>> If I recall correctly people were opposed to adding LaTeX docs. (But >>> maybe I recall incorrectly; if so please someone correct me.) I also >>> have various special function write ups that might be handy for future >>> devs... maybe in a separate repo? >>> >>> On Wed, Oct 18, 2017 at 6:47 PM, Adam wrote: >>> > Hello guys, >>> > >>> > I've found a small region in the complex plane where scipy's >>> > implementation >>> > of the hypergeometric function hyp2f1 fails. I've documented this >>> error in >>> > issue 8054 on github. >>> > >>> > I am willing to submit a PR that fixes this issue. My PR would >>> basically >>> > implement the analytic continuation formula given in this paper: >>> (Buhring, >>> > An Analytic Continuation of the Hypergeometric Series). I've already >>> > implemented this series in some prototype code written in Fortran and >>> it >>> > agrees well with the values returned by mpmath's implementation of >>> hyp2f1. >>> > >>> > Before I attempt a PR, I just wanted to touch base and ask the group >>> the >>> > following: >>> > >>> > 1) Does this sound like a worthwhile PR? The failure region is somewhat >>> > small and I don't know with what urgency people would want this fixed. >>> > >>> > 2) Does the implementation sound reasonable? My background is physics >>> and >>> > so >>> > I haven't done a complete literature search looking for the *fastest* >>> > algorithm. All I can say that the Buhring's formula works and my >>> > implementation only seems to be about %50 slower than the current >>> hyp2f1 >>> > (at >>> > points in the complex plane where both methods converge). I would only >>> > apply >>> > Buhring's series in the region where hyp2f1 currently diverges. >>> > >>> > 3) Can the PR implement formulas/methods that don't appear in the >>> > literature? Buhring's paper *only* gives the analytic continuation for >>> the >>> > case where the difference between the a/b parameters is NOT an integer. >>> > When >>> > a-b=m, the limit case of his series can be derived using a method >>> > described >>> > in "The Special Functions and Their Approximations" by Y. Luke (as >>> Buhling >>> > mentions in his paper). I've derived the formula for this limit case >>> and >>> > have an implementation of it that produces values in agreement with >>> > mpmath. >>> > Is it going to be a problem if I implement this limit case in the PR? I >>> > ask >>> > because I don't what reference I would place hyp2f1's doc string. I >>> would >>> > be >>> > wiling to maybe add a latex doc to the PR (placed somewhere in the doc >>> > folder?) that contains the formula so that future scipy devs have >>> > something >>> > to reference when reviewing hyp2f1's source code. >>> > >>> > Anyways, let me know if my idea for a PR sounds like a good idea! I >>> > apologize for the longish email, but this is my first time trying to >>> > contribute to scipy... >>> > >>> > --Adam >>> > >>> > _______________________________________________ >>> > SciPy-Dev mailing list >>> > SciPy-Dev at python.org >>> > https://mail.python.org/mailman/listinfo/scipy-dev >>> > >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at python.org >>> https://mail.python.org/mailman/listinfo/scipy-dev >>> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Former at physicist.net Fri Oct 20 21:23:01 2017 From: Former at physicist.net (Adam) Date: Fri, 20 Oct 2017 18:23:01 -0700 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: References: <1508370462.5994.94.camel@physicist.net> Message-ID: <1508548981.3961.10.camel@physicist.net> I can certainly add the formulas to the doc string if that's what people want. ?My only concern is that the a-b=m case involves about a page of formula's and would take a lot of space in the doc string (I've attached the pdf from my latex file of the formulas). Originally I was thinking that the docstring would just contain some reference to the pdf document, e.g., "See the pdf at location X for the method used when a-b is an integer."? But like I said, I can put them wherever they need to go; I justed wanted to make sure that future maintainers have some reference as to what the code is trying to do... --Adam On Fri, 2017-10-20 at 08:54 -0400, josef.pktd at gmail.com wrote: > One possibility: > Currently the only more extensive Latex based documentation is in the > tutorial. > I think it would be possible to add a technical appendix or something > like that > to the scipy.special tutorial, a bit similar to the distributions > formulas attached to the? > stats tutorial. > > For example Boost, last time I checked, had long documentation for > the special > functions, which might be too long to fit in docstrings. > > I don't know how much there would be for special functions and > whether it is? > difficult to maintain those notes. However, I think it would be good > to have > notes that developers have already written available for future > developers and users that are interested in technical details. > > > Josef > > > On Fri, Oct 20, 2017 at 2:01 AM, Ralf Gommers > wrote: > > > > > > On Thu, Oct 19, 2017 at 8:04 PM, Ted Pudlik > > wrote: > > > Concerning the actual formulas: there's a compromise between > > > leaving them implicit and creating a separate LaTeX doc.? You > > > could add the formulas to the docstring.? The LaTeX will render > > > in the HTML version of the documentation (example).? I'm not sure > > > how the maintainers feel about this, though (this is just a > > > suggestion from a "private citizen"). > > > > > In general: using LaTeX can be a good idea, the one thing that has > > to be kept in mind is readability as plain text (important both for > > reading docstrings in IPython terminal and when working on the code > > in an editor). Best to add LaTeX formulas to the Notes section > > rather than in the first sentences. And avoid usage of things like > > \left[ that make the rendered html slightly prettier but the actual > > math much harder to read as plain text. > > > > Here's a recent PR with discussion about various LaTeX styles: http > > s://github.com/scipy/scipy/pull/7756. The style that got merged is > > about right. > > > > Cheers, > > Ralf > > > > > > > > > > > > > > On Thu, Oct 19, 2017 at 11:59 AM Adam > > > wrote: > > > > Okay cool; thanks for the helpful reply! > > > > > > > > I'll look at Gosper's method and see how it compares with > > > > Buhring's method. > > > > For now I'll plan on doing a PR that implements one of these > > > > two methods.? I > > > > was just worried that I might end up doing a lot of work on a > > > > PR that > > > > implements Buhring's series only to have a reviewer reject it > > > > saying "Well, > > > > you should have used such-and-such's algorithm which is must > > > > faster, much > > > > more accurate, etc." > > > > > > > > I'll also hold off on adding a latex doc to the repo of the > > > > actual formulas > > > > used for the b-a=integer special case (unless I hear > > > > otherwise). > > > > > > > > Thanks again! > > > > > > > > --Adam > > > > > > > > -----Original Message----- > > > > From: Joshua Wilson > > > > Sent: Thursday, October 19, 2017 9:35 AM > > > > To: SciPy Developers List > > > > Subject: Re: [SciPy-Dev] Fixing a bug with scipy's > > > > hypergeometric function > > > > hyp2f1 > > > > > > > > Hey Adam, > > > > > > > > > Does this sound like a worthwhile PR? > > > > > > > > Yes, definitely > > > > > > > > > Does the implementation sound reasonable? > > > > > > > > It's been a while since I've thought about this, but if I > > > > recall > > > > correctly the problematic region you've found is one that comes > > > > up > > > > quite frequently--see e.g. page 14 in > > > > > > > > http://fredrikj.net/math/hypgeom.pdf > > > > > > > > Floating around in the ether is a method credited to Bill > > > > Gosper for > > > > handling that region which also uses a recurrence relation > > > > (maybe > > > > related to/the same as in the paper you cited)? I can never > > > > seem to > > > > find the original reference (dead link), but I've attached > > > > someone's > > > > writeup of it. > > > > > > > > So, your implementation sounds reasonable, but if you really > > > > want to > > > > dig into it you could check out the Gosper stuff and see how > > > > they > > > > compare. > > > > > > > > > Can the PR implement formulas/methods that don't appear in > > > > the literature? > > > > > Is it going to be a problem if I implement this limit case in > > > > the PR? > > > > > > > > It's implicit in the literature, so I think it's fine. > > > > > > > > > I don't what reference I would place hyp2f1's doc string > > > > > > > > The Buhring paper. The formula is something that an informed > > > > reader > > > > could figure out after reading it. > > > > > > > > > I would be wiling to maybe add a latex doc to the PR (placed > > > > somewhere in > > > > > the doc folder?) > > > > > > > > If I recall correctly people were opposed to adding LaTeX docs. > > > > (But > > > > maybe I recall incorrectly; if so please someone correct me.) I > > > > also > > > > have various special function write ups that might be handy for > > > > future > > > > devs... maybe in a separate repo? > > > > > > > > On Wed, Oct 18, 2017 at 6:47 PM, Adam > > > > wrote: > > > > > Hello guys, > > > > > > > > > > I've found a small region in the complex plane where scipy's > > > > > implementation > > > > > of the hypergeometric function hyp2f1 fails. I've documented > > > > this error in > > > > > issue 8054 on github. > > > > > > > > > > I am willing to submit a PR that fixes this issue. My PR > > > > would basically > > > > > implement the analytic continuation formula given in this > > > > paper: (Buhring, > > > > > An Analytic Continuation of the Hypergeometric Series). I've > > > > already > > > > > implemented this series in some prototype code written in > > > > Fortran and it > > > > > agrees well with the values returned by mpmath's > > > > implementation of hyp2f1. > > > > > > > > > > Before I attempt a PR, I just wanted to touch base and ask > > > > the group the > > > > > following: > > > > > > > > > > 1) Does this sound like a worthwhile PR? The failure region > > > > is somewhat > > > > > small and I don't know with what urgency people would want > > > > this fixed. > > > > > > > > > > 2) Does the implementation sound reasonable? My background is > > > > physics and > > > > > so > > > > > I haven't done a complete literature search looking for the > > > > *fastest* > > > > > algorithm. All I can say that the Buhring's formula works and > > > > my > > > > > implementation only seems to be about %50 slower than the > > > > current hyp2f1 > > > > > (at > > > > > points in the complex plane where both methods converge). I > > > > would only > > > > > apply > > > > > Buhring's series in the region where hyp2f1 currently > > > > diverges. > > > > > > > > > > 3) Can the PR implement formulas/methods that don't appear in > > > > the > > > > > literature? Buhring's paper *only* gives the analytic > > > > continuation for the > > > > > case where the difference between the a/b parameters is NOT > > > > an integer. > > > > > When > > > > > a-b=m, the limit case of his series can be derived using a > > > > method > > > > > described > > > > > in "The Special Functions and Their Approximations" by Y. > > > > Luke (as Buhling > > > > > mentions in his paper). I've derived the formula for this > > > > limit case and > > > > > have an implementation of it that produces values in > > > > agreement with > > > > > mpmath. > > > > > Is it going to be a problem if I implement this limit case in > > > > the PR? I > > > > > ask > > > > > because I don't what reference I would place hyp2f1's doc > > > > string. I would > > > > > be > > > > > wiling to maybe add a latex doc to the PR (placed somewhere > > > > in the doc > > > > > folder?) that contains the formula so that future scipy devs > > > > have > > > > > something > > > > > to reference when reviewing hyp2f1's source code. > > > > > > > > > > Anyways, let me know if my idea for a PR sounds like a good > > > > idea! I > > > > > apologize for the longish email, but this is my first time > > > > trying to > > > > > contribute to scipy... > > > > > > > > > > --Adam > > > > > > > > > > _______________________________________________ > > > > > SciPy-Dev mailing list > > > > > SciPy-Dev at python.org > > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > SciPy-Dev mailing list > > > > SciPy-Dev at python.org > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > _______________________________________________ > > > > SciPy-Dev mailing list > > > > SciPy-Dev at python.org > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > _______________________________________________ > > > SciPy-Dev mailing list > > > SciPy-Dev at python.org > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AB_Integer_Formulas.pdf Type: application/pdf Size: 88033 bytes Desc: not available URL: From andyspiros at gmail.com Mon Oct 23 07:40:59 2017 From: andyspiros at gmail.com (Andrea Arteaga) Date: Mon, 23 Oct 2017 13:40:59 +0200 Subject: [SciPy-Dev] Linear extrapolation in univariate spline Message-ID: Dear SciPy devs, The UnivariateSpline class [1] allows to pass a parameter `ext` to control the behavior of the interpolant outside of the input data range, i.e, for the cases where an extrapolation is required. The four available modes are to perform actual k-degree extrapolation, to return 0, to do constant extrapolation or to fail. These modes are insufficient for my needs. What I would actually need is a linear extrapolation. By definition of the "natural" cubic spline [2], the second derivative will be zero at both ends of the domain. This has the physical meaning of modeling exactly the shape of a ruler bent in such a way to touch a set of points. Before the first point and after the last one, the rules will be straight. This is the kind of extrapolation I would need. I would like to ask if that feature has not been implemented for a good reason, if there are any plans on implementing it and if I can do something. I started to look at the code to see if I could easily implement this mode. In any case I will need some guidance with it. Another thing I should ask is whether there is already a way to specify custom extrapolation modes (e.g. by passing a python function). I think I found the place in the SciPy code where the extrapolation modes are handled, in the `splev.f` file [3]. It does not look too difficult to add a `e .eq. 4` case, which handles linear extrapolation. But I don't know how to access the slopes at both ends of the domain. Thanks and best Andrea Arteaga [1] https://docs.scipy.org/doc/scipy/reference/generated/scipy.interpolate.UnivariateSpline.html#scipy.interpolate.UnivariateSpline [2] https://en.wikipedia.org/wiki/Spline_interpolation#Example [3] https://github.com/scipy/scipy/blob/master/scipy/interpolate/fitpack/splev.f#L97-L113 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Tue Oct 24 05:35:33 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 24 Oct 2017 22:35:33 +1300 Subject: [SciPy-Dev] establishing a Code of Conduct for SciPy In-Reply-To: References: <1505052397.2303.14.camel@iki.fi> <1505164117.2582.92.camel@iki.fi> <1505174937.3638904.1102815104.5E1A155A@webmail.messagingengine.com> <3AA0546E-C9E6-49E9-83D2-A48298E84753@gmail.com> Message-ID: On Fri, Oct 20, 2017 at 6:47 PM, Ralf Gommers wrote: > > > On Thu, Oct 19, 2017 at 4:00 PM, Matthew Brett > wrote: > >> Hi, >> >> I tried to distill the results of the discussion into a PR to Ralf's PR: >> >> https://github.com/rgommers/scipy/pull/14 > > > Great, thanks Matthew. > > That PR is related to the longest discussion we had. Here I'll also > briefly summarize the other things we discussed: > > 1. A question on the CoC PR on whether we need a separate CoC committee or > can make do with either a single person or letting the SciPy steering > committee handle the job. The outcome was that we do want a CoC committee, > ideally 3-5 people in size. > > 2. The discussion about different cases that Matthew's PR responds to. > Discussion started from this comment: https://github.com/scipy/ > scipy/pull/7963#discussion_r145582715, and a couple of previous emails on > this mailing list also were related to that comment. > > 3. Timeline for merging the CoC. I will incorporate Matthew's PR and > address other open comments tonight. Then I'll be offline until Monday > evening. Hopefully by then the remaining points for discussion have been > converged. I'd like to merge the CoC on Tuesday and release 1.0 on > Wednesday. > The CoC is now merged. Thanks everyone for the constructive discussion! Cheers, Ralf > Cheers, > Ralf > > > >> >> Nathaniel - I probably didn't convey this well over the broken line we >> were on, but I do fully accept that we have to be careful about subtle >> discrimination, against women in particular, and I have added that as >> a specific concern in the PR, but please feel free to insist if I >> haven't captured what you meant. >> >> Cheers, >> >> Matthew >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Oct 25 06:14:07 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 25 Oct 2017 23:14:07 +1300 Subject: [SciPy-Dev] SciPy 1.0 released! Message-ID: Hi all, We are extremely pleased to announce the release of SciPy 1.0, 16 years after version 0.1 saw the light of day. It has been a long, productive journey to get here, and we anticipate many more exciting new features and releases in the future. Why 1.0 now? ------------ A version number should reflect the maturity of a project - and SciPy was a mature and stable library that is heavily used in production settings for a long time already. From that perspective, the 1.0 version number is long overdue. Some key project goals, both technical (e.g. Windows wheels and continuous integration) and organisational (a governance structure, code of conduct and a roadmap), have been achieved recently. Many of us are a bit perfectionist, and therefore are reluctant to call something "1.0" because it may imply that it's "finished" or "we are 100% happy with it". This is normal for many open source projects, however that doesn't make it right. We acknowledge to ourselves that it's not perfect, and there are some dusty corners left (that will probably always be the case). Despite that, SciPy is extremely useful to its users, on average has high quality code and documentation, and gives the stability and backwards compatibility guarantees that a 1.0 label imply. Some history and perspectives ----------------------------- - 2001: the first SciPy release - 2005: transition to NumPy - 2007: creation of scikits - 2008: scipy.spatial module and first Cython code added - 2010: moving to a 6-monthly release cycle - 2011: SciPy development moves to GitHub - 2011: Python 3 support - 2012: adding a sparse graph module and unified optimization interface - 2012: removal of scipy.maxentropy - 2013: continuous integration with TravisCI - 2015: adding Cython interface for BLAS/LAPACK and a benchmark suite - 2017: adding a unified C API with scipy.LowLevelCallable; removal of scipy.weave - 2017: SciPy 1.0 release **Pauli Virtanen** is SciPy's Benevolent Dictator For Life (BDFL). He says: *Truthfully speaking, we could have released a SciPy 1.0 a long time ago, so I'm happy we do it now at long last. The project has a long history, and during the years it has matured also as a software project. I believe it has well proved its merit to warrant a version number starting with unity.* *Since its conception 15+ years ago, SciPy has largely been written by and for scientists, to provide a box of basic tools that they need. Over time, the set of people active in its development has undergone some rotation, and we have evolved towards a somewhat more systematic approach to development. Regardless, this underlying drive has stayed the same, and I think it will also continue propelling the project forward in future. This is all good, since not long after 1.0 comes 1.1.* **Travis Oliphant** is one of SciPy's creators. He says: *I'm honored to write a note of congratulations to the SciPy developers and the entire SciPy community for the release of SciPy 1.0. This release represents a dream of many that has been patiently pursued by a stalwart group of pioneers for nearly 2 decades. Efforts have been broad and consistent over that time from many hundreds of people. From initial discussions to efforts coding and packaging to documentation efforts to extensive conference and community building, the SciPy effort has been a global phenomenon that it has been a privilege to participate in.* *The idea of SciPy was already in multiple people?s minds in 1997 when I first joined the Python community as a young graduate student who had just fallen in love with the expressibility and extensibility of Python. The internet was just starting to bringing together like-minded mathematicians and scientists in nascent electronically-connected communities. In 1998, there was a concerted discussion on the matrix-SIG, python mailing list with people like Paul Barrett, Joe Harrington, Perry Greenfield, Paul Dubois, Konrad Hinsen, David Ascher, and others. This discussion encouraged me in 1998 and 1999 to procrastinate my PhD and spend a lot of time writing extension modules to Python that mostly wrapped battle-tested Fortran and C-code making it available to the Python user. This work attracted the help of others like Robert Kern, Pearu Peterson and Eric Jones who joined their efforts with mine in 2000 so that by 2001, the first SciPy release was ready. This was long before Github simplified collaboration and input from others and the "patch" command and email was how you helped a project improve.* *Since that time, hundreds of people have spent an enormous amount of time improving the SciPy library and the community surrounding this library has dramatically grown. I stopped being able to participate actively in developing the SciPy library around 2010. Fortunately, at that time, Pauli Virtanen and Ralf Gommers picked up the pace of development supported by dozens of other key contributors such as David Cournapeau, Evgeni Burovski, Josef Perktold, and Warren Weckesser. While I have only been able to admire the development of SciPy from a distance for the past 7 years, I have never lost my love of the project and the concept of community-driven development. I remain driven even now by a desire to help sustain the development of not only the SciPy library but many other affiliated and related open-source projects. I am extremely pleased that SciPy is in the hands of a world-wide community of talented developers who will ensure that SciPy remains an example of how grass-roots, community-driven development can succeed.* **Fernando Perez** offers a wider community perspective: *The existence of a nascent Scipy library, and the incredible --if tiny by today's standards-- community surrounding it is what drew me into the scientific Python world while still a physics graduate student in 2001. Today, I am awed when I see these tools power everything from high school education to the research that led to the 2017 Nobel Prize in physics.* *Don't be fooled by the 1.0 number: this project is a mature cornerstone of the modern scientific computing ecosystem. I am grateful for the many who have made it possible, and hope to be able to contribute again to it in the future. My sincere congratulations to the whole team!* Highlights of this release -------------------------- Some of the highlights of this release are: - Major build improvements. Windows wheels are available on PyPI for the first time, and continuous integration has been set up on Windows and OS X in addition to Linux. - A set of new ODE solvers and a unified interface to them (`scipy.integrate.solve_ivp`). - Two new trust region optimizers and a new linear programming method, with improved performance compared to what `scipy.optimize` offered previously. - Many new BLAS and LAPACK functions were wrapped. The BLAS wrappers are now complete. Upgrading and compatibility --------------------------- There have been a number of deprecations and API changes in this release, which are documented below. Before upgrading, we recommend that users check that their own code does not use deprecated SciPy functionality (to do so, run your code with ``python -Wd`` and check for ``DeprecationWarning`` s). This release requires Python 2.7 or >=3.4 and NumPy 1.8.2 or greater. This is also the last release to support LAPACK 3.1.x - 3.3.x. Moving the lowest supported LAPACK version to >3.2.x was long blocked by Apple Accelerate providing the LAPACK 3.2.1 API. We have decided that it's time to either drop Accelerate or, if there is enough interest, provide shims for functions added in more recent LAPACK versions so it can still be used. New features ============ `scipy.cluster` improvements ---------------------------- `scipy.cluster.hierarchy.optimal_leaf_ordering`, a function to reorder a linkage matrix to minimize distances between adjacent leaves, was added. `scipy.fftpack` improvements ---------------------------- N-dimensional versions of the discrete sine and cosine transforms and their inverses were added as ``dctn``, ``idctn``, ``dstn`` and ``idstn``. `scipy.integrate` improvements ------------------------------ A set of new ODE solvers have been added to `scipy.integrate`. The convenience function `scipy.integrate.solve_ivp` allows uniform access to all solvers. The individual solvers (``RK23``, ``RK45``, ``Radau``, ``BDF`` and ``LSODA``) can also be used directly. `scipy.linalg` improvements ---------------------------- The BLAS wrappers in `scipy.linalg.blas` have been completed. Added functions are ``*gbmv``, ``*hbmv``, ``*hpmv``, ``*hpr``, ``*hpr2``, ``*spmv``, ``*spr``, ``*tbmv``, ``*tbsv``, ``*tpmv``, ``*tpsv``, ``*trsm``, ``*trsv``, ``*sbmv``, ``*spr2``, Wrappers for the LAPACK functions ``*gels``, ``*stev``, ``*sytrd``, ``*hetrd``, ``*sytf2``, ``*hetrf``, ``*sytrf``, ``*sycon``, ``*hecon``, ``*gglse``, ``*stebz``, ``*stemr``, ``*sterf``, and ``*stein`` have been added. The function `scipy.linalg.subspace_angles` has been added to compute the subspace angles between two matrices. The function `scipy.linalg.clarkson_woodruff_transform` has been added. It finds low-rank matrix approximation via the Clarkson-Woodruff Transform. The functions `scipy.linalg.eigh_tridiagonal` and `scipy.linalg.eigvalsh_tridiagonal`, which find the eigenvalues and eigenvectors of tridiagonal hermitian/symmetric matrices, were added. `scipy.ndimage` improvements ---------------------------- Support for homogeneous coordinate transforms has been added to `scipy.ndimage.affine_transform`. The ``ndimage`` C code underwent a significant refactoring, and is now a lot easier to understand and maintain. `scipy.optimize` improvements ----------------------------- The methods ``trust-region-exact`` and ``trust-krylov`` have been added to the function `scipy.optimize.minimize`. These new trust-region methods solve the subproblem with higher accuracy at the cost of more Hessian factorizations (compared to dogleg) or more matrix vector products (compared to ncg) but usually require less nonlinear iterations and are able to deal with indefinite Hessians. They seem very competitive against the other Newton methods implemented in scipy. `scipy.optimize.linprog` gained an interior point method. Its performance is superior (both in accuracy and speed) to the older simplex method. `scipy.signal` improvements --------------------------- An argument ``fs`` (sampling frequency) was added to the following functions: ``firwin``, ``firwin2``, ``firls``, and ``remez``. This makes these functions consistent with many other functions in `scipy.signal` in which the sampling frequency can be specified. `scipy.signal.freqz` has been sped up significantly for FIR filters. `scipy.sparse` improvements --------------------------- Iterating over and slicing of CSC and CSR matrices is now faster by up to ~35%. The ``tocsr`` method of COO matrices is now several times faster. The ``diagonal`` method of sparse matrices now takes a parameter, indicating which diagonal to return. `scipy.sparse.linalg` improvements ---------------------------------- A new iterative solver for large-scale nonsymmetric sparse linear systems, `scipy.sparse.linalg.gcrotmk`, was added. It implements ``GCROT(m,k)``, a flexible variant of ``GCROT``. `scipy.sparse.linalg.lsmr` now accepts an initial guess, yielding potentially faster convergence. SuperLU was updated to version 5.2.1. `scipy.spatial` improvements ---------------------------- Many distance metrics in `scipy.spatial.distance` gained support for weights. The signatures of `scipy.spatial.distance.pdist` and `scipy.spatial.distance.cdist` were changed to ``*args, **kwargs`` in order to support a wider range of metrics (e.g. string-based metrics that need extra keywords). Also, an optional ``out`` parameter was added to ``pdist`` and ``cdist`` allowing the user to specify where the resulting distance matrix is to be stored `scipy.stats` improvements -------------------------- The methods ``cdf`` and ``logcdf`` were added to `scipy.stats.multivariate_normal`, providing the cumulative distribution function of the multivariate normal distribution. New statistical distance functions were added, namely `scipy.stats.wasserstein_distance` for the first Wasserstein distance and `scipy.stats.energy_distance` for the energy distance. Deprecated features =================== The following functions in `scipy.misc` are deprecated: ``bytescale``, ``fromimage``, ``imfilter``, ``imread``, ``imresize``, ``imrotate``, ``imsave``, ``imshow`` and ``toimage``. Most of those functions have unexpected behavior (like rescaling and type casting image data without the user asking for that). Other functions simply have better alternatives. ``scipy.interpolate.interpolate_wrapper`` and all functions in that submodule are deprecated. This was a never finished set of wrapper functions which is not relevant anymore. The ``fillvalue`` of `scipy.signal.convolve2d` will be cast directly to the dtypes of the input arrays in the future and checked that it is a scalar or an array with a single element. ``scipy.spatial.distance.matching`` is deprecated. It is an alias of `scipy.spatial.distance.hamming`, which should be used instead. Implementation of `scipy.spatial.distance.wminkowski` was based on a wrong interpretation of the metric definition. In scipy 1.0 it has been just deprecated in the documentation to keep retro-compatibility but is recommended to use the new version of `scipy.spatial.distance.minkowski` that implements the correct behaviour. Positional arguments of `scipy.spatial.distance.pdist` and `scipy.spatial.distance.cdist` should be replaced with their keyword version. Backwards incompatible changes ============================== The following deprecated functions have been removed from `scipy.stats`: ``betai``, ``chisqprob``, ``f_value``, ``histogram``, ``histogram2``, ``pdf_fromgamma``, ``signaltonoise``, ``square_of_sums``, ``ss`` and ``threshold``. The following deprecated functions have been removed from `scipy.stats.mstats`: ``betai``, ``f_value_wilks_lambda``, ``signaltonoise`` and ``threshold``. The deprecated ``a`` and ``reta`` keywords have been removed from `scipy.stats.shapiro`. The deprecated functions ``sparse.csgraph.cs_graph_components`` and ``sparse.linalg.symeig`` have been removed from `scipy.sparse`. The following deprecated keywords have been removed in `scipy.sparse.linalg`: ``drop_tol`` from ``splu``, and ``xtype`` from ``bicg``, ``bicgstab``, ``cg``, ``cgs``, ``gmres``, ``qmr`` and ``minres``. The deprecated functions ``expm2`` and ``expm3`` have been removed from `scipy.linalg`. The deprecated keyword ``q`` was removed from `scipy.linalg.expm`. And the deprecated submodule ``linalg.calc_lwork`` was removed. The deprecated functions ``C2K``, ``K2C``, ``F2C``, ``C2F``, ``F2K`` and ``K2F`` have been removed from `scipy.constants`. The deprecated ``ppform`` class was removed from `scipy.interpolate`. The deprecated keyword ``iprint`` was removed from `scipy.optimize.fmin_cobyla`. The default value for the ``zero_phase`` keyword of `scipy.signal.decimate` has been changed to True. The ``kmeans`` and ``kmeans2`` functions in `scipy.cluster.vq` changed the method used for random initialization, so using a fixed random seed will not necessarily produce the same results as in previous versions. `scipy.special.gammaln` does not accept complex arguments anymore. The deprecated functions ``sph_jn``, ``sph_yn``, ``sph_jnyn``, ``sph_in``, ``sph_kn``, and ``sph_inkn`` have been removed. Users should instead use the functions ``spherical_jn``, ``spherical_yn``, ``spherical_in``, and ``spherical_kn``. Be aware that the new functions have different signatures. The cross-class properties of `scipy.signal.lti` systems have been removed. The following properties/setters have been removed: Name - (accessing/setting has been removed) - (setting has been removed) * StateSpace - (``num``, ``den``, ``gain``) - (``zeros``, ``poles``) * TransferFunction (``A``, ``B``, ``C``, ``D``, ``gain``) - (``zeros``, ``poles``) * ZerosPolesGain (``A``, ``B``, ``C``, ``D``, ``num``, ``den``) - () ``signal.freqz(b, a)`` with ``b`` or ``a`` >1-D raises a ``ValueError``. This was a corner case for which it was unclear that the behavior was well-defined. The method ``var`` of `scipy.stats.dirichlet` now returns a scalar rather than an ndarray when the length of alpha is 1. Other changes ============= SciPy now has a formal governance structure. It consists of a BDFL (Pauli Virtanen) and a Steering Committee. See `the governance document < https://github.com/scipy/scipy/blob/master/doc/source/dev/governance/governance.rst >`_ for details. It is now possible to build SciPy on Windows with MSVC + gfortran! Continuous integration has been set up for this build configuration on Appveyor, building against OpenBLAS. Continuous integration for OS X has been set up on TravisCI. The SciPy test suite has been migrated from ``nose`` to ``pytest``. ``scipy/_distributor_init.py`` was added to allow redistributors of SciPy to add custom code that needs to run when importing SciPy (e.g. checks for hardware, DLL search paths, etc.). Support for PEP 518 (specifying build system requirements) was added - see ``pyproject.toml`` in the root of the SciPy repository. In order to have consistent function names, the function ``scipy.linalg.solve_lyapunov`` is renamed to `scipy.linalg.solve_continuous_lyapunov`. The old name is kept for backwards-compatibility. Authors ======= * @arcady + * @xoviat + * Anton Akhmerov * Dominic Antonacci + * Alessandro Pietro Bardelli * Ved Basu + * Michael James Bedford + * Ray Bell + * Juan M. Bello-Rivas + * Sebastian Berg * Felix Berkenkamp * Jyotirmoy Bhattacharya + * Matthew Brett * Jonathan Bright * Bruno Jim?nez + * Evgeni Burovski * Patrick Callier * Mark Campanelli + * CJ Carey * Robert Cimrman * Adam Cox + * Michael Danilov + * David Haberth?r + * Andras Deak + * Philip DeBoer * Anne-Sylvie Deutsch * Cathy Douglass + * Dominic Else + * Guo Fei + * Roman Feldbauer + * Yu Feng * Jaime Fernandez del Rio * Orestis Floros + * David Freese + * Adam Geitgey + * James Gerity + * Dezmond Goff + * Christoph Gohlke * Ralf Gommers * Dirk Gorissen + * Matt Haberland + * David Hagen + * Charles Harris * Lam Yuen Hei + * Jean Helie + * Gaute Hope + * Guillaume Horel + * Franziska Horn + * Yevhenii Hyzyla + * Vladislav Iakovlev + * Marvin Kastner + * Mher Kazandjian * Thomas Keck * Adam Kurkiewicz + * Ronan Lamy + * J.L. Lanfranchi + * Eric Larson * Denis Laxalde * Gregory R. Lee * Felix Lenders + * Evan Limanto * Julian Lukwata + * Fran?ois Magimel * Syrtis Major + * Charles Masson + * Nikolay Mayorov * Tobias Megies * Markus Meister + * Roman Mirochnik + * Jordi Montes + * Nathan Musoke + * Andrew Nelson * M.J. Nichol * Juan Nunez-Iglesias * Arno Onken + * Nick Papior + * Dima Pasechnik + * Ashwin Pathak + * Oleksandr Pavlyk + * Stefan Peterson * Ilhan Polat * Andrey Portnoy + * Ravi Kumar Prasad + * Aman Pratik * Eric Quintero * Vedant Rathore + * Tyler Reddy * Joscha Reimer * Philipp Rentzsch + * Antonio Horta Ribeiro * Ned Richards + * Kevin Rose + * Benoit Rostykus + * Matt Ruffalo + * Eli Sadoff + * Pim Schellart * Nico Schl?mer + * Klaus Sembritzki + * Nikolay Shebanov + * Jonathan Tammo Siebert * Scott Sievert * Max Silbiger + * Mandeep Singh + * Michael Stewart + * Jonathan Sutton + * Deep Tavker + * Martin Thoma * James Tocknell + * Aleksandar Trifunovic + * Paul van Mulbregt + * Jacob Vanderplas * Aditya Vijaykumar * Pauli Virtanen * James Webber * Warren Weckesser * Eric Wieser + * Josh Wilson * Zhiqing Xiao + * Evgeny Zhurko * Nikolay Zinov + * Z? Vin?cius + A total of 121 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Wed Oct 25 13:09:14 2017 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 25 Oct 2017 11:09:14 -0600 Subject: [SciPy-Dev] [Numpy-discussion] SciPy 1.0 released! In-Reply-To: References: Message-ID: On Wed, Oct 25, 2017 at 4:14 AM, Ralf Gommers wrote: > Hi all, > > We are extremely pleased to announce the release of SciPy 1.0, 16 years > after > version 0.1 saw the light of day. It has been a long, productive journey > to > get here, and we anticipate many more exciting new features and releases > in the > future. > > > Why 1.0 now? > ------------ > > A version number should reflect the maturity of a project - and SciPy was a > mature and stable library that is heavily used in production settings for a > long time already. From that perspective, the 1.0 version number is long > overdue. > > Some key project goals, both technical (e.g. Windows wheels and continuous > integration) and organisational (a governance structure, code of conduct > and a > roadmap), have been achieved recently. > > Many of us are a bit perfectionist, and therefore are reluctant to call > something "1.0" because it may imply that it's "finished" or "we are 100% > happy > with it". This is normal for many open source projects, however that > doesn't > make it right. We acknowledge to ourselves that it's not perfect, and > there > are some dusty corners left (that will probably always be the case). > Despite > that, SciPy is extremely useful to its users, on average has high quality > code > and documentation, and gives the stability and backwards compatibility > guarantees that a 1.0 label imply. > > > Some history and perspectives > ----------------------------- > > - 2001: the first SciPy release > - 2005: transition to NumPy > - 2007: creation of scikits > - 2008: scipy.spatial module and first Cython code added > - 2010: moving to a 6-monthly release cycle > - 2011: SciPy development moves to GitHub > - 2011: Python 3 support > - 2012: adding a sparse graph module and unified optimization interface > - 2012: removal of scipy.maxentropy > - 2013: continuous integration with TravisCI > - 2015: adding Cython interface for BLAS/LAPACK and a benchmark suite > - 2017: adding a unified C API with scipy.LowLevelCallable; removal of > scipy.weave > - 2017: SciPy 1.0 release > > > **Pauli Virtanen** is SciPy's Benevolent Dictator For Life (BDFL). He > says: > > *Truthfully speaking, we could have released a SciPy 1.0 a long time ago, > so I'm > happy we do it now at long last. The project has a long history, and > during the > years it has matured also as a software project. I believe it has well > proved > its merit to warrant a version number starting with unity.* > > *Since its conception 15+ years ago, SciPy has largely been written by and > for > scientists, to provide a box of basic tools that they need. Over time, the > set > of people active in its development has undergone some rotation, and we > have > evolved towards a somewhat more systematic approach to development. > Regardless, > this underlying drive has stayed the same, and I think it will also > continue > propelling the project forward in future. This is all good, since not long > after 1.0 comes 1.1.* > > **Travis Oliphant** is one of SciPy's creators. He says: > > *I'm honored to write a note of congratulations to the SciPy developers > and the > entire SciPy community for the release of SciPy 1.0. This release > represents > a dream of many that has been patiently pursued by a stalwart group of > pioneers > for nearly 2 decades. Efforts have been broad and consistent over that > time > from many hundreds of people. From initial discussions to efforts coding > and > packaging to documentation efforts to extensive conference and community > building, the SciPy effort has been a global phenomenon that it has been a > privilege to participate in.* > > *The idea of SciPy was already in multiple people?s minds in 1997 when I > first > joined the Python community as a young graduate student who had just > fallen in > love with the expressibility and extensibility of Python. The internet > was > just starting to bringing together like-minded mathematicians and > scientists in > nascent electronically-connected communities. In 1998, there was a > concerted > discussion on the matrix-SIG, python mailing list with people like Paul > Barrett, Joe Harrington, Perry Greenfield, Paul Dubois, Konrad Hinsen, > David > Ascher, and others. This discussion encouraged me in 1998 and 1999 to > procrastinate my PhD and spend a lot of time writing extension modules to > Python that mostly wrapped battle-tested Fortran and C-code making it > available > to the Python user. This work attracted the help of others like Robert > Kern, > Pearu Peterson and Eric Jones who joined their efforts with mine in 2000 so > that by 2001, the first SciPy release was ready. This was long before > Github > simplified collaboration and input from others and the "patch" command and > email was how you helped a project improve.* > > *Since that time, hundreds of people have spent an enormous amount of time > improving the SciPy library and the community surrounding this library has > dramatically grown. I stopped being able to participate actively in > developing > the SciPy library around 2010. Fortunately, at that time, Pauli Virtanen > and > Ralf Gommers picked up the pace of development supported by dozens of > other key > contributors such as David Cournapeau, Evgeni Burovski, Josef Perktold, and > Warren Weckesser. While I have only been able to admire the development > of > SciPy from a distance for the past 7 years, I have never lost my love of > the > project and the concept of community-driven development. I remain driven > even now by a desire to help sustain the development of not only the SciPy > library but many other affiliated and related open-source projects. I am > extremely pleased that SciPy is in the hands of a world-wide community of > talented developers who will ensure that SciPy remains an example of how > grass-roots, community-driven development can succeed.* > > **Fernando Perez** offers a wider community perspective: > > *The existence of a nascent Scipy library, and the incredible --if tiny by > today's standards-- community surrounding it is what drew me into the > scientific Python world while still a physics graduate student in 2001. > Today, > I am awed when I see these tools power everything from high school > education to > the research that led to the 2017 Nobel Prize in physics.* > > *Don't be fooled by the 1.0 number: this project is a mature cornerstone > of the > modern scientific computing ecosystem. I am grateful for the many who have > made it possible, and hope to be able to contribute again to it in the > future. > My sincere congratulations to the whole team!* > > > Highlights of this release > -------------------------- > > Some of the highlights of this release are: > > - Major build improvements. Windows wheels are available on PyPI for the > first time, and continuous integration has been set up on Windows and OS > X > in addition to Linux. > - A set of new ODE solvers and a unified interface to them > (`scipy.integrate.solve_ivp`). > - Two new trust region optimizers and a new linear programming method, with > improved performance compared to what `scipy.optimize` offered > previously. > - Many new BLAS and LAPACK functions were wrapped. The BLAS wrappers are > now > complete. > > > Upgrading and compatibility > --------------------------- > > There have been a number of deprecations and API changes in this release, > which > are documented below. Before upgrading, we recommend that users check that > their own code does not use deprecated SciPy functionality (to do so, run > your > code with ``python -Wd`` and check for ``DeprecationWarning`` s). > > This release requires Python 2.7 or >=3.4 and NumPy 1.8.2 or greater. > > This is also the last release to support LAPACK 3.1.x - 3.3.x. Moving the > lowest supported LAPACK version to >3.2.x was long blocked by Apple > Accelerate > providing the LAPACK 3.2.1 API. We have decided that it's time to either > drop > Accelerate or, if there is enough interest, provide shims for functions > added > in more recent LAPACK versions so it can still be used. > > > New features > ============ > > `scipy.cluster` improvements > ---------------------------- > > `scipy.cluster.hierarchy.optimal_leaf_ordering`, a function to reorder a > linkage matrix to minimize distances between adjacent leaves, was added. > > > `scipy.fftpack` improvements > ---------------------------- > > N-dimensional versions of the discrete sine and cosine transforms and their > inverses were added as ``dctn``, ``idctn``, ``dstn`` and ``idstn``. > > > `scipy.integrate` improvements > ------------------------------ > > A set of new ODE solvers have been added to `scipy.integrate`. The > convenience > function `scipy.integrate.solve_ivp` allows uniform access to all solvers. > The individual solvers (``RK23``, ``RK45``, ``Radau``, ``BDF`` and > ``LSODA``) > can also be used directly. > > > `scipy.linalg` improvements > ---------------------------- > > The BLAS wrappers in `scipy.linalg.blas` have been completed. Added > functions > are ``*gbmv``, ``*hbmv``, ``*hpmv``, ``*hpr``, ``*hpr2``, ``*spmv``, > ``*spr``, > ``*tbmv``, ``*tbsv``, ``*tpmv``, ``*tpsv``, ``*trsm``, ``*trsv``, > ``*sbmv``, > ``*spr2``, > > Wrappers for the LAPACK functions ``*gels``, ``*stev``, ``*sytrd``, > ``*hetrd``, > ``*sytf2``, ``*hetrf``, ``*sytrf``, ``*sycon``, ``*hecon``, ``*gglse``, > ``*stebz``, ``*stemr``, ``*sterf``, and ``*stein`` have been added. > > The function `scipy.linalg.subspace_angles` has been added to compute the > subspace angles between two matrices. > > The function `scipy.linalg.clarkson_woodruff_transform` has been added. > It finds low-rank matrix approximation via the Clarkson-Woodruff Transform. > > The functions `scipy.linalg.eigh_tridiagonal` and > `scipy.linalg.eigvalsh_tridiagonal`, which find the eigenvalues and > eigenvectors of tridiagonal hermitian/symmetric matrices, were added. > > > `scipy.ndimage` improvements > ---------------------------- > > Support for homogeneous coordinate transforms has been added to > `scipy.ndimage.affine_transform`. > > The ``ndimage`` C code underwent a significant refactoring, and is now > a lot easier to understand and maintain. > > > `scipy.optimize` improvements > ----------------------------- > > The methods ``trust-region-exact`` and ``trust-krylov`` have been added to > the > function `scipy.optimize.minimize`. These new trust-region methods solve > the > subproblem with higher accuracy at the cost of more Hessian factorizations > (compared to dogleg) or more matrix vector products (compared to ncg) but > usually require less nonlinear iterations and are able to deal with > indefinite > Hessians. They seem very competitive against the other Newton methods > implemented in scipy. > > `scipy.optimize.linprog` gained an interior point method. Its performance > is > superior (both in accuracy and speed) to the older simplex method. > > > `scipy.signal` improvements > --------------------------- > > An argument ``fs`` (sampling frequency) was added to the following > functions: > ``firwin``, ``firwin2``, ``firls``, and ``remez``. This makes these > functions > consistent with many other functions in `scipy.signal` in which the > sampling > frequency can be specified. > > `scipy.signal.freqz` has been sped up significantly for FIR filters. > > > `scipy.sparse` improvements > --------------------------- > > Iterating over and slicing of CSC and CSR matrices is now faster by up to > ~35%. > > The ``tocsr`` method of COO matrices is now several times faster. > > The ``diagonal`` method of sparse matrices now takes a parameter, > indicating > which diagonal to return. > > > `scipy.sparse.linalg` improvements > ---------------------------------- > > A new iterative solver for large-scale nonsymmetric sparse linear systems, > `scipy.sparse.linalg.gcrotmk`, was added. It implements ``GCROT(m,k)``, a > flexible variant of ``GCROT``. > > `scipy.sparse.linalg.lsmr` now accepts an initial guess, yielding > potentially > faster convergence. > > SuperLU was updated to version 5.2.1. > > > `scipy.spatial` improvements > ---------------------------- > > Many distance metrics in `scipy.spatial.distance` gained support for > weights. > > The signatures of `scipy.spatial.distance.pdist` and > `scipy.spatial.distance.cdist` were changed to ``*args, **kwargs`` in > order to > support a wider range of metrics (e.g. string-based metrics that need extra > keywords). Also, an optional ``out`` parameter was added to ``pdist`` and > ``cdist`` allowing the user to specify where the resulting distance matrix > is > to be stored > > > `scipy.stats` improvements > -------------------------- > > The methods ``cdf`` and ``logcdf`` were added to > `scipy.stats.multivariate_normal`, providing the cumulative distribution > function of the multivariate normal distribution. > > New statistical distance functions were added, namely > `scipy.stats.wasserstein_distance` for the first Wasserstein distance and > `scipy.stats.energy_distance` for the energy distance. > > > Deprecated features > =================== > > The following functions in `scipy.misc` are deprecated: ``bytescale``, > ``fromimage``, ``imfilter``, ``imread``, ``imresize``, ``imrotate``, > ``imsave``, ``imshow`` and ``toimage``. Most of those functions have > unexpected > behavior (like rescaling and type casting image data without the user > asking > for that). Other functions simply have better alternatives. > > ``scipy.interpolate.interpolate_wrapper`` and all functions in that > submodule > are deprecated. This was a never finished set of wrapper functions which > is > not relevant anymore. > > The ``fillvalue`` of `scipy.signal.convolve2d` will be cast directly to the > dtypes of the input arrays in the future and checked that it is a scalar or > an array with a single element. > > ``scipy.spatial.distance.matching`` is deprecated. It is an alias of > `scipy.spatial.distance.hamming`, which should be used instead. > > Implementation of `scipy.spatial.distance.wminkowski` was based on a wrong > interpretation of the metric definition. In scipy 1.0 it has been just > deprecated in the documentation to keep retro-compatibility but is > recommended > to use the new version of `scipy.spatial.distance.minkowski` that > implements > the correct behaviour. > > Positional arguments of `scipy.spatial.distance.pdist` and > `scipy.spatial.distance.cdist` should be replaced with their keyword > version. > > > Backwards incompatible changes > ============================== > > The following deprecated functions have been removed from `scipy.stats`: > ``betai``, ``chisqprob``, ``f_value``, ``histogram``, ``histogram2``, > ``pdf_fromgamma``, ``signaltonoise``, ``square_of_sums``, ``ss`` and > ``threshold``. > > The following deprecated functions have been removed from > `scipy.stats.mstats`: > ``betai``, ``f_value_wilks_lambda``, ``signaltonoise`` and ``threshold``. > > The deprecated ``a`` and ``reta`` keywords have been removed from > `scipy.stats.shapiro`. > > The deprecated functions ``sparse.csgraph.cs_graph_components`` and > ``sparse.linalg.symeig`` have been removed from `scipy.sparse`. > > The following deprecated keywords have been removed in > `scipy.sparse.linalg`: > ``drop_tol`` from ``splu``, and ``xtype`` from ``bicg``, ``bicgstab``, > ``cg``, > ``cgs``, ``gmres``, ``qmr`` and ``minres``. > > The deprecated functions ``expm2`` and ``expm3`` have been removed from > `scipy.linalg`. The deprecated keyword ``q`` was removed from > `scipy.linalg.expm`. And the deprecated submodule ``linalg.calc_lwork`` > was > removed. > > The deprecated functions ``C2K``, ``K2C``, ``F2C``, ``C2F``, ``F2K`` and > ``K2F`` have been removed from `scipy.constants`. > > The deprecated ``ppform`` class was removed from `scipy.interpolate`. > > The deprecated keyword ``iprint`` was removed from > `scipy.optimize.fmin_cobyla`. > > The default value for the ``zero_phase`` keyword of `scipy.signal.decimate` > has been changed to True. > > The ``kmeans`` and ``kmeans2`` functions in `scipy.cluster.vq` changed the > method used for random initialization, so using a fixed random seed will > not necessarily produce the same results as in previous versions. > > `scipy.special.gammaln` does not accept complex arguments anymore. > > The deprecated functions ``sph_jn``, ``sph_yn``, ``sph_jnyn``, ``sph_in``, > ``sph_kn``, and ``sph_inkn`` have been removed. Users should instead use > the functions ``spherical_jn``, ``spherical_yn``, ``spherical_in``, and > ``spherical_kn``. Be aware that the new functions have different > signatures. > > The cross-class properties of `scipy.signal.lti` systems have been removed. > The following properties/setters have been removed: > > Name - (accessing/setting has been removed) - (setting has been removed) > > * StateSpace - (``num``, ``den``, ``gain``) - (``zeros``, ``poles``) > * TransferFunction (``A``, ``B``, ``C``, ``D``, ``gain``) - (``zeros``, > ``poles``) > * ZerosPolesGain (``A``, ``B``, ``C``, ``D``, ``num``, ``den``) - () > > ``signal.freqz(b, a)`` with ``b`` or ``a`` >1-D raises a ``ValueError``. > This > was a corner case for which it was unclear that the behavior was > well-defined. > > The method ``var`` of `scipy.stats.dirichlet` now returns a scalar rather > than > an ndarray when the length of alpha is 1. > > > Other changes > ============= > > SciPy now has a formal governance structure. It consists of a BDFL (Pauli > Virtanen) and a Steering Committee. See `the governance document > dev/governance/governance.rst>`_ > for details. > > It is now possible to build SciPy on Windows with MSVC + gfortran! > Continuous > integration has been set up for this build configuration on Appveyor, > building > against OpenBLAS. > > Continuous integration for OS X has been set up on TravisCI. > > The SciPy test suite has been migrated from ``nose`` to ``pytest``. > > ``scipy/_distributor_init.py`` was added to allow redistributors of SciPy > to > add custom code that needs to run when importing SciPy (e.g. checks for > hardware, DLL search paths, etc.). > > Support for PEP 518 (specifying build system requirements) was added - see > ``pyproject.toml`` in the root of the SciPy repository. > > In order to have consistent function names, the function > ``scipy.linalg.solve_lyapunov`` is renamed to > `scipy.linalg.solve_continuous_lyapunov`. The old name is kept for > backwards-compatibility. > > > Authors > ======= > > * @arcady + > * @xoviat + > * Anton Akhmerov > * Dominic Antonacci + > * Alessandro Pietro Bardelli > * Ved Basu + > * Michael James Bedford + > * Ray Bell + > * Juan M. Bello-Rivas + > * Sebastian Berg > * Felix Berkenkamp > * Jyotirmoy Bhattacharya + > * Matthew Brett > * Jonathan Bright > * Bruno Jim?nez + > * Evgeni Burovski > * Patrick Callier > * Mark Campanelli + > * CJ Carey > * Robert Cimrman > * Adam Cox + > * Michael Danilov + > * David Haberth?r + > * Andras Deak + > * Philip DeBoer > * Anne-Sylvie Deutsch > * Cathy Douglass + > * Dominic Else + > * Guo Fei + > * Roman Feldbauer + > * Yu Feng > * Jaime Fernandez del Rio > * Orestis Floros + > * David Freese + > * Adam Geitgey + > * James Gerity + > * Dezmond Goff + > * Christoph Gohlke > * Ralf Gommers > * Dirk Gorissen + > * Matt Haberland + > * David Hagen + > * Charles Harris > * Lam Yuen Hei + > * Jean Helie + > * Gaute Hope + > * Guillaume Horel + > * Franziska Horn + > * Yevhenii Hyzyla + > * Vladislav Iakovlev + > * Marvin Kastner + > * Mher Kazandjian > * Thomas Keck > * Adam Kurkiewicz + > * Ronan Lamy + > * J.L. Lanfranchi + > * Eric Larson > * Denis Laxalde > * Gregory R. Lee > * Felix Lenders + > * Evan Limanto > * Julian Lukwata + > * Fran?ois Magimel > * Syrtis Major + > * Charles Masson + > * Nikolay Mayorov > * Tobias Megies > * Markus Meister + > * Roman Mirochnik + > * Jordi Montes + > * Nathan Musoke + > * Andrew Nelson > * M.J. Nichol > * Juan Nunez-Iglesias > * Arno Onken + > * Nick Papior + > * Dima Pasechnik + > * Ashwin Pathak + > * Oleksandr Pavlyk + > * Stefan Peterson > * Ilhan Polat > * Andrey Portnoy + > * Ravi Kumar Prasad + > * Aman Pratik > * Eric Quintero > * Vedant Rathore + > * Tyler Reddy > * Joscha Reimer > * Philipp Rentzsch + > * Antonio Horta Ribeiro > * Ned Richards + > * Kevin Rose + > * Benoit Rostykus + > * Matt Ruffalo + > * Eli Sadoff + > * Pim Schellart > * Nico Schl?mer + > * Klaus Sembritzki + > * Nikolay Shebanov + > * Jonathan Tammo Siebert > * Scott Sievert > * Max Silbiger + > * Mandeep Singh + > * Michael Stewart + > * Jonathan Sutton + > * Deep Tavker + > * Martin Thoma > * James Tocknell + > * Aleksandar Trifunovic + > * Paul van Mulbregt + > * Jacob Vanderplas > * Aditya Vijaykumar > * Pauli Virtanen > * James Webber > * Warren Weckesser > * Eric Wieser + > * Josh Wilson > * Zhiqing Xiao + > * Evgeny Zhurko > * Nikolay Zinov + > * Z? Vin?cius + > > A total of 121 people contributed to this release. > People with a "+" by their names contributed a patch for the first time. > This list of names is automatically generated, and may not be fully > complete. > > > Cheers, > Ralf > > Congratulations to all. SciPy provides wonderful tools that are free for all to use. That those tools are available, and easily installed, is a great boon to many who would otherwise be at a disadvantage for lack of money or access; that, in itself, will have a major impact. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From dillon.niederhut at gmail.com Wed Oct 25 13:32:17 2017 From: dillon.niederhut at gmail.com (Dillon Niederhut) Date: Wed, 25 Oct 2017 17:32:17 +0000 Subject: [SciPy-Dev] [Numpy-discussion] SciPy 1.0 released! In-Reply-To: References: Message-ID: Woohoo! On Wed, Oct 25, 2017, 12:10 Charles R Harris wrote: > On Wed, Oct 25, 2017 at 4:14 AM, Ralf Gommers > wrote: > >> Hi all, >> >> We are extremely pleased to announce the release of SciPy 1.0, 16 years >> after >> version 0.1 saw the light of day. It has been a long, productive journey >> to >> get here, and we anticipate many more exciting new features and releases >> in the >> future. >> >> >> Why 1.0 now? >> ------------ >> >> A version number should reflect the maturity of a project - and SciPy was >> a >> mature and stable library that is heavily used in production settings for >> a >> long time already. From that perspective, the 1.0 version number is long >> overdue. >> >> Some key project goals, both technical (e.g. Windows wheels and continuous >> integration) and organisational (a governance structure, code of conduct >> and a >> roadmap), have been achieved recently. >> >> Many of us are a bit perfectionist, and therefore are reluctant to call >> something "1.0" because it may imply that it's "finished" or "we are 100% >> happy >> with it". This is normal for many open source projects, however that >> doesn't >> make it right. We acknowledge to ourselves that it's not perfect, and >> there >> are some dusty corners left (that will probably always be the case). >> Despite >> that, SciPy is extremely useful to its users, on average has high quality >> code >> and documentation, and gives the stability and backwards compatibility >> guarantees that a 1.0 label imply. >> >> >> Some history and perspectives >> ----------------------------- >> >> - 2001: the first SciPy release >> - 2005: transition to NumPy >> - 2007: creation of scikits >> - 2008: scipy.spatial module and first Cython code added >> - 2010: moving to a 6-monthly release cycle >> - 2011: SciPy development moves to GitHub >> - 2011: Python 3 support >> - 2012: adding a sparse graph module and unified optimization interface >> - 2012: removal of scipy.maxentropy >> - 2013: continuous integration with TravisCI >> - 2015: adding Cython interface for BLAS/LAPACK and a benchmark suite >> - 2017: adding a unified C API with scipy.LowLevelCallable; removal of >> scipy.weave >> - 2017: SciPy 1.0 release >> >> >> **Pauli Virtanen** is SciPy's Benevolent Dictator For Life (BDFL). He >> says: >> >> *Truthfully speaking, we could have released a SciPy 1.0 a long time ago, >> so I'm >> happy we do it now at long last. The project has a long history, and >> during the >> years it has matured also as a software project. I believe it has well >> proved >> its merit to warrant a version number starting with unity.* >> >> *Since its conception 15+ years ago, SciPy has largely been written by >> and for >> scientists, to provide a box of basic tools that they need. Over time, >> the set >> of people active in its development has undergone some rotation, and we >> have >> evolved towards a somewhat more systematic approach to development. >> Regardless, >> this underlying drive has stayed the same, and I think it will also >> continue >> propelling the project forward in future. This is all good, since not long >> after 1.0 comes 1.1.* >> >> **Travis Oliphant** is one of SciPy's creators. He says: >> >> *I'm honored to write a note of congratulations to the SciPy developers >> and the >> entire SciPy community for the release of SciPy 1.0. This release >> represents >> a dream of many that has been patiently pursued by a stalwart group of >> pioneers >> for nearly 2 decades. Efforts have been broad and consistent over that >> time >> from many hundreds of people. From initial discussions to efforts >> coding and >> packaging to documentation efforts to extensive conference and community >> building, the SciPy effort has been a global phenomenon that it has been a >> privilege to participate in.* >> >> *The idea of SciPy was already in multiple people?s minds in 1997 when I >> first >> joined the Python community as a young graduate student who had just >> fallen in >> love with the expressibility and extensibility of Python. The internet >> was >> just starting to bringing together like-minded mathematicians and >> scientists in >> nascent electronically-connected communities. In 1998, there was a >> concerted >> discussion on the matrix-SIG, python mailing list with people like Paul >> Barrett, Joe Harrington, Perry Greenfield, Paul Dubois, Konrad Hinsen, >> David >> Ascher, and others. This discussion encouraged me in 1998 and 1999 to >> procrastinate my PhD and spend a lot of time writing extension modules to >> Python that mostly wrapped battle-tested Fortran and C-code making it >> available >> to the Python user. This work attracted the help of others like Robert >> Kern, >> Pearu Peterson and Eric Jones who joined their efforts with mine in 2000 >> so >> that by 2001, the first SciPy release was ready. This was long before >> Github >> simplified collaboration and input from others and the "patch" command and >> email was how you helped a project improve.* >> >> *Since that time, hundreds of people have spent an enormous amount of time >> improving the SciPy library and the community surrounding this library has >> dramatically grown. I stopped being able to participate actively in >> developing >> the SciPy library around 2010. Fortunately, at that time, Pauli Virtanen >> and >> Ralf Gommers picked up the pace of development supported by dozens of >> other key >> contributors such as David Cournapeau, Evgeni Burovski, Josef Perktold, >> and >> Warren Weckesser. While I have only been able to admire the development >> of >> SciPy from a distance for the past 7 years, I have never lost my love of >> the >> project and the concept of community-driven development. I remain >> driven >> even now by a desire to help sustain the development of not only the SciPy >> library but many other affiliated and related open-source projects. I am >> extremely pleased that SciPy is in the hands of a world-wide community of >> talented developers who will ensure that SciPy remains an example of how >> grass-roots, community-driven development can succeed.* >> >> **Fernando Perez** offers a wider community perspective: >> >> *The existence of a nascent Scipy library, and the incredible --if tiny by >> today's standards-- community surrounding it is what drew me into the >> scientific Python world while still a physics graduate student in 2001. >> Today, >> I am awed when I see these tools power everything from high school >> education to >> the research that led to the 2017 Nobel Prize in physics.* >> >> *Don't be fooled by the 1.0 number: this project is a mature cornerstone >> of the >> modern scientific computing ecosystem. I am grateful for the many who >> have >> made it possible, and hope to be able to contribute again to it in the >> future. >> My sincere congratulations to the whole team!* >> >> >> Highlights of this release >> -------------------------- >> >> Some of the highlights of this release are: >> >> - Major build improvements. Windows wheels are available on PyPI for the >> first time, and continuous integration has been set up on Windows and >> OS X >> in addition to Linux. >> - A set of new ODE solvers and a unified interface to them >> (`scipy.integrate.solve_ivp`). >> - Two new trust region optimizers and a new linear programming method, >> with >> improved performance compared to what `scipy.optimize` offered >> previously. >> - Many new BLAS and LAPACK functions were wrapped. The BLAS wrappers are >> now >> complete. >> >> >> Upgrading and compatibility >> --------------------------- >> >> There have been a number of deprecations and API changes in this release, >> which >> are documented below. Before upgrading, we recommend that users check >> that >> their own code does not use deprecated SciPy functionality (to do so, run >> your >> code with ``python -Wd`` and check for ``DeprecationWarning`` s). >> >> This release requires Python 2.7 or >=3.4 and NumPy 1.8.2 or greater. >> >> This is also the last release to support LAPACK 3.1.x - 3.3.x. Moving the >> lowest supported LAPACK version to >3.2.x was long blocked by Apple >> Accelerate >> providing the LAPACK 3.2.1 API. We have decided that it's time to either >> drop >> Accelerate or, if there is enough interest, provide shims for functions >> added >> in more recent LAPACK versions so it can still be used. >> >> >> New features >> ============ >> >> `scipy.cluster` improvements >> ---------------------------- >> >> `scipy.cluster.hierarchy.optimal_leaf_ordering`, a function to reorder a >> linkage matrix to minimize distances between adjacent leaves, was added. >> >> >> `scipy.fftpack` improvements >> ---------------------------- >> >> N-dimensional versions of the discrete sine and cosine transforms and >> their >> inverses were added as ``dctn``, ``idctn``, ``dstn`` and ``idstn``. >> >> >> `scipy.integrate` improvements >> ------------------------------ >> >> A set of new ODE solvers have been added to `scipy.integrate`. The >> convenience >> function `scipy.integrate.solve_ivp` allows uniform access to all solvers. >> The individual solvers (``RK23``, ``RK45``, ``Radau``, ``BDF`` and >> ``LSODA``) >> can also be used directly. >> >> >> `scipy.linalg` improvements >> ---------------------------- >> >> The BLAS wrappers in `scipy.linalg.blas` have been completed. Added >> functions >> are ``*gbmv``, ``*hbmv``, ``*hpmv``, ``*hpr``, ``*hpr2``, ``*spmv``, >> ``*spr``, >> ``*tbmv``, ``*tbsv``, ``*tpmv``, ``*tpsv``, ``*trsm``, ``*trsv``, >> ``*sbmv``, >> ``*spr2``, >> >> Wrappers for the LAPACK functions ``*gels``, ``*stev``, ``*sytrd``, >> ``*hetrd``, >> ``*sytf2``, ``*hetrf``, ``*sytrf``, ``*sycon``, ``*hecon``, ``*gglse``, >> ``*stebz``, ``*stemr``, ``*sterf``, and ``*stein`` have been added. >> >> The function `scipy.linalg.subspace_angles` has been added to compute the >> subspace angles between two matrices. >> >> The function `scipy.linalg.clarkson_woodruff_transform` has been added. >> It finds low-rank matrix approximation via the Clarkson-Woodruff >> Transform. >> >> The functions `scipy.linalg.eigh_tridiagonal` and >> `scipy.linalg.eigvalsh_tridiagonal`, which find the eigenvalues and >> eigenvectors of tridiagonal hermitian/symmetric matrices, were added. >> >> >> `scipy.ndimage` improvements >> ---------------------------- >> >> Support for homogeneous coordinate transforms has been added to >> `scipy.ndimage.affine_transform`. >> >> The ``ndimage`` C code underwent a significant refactoring, and is now >> a lot easier to understand and maintain. >> >> >> `scipy.optimize` improvements >> ----------------------------- >> >> The methods ``trust-region-exact`` and ``trust-krylov`` have been added >> to the >> function `scipy.optimize.minimize`. These new trust-region methods solve >> the >> subproblem with higher accuracy at the cost of more Hessian factorizations >> (compared to dogleg) or more matrix vector products (compared to ncg) but >> usually require less nonlinear iterations and are able to deal with >> indefinite >> Hessians. They seem very competitive against the other Newton methods >> implemented in scipy. >> >> `scipy.optimize.linprog` gained an interior point method. Its >> performance is >> superior (both in accuracy and speed) to the older simplex method. >> >> >> `scipy.signal` improvements >> --------------------------- >> >> An argument ``fs`` (sampling frequency) was added to the following >> functions: >> ``firwin``, ``firwin2``, ``firls``, and ``remez``. This makes these >> functions >> consistent with many other functions in `scipy.signal` in which the >> sampling >> frequency can be specified. >> >> `scipy.signal.freqz` has been sped up significantly for FIR filters. >> >> >> `scipy.sparse` improvements >> --------------------------- >> >> Iterating over and slicing of CSC and CSR matrices is now faster by up to >> ~35%. >> >> The ``tocsr`` method of COO matrices is now several times faster. >> >> The ``diagonal`` method of sparse matrices now takes a parameter, >> indicating >> which diagonal to return. >> >> >> `scipy.sparse.linalg` improvements >> ---------------------------------- >> >> A new iterative solver for large-scale nonsymmetric sparse linear systems, >> `scipy.sparse.linalg.gcrotmk`, was added. It implements ``GCROT(m,k)``, a >> flexible variant of ``GCROT``. >> >> `scipy.sparse.linalg.lsmr` now accepts an initial guess, yielding >> potentially >> faster convergence. >> >> SuperLU was updated to version 5.2.1. >> >> >> `scipy.spatial` improvements >> ---------------------------- >> >> Many distance metrics in `scipy.spatial.distance` gained support for >> weights. >> >> The signatures of `scipy.spatial.distance.pdist` and >> `scipy.spatial.distance.cdist` were changed to ``*args, **kwargs`` in >> order to >> support a wider range of metrics (e.g. string-based metrics that need >> extra >> keywords). Also, an optional ``out`` parameter was added to ``pdist`` and >> ``cdist`` allowing the user to specify where the resulting distance >> matrix is >> to be stored >> >> >> `scipy.stats` improvements >> -------------------------- >> >> The methods ``cdf`` and ``logcdf`` were added to >> `scipy.stats.multivariate_normal`, providing the cumulative distribution >> function of the multivariate normal distribution. >> >> New statistical distance functions were added, namely >> `scipy.stats.wasserstein_distance` for the first Wasserstein distance and >> `scipy.stats.energy_distance` for the energy distance. >> >> >> Deprecated features >> =================== >> >> The following functions in `scipy.misc` are deprecated: ``bytescale``, >> ``fromimage``, ``imfilter``, ``imread``, ``imresize``, ``imrotate``, >> ``imsave``, ``imshow`` and ``toimage``. Most of those functions have >> unexpected >> behavior (like rescaling and type casting image data without the user >> asking >> for that). Other functions simply have better alternatives. >> >> ``scipy.interpolate.interpolate_wrapper`` and all functions in that >> submodule >> are deprecated. This was a never finished set of wrapper functions which >> is >> not relevant anymore. >> >> The ``fillvalue`` of `scipy.signal.convolve2d` will be cast directly to >> the >> dtypes of the input arrays in the future and checked that it is a scalar >> or >> an array with a single element. >> >> ``scipy.spatial.distance.matching`` is deprecated. It is an alias of >> `scipy.spatial.distance.hamming`, which should be used instead. >> >> Implementation of `scipy.spatial.distance.wminkowski` was based on a wrong >> interpretation of the metric definition. In scipy 1.0 it has been just >> deprecated in the documentation to keep retro-compatibility but is >> recommended >> to use the new version of `scipy.spatial.distance.minkowski` that >> implements >> the correct behaviour. >> >> Positional arguments of `scipy.spatial.distance.pdist` and >> `scipy.spatial.distance.cdist` should be replaced with their keyword >> version. >> >> >> Backwards incompatible changes >> ============================== >> >> The following deprecated functions have been removed from `scipy.stats`: >> ``betai``, ``chisqprob``, ``f_value``, ``histogram``, ``histogram2``, >> ``pdf_fromgamma``, ``signaltonoise``, ``square_of_sums``, ``ss`` and >> ``threshold``. >> >> The following deprecated functions have been removed from >> `scipy.stats.mstats`: >> ``betai``, ``f_value_wilks_lambda``, ``signaltonoise`` and ``threshold``. >> >> The deprecated ``a`` and ``reta`` keywords have been removed from >> `scipy.stats.shapiro`. >> >> The deprecated functions ``sparse.csgraph.cs_graph_components`` and >> ``sparse.linalg.symeig`` have been removed from `scipy.sparse`. >> >> The following deprecated keywords have been removed in >> `scipy.sparse.linalg`: >> ``drop_tol`` from ``splu``, and ``xtype`` from ``bicg``, ``bicgstab``, >> ``cg``, >> ``cgs``, ``gmres``, ``qmr`` and ``minres``. >> >> The deprecated functions ``expm2`` and ``expm3`` have been removed from >> `scipy.linalg`. The deprecated keyword ``q`` was removed from >> `scipy.linalg.expm`. And the deprecated submodule ``linalg.calc_lwork`` >> was >> removed. >> >> The deprecated functions ``C2K``, ``K2C``, ``F2C``, ``C2F``, ``F2K`` and >> ``K2F`` have been removed from `scipy.constants`. >> >> The deprecated ``ppform`` class was removed from `scipy.interpolate`. >> >> The deprecated keyword ``iprint`` was removed from >> `scipy.optimize.fmin_cobyla`. >> >> The default value for the ``zero_phase`` keyword of >> `scipy.signal.decimate` >> has been changed to True. >> >> The ``kmeans`` and ``kmeans2`` functions in `scipy.cluster.vq` changed the >> method used for random initialization, so using a fixed random seed will >> not necessarily produce the same results as in previous versions. >> >> `scipy.special.gammaln` does not accept complex arguments anymore. >> >> The deprecated functions ``sph_jn``, ``sph_yn``, ``sph_jnyn``, ``sph_in``, >> ``sph_kn``, and ``sph_inkn`` have been removed. Users should instead use >> the functions ``spherical_jn``, ``spherical_yn``, ``spherical_in``, and >> ``spherical_kn``. Be aware that the new functions have different >> signatures. >> >> The cross-class properties of `scipy.signal.lti` systems have been >> removed. >> The following properties/setters have been removed: >> >> Name - (accessing/setting has been removed) - (setting has been removed) >> >> * StateSpace - (``num``, ``den``, ``gain``) - (``zeros``, ``poles``) >> * TransferFunction (``A``, ``B``, ``C``, ``D``, ``gain``) - (``zeros``, >> ``poles``) >> * ZerosPolesGain (``A``, ``B``, ``C``, ``D``, ``num``, ``den``) - () >> >> ``signal.freqz(b, a)`` with ``b`` or ``a`` >1-D raises a ``ValueError``. >> This >> was a corner case for which it was unclear that the behavior was >> well-defined. >> >> The method ``var`` of `scipy.stats.dirichlet` now returns a scalar rather >> than >> an ndarray when the length of alpha is 1. >> >> >> Other changes >> ============= >> >> SciPy now has a formal governance structure. It consists of a BDFL (Pauli >> Virtanen) and a Steering Committee. See `the governance document >> < >> https://github.com/scipy/scipy/blob/master/doc/source/dev/governance/governance.rst >> >`_ >> for details. >> >> It is now possible to build SciPy on Windows with MSVC + gfortran! >> Continuous >> integration has been set up for this build configuration on Appveyor, >> building >> against OpenBLAS. >> >> Continuous integration for OS X has been set up on TravisCI. >> >> The SciPy test suite has been migrated from ``nose`` to ``pytest``. >> >> ``scipy/_distributor_init.py`` was added to allow redistributors of SciPy >> to >> add custom code that needs to run when importing SciPy (e.g. checks for >> hardware, DLL search paths, etc.). >> >> Support for PEP 518 (specifying build system requirements) was added - see >> ``pyproject.toml`` in the root of the SciPy repository. >> >> In order to have consistent function names, the function >> ``scipy.linalg.solve_lyapunov`` is renamed to >> `scipy.linalg.solve_continuous_lyapunov`. The old name is kept for >> backwards-compatibility. >> >> >> Authors >> ======= >> >> * @arcady + >> * @xoviat + >> * Anton Akhmerov >> * Dominic Antonacci + >> * Alessandro Pietro Bardelli >> * Ved Basu + >> * Michael James Bedford + >> * Ray Bell + >> * Juan M. Bello-Rivas + >> * Sebastian Berg >> * Felix Berkenkamp >> * Jyotirmoy Bhattacharya + >> * Matthew Brett >> * Jonathan Bright >> * Bruno Jim?nez + >> * Evgeni Burovski >> * Patrick Callier >> * Mark Campanelli + >> * CJ Carey >> * Robert Cimrman >> * Adam Cox + >> * Michael Danilov + >> * David Haberth?r + >> * Andras Deak + >> * Philip DeBoer >> * Anne-Sylvie Deutsch >> * Cathy Douglass + >> * Dominic Else + >> * Guo Fei + >> * Roman Feldbauer + >> * Yu Feng >> * Jaime Fernandez del Rio >> * Orestis Floros + >> * David Freese + >> * Adam Geitgey + >> * James Gerity + >> * Dezmond Goff + >> * Christoph Gohlke >> * Ralf Gommers >> * Dirk Gorissen + >> * Matt Haberland + >> * David Hagen + >> * Charles Harris >> * Lam Yuen Hei + >> * Jean Helie + >> * Gaute Hope + >> * Guillaume Horel + >> * Franziska Horn + >> * Yevhenii Hyzyla + >> * Vladislav Iakovlev + >> * Marvin Kastner + >> * Mher Kazandjian >> * Thomas Keck >> * Adam Kurkiewicz + >> * Ronan Lamy + >> * J.L. Lanfranchi + >> * Eric Larson >> * Denis Laxalde >> * Gregory R. Lee >> * Felix Lenders + >> * Evan Limanto >> * Julian Lukwata + >> * Fran?ois Magimel >> * Syrtis Major + >> * Charles Masson + >> * Nikolay Mayorov >> * Tobias Megies >> * Markus Meister + >> * Roman Mirochnik + >> * Jordi Montes + >> * Nathan Musoke + >> * Andrew Nelson >> * M.J. Nichol >> * Juan Nunez-Iglesias >> * Arno Onken + >> * Nick Papior + >> * Dima Pasechnik + >> * Ashwin Pathak + >> * Oleksandr Pavlyk + >> * Stefan Peterson >> * Ilhan Polat >> * Andrey Portnoy + >> * Ravi Kumar Prasad + >> * Aman Pratik >> * Eric Quintero >> * Vedant Rathore + >> * Tyler Reddy >> * Joscha Reimer >> * Philipp Rentzsch + >> * Antonio Horta Ribeiro >> * Ned Richards + >> * Kevin Rose + >> * Benoit Rostykus + >> * Matt Ruffalo + >> * Eli Sadoff + >> * Pim Schellart >> * Nico Schl?mer + >> * Klaus Sembritzki + >> * Nikolay Shebanov + >> * Jonathan Tammo Siebert >> * Scott Sievert >> * Max Silbiger + >> * Mandeep Singh + >> * Michael Stewart + >> * Jonathan Sutton + >> * Deep Tavker + >> * Martin Thoma >> * James Tocknell + >> * Aleksandar Trifunovic + >> * Paul van Mulbregt + >> * Jacob Vanderplas >> * Aditya Vijaykumar >> * Pauli Virtanen >> * James Webber >> * Warren Weckesser >> * Eric Wieser + >> * Josh Wilson >> * Zhiqing Xiao + >> * Evgeny Zhurko >> * Nikolay Zinov + >> * Z? Vin?cius + >> >> A total of 121 people contributed to this release. >> People with a "+" by their names contributed a patch for the first time. >> This list of names is automatically generated, and may not be fully >> complete. >> >> >> Cheers, >> Ralf >> >> > Congratulations to all. SciPy provides wonderful tools that are free for > all to use. That those tools are available, and easily installed, is a > great boon to many who would otherwise be at a disadvantage for lack of > money or access; that, in itself, will have a major impact. > > Chuck > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Wed Oct 25 16:18:08 2017 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 25 Oct 2017 22:18:08 +0200 Subject: [SciPy-Dev] SciPy 1.0 released! In-Reply-To: References: Message-ID: <1508962688.3720.1.camel@iki.fi> Hi, ke, 2017-10-25 kello 23:14 +1300, Ralf Gommers kirjoitti: > We are extremely pleased to announce the release of SciPy 1.0, 16 > years > after > version 0.1 saw the light of day. It has been a long, productive > journey to > get here, and we anticipate many more exciting new features and > releases in > the > future. Thanks a lot Ralf for taking care of the release! Cheers, Pauli From Former at physicist.net Thu Oct 26 21:26:18 2017 From: Former at physicist.net (Adam) Date: Thu, 26 Oct 2017 18:26:18 -0700 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: <1508548981.3961.10.camel@physicist.net> References: <1508370462.5994.94.camel@physicist.net> <1508548981.3961.10.camel@physicist.net> Message-ID: <1509067578.16218.3.camel@physicist.net> Hey guys, How do I view the html version of a functions docstring? ?I've added my Buhring reference to the docstring and I want to see how it renders in HTML. I've tried both methods described in?https://github.com/scipy/scipy/blo b/master/doc/README.txt?but neither of them worked. When I try: (scipy-dev) adam at adam-P7xxDM-G:~/scipy-dev/scipy$ python setup.py build_sphinx I get: (...blah...blah...) usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] ?or: setup.py --help [cmd1 cmd2 ...] ?or: setup.py --help-commands ?or: setup.py cmd --help error: invalid command 'build_sphinx' When I try : (scipy-dev) adam at adam-P7xxDM-G:~/scipy-dev/scipy/doc$ make html I do in fact get a bunch of html in the folders build/html, but the html for hyp2f1 doesn't contain my edits. ?I've tried building html after reinstalling my dev version of scipy, but that didn't change anything. Thanks for any help! --Adam On Fri, 2017-10-20 at 18:23 -0700, Adam wrote: > I can certainly add the formulas to the doc string if that's what > people want. ?My only concern is that the a-b=m case involves about a > page of formula's and would take a lot of space in the doc string > (I've attached the pdf from my latex file of the formulas). > Originally I was thinking that the docstring would just contain some > reference to the pdf document, e.g., "See the pdf at location X for > the method used when a-b is an integer."? > > But like I said, I can put them wherever they need to go; I justed > wanted to make sure that future maintainers have some reference as to > what the code is trying to do... > > --Adam > > On Fri, 2017-10-20 at 08:54 -0400, josef.pktd at gmail.com wrote: > > One possibility: > > Currently the only more extensive Latex based documentation is in > > the tutorial. > > I think it would be possible to add a technical appendix or > > something like that > > to the scipy.special tutorial, a bit similar to the distributions > > formulas attached to the? > > stats tutorial. > > > > For example Boost, last time I checked, had long documentation for > > the special > > functions, which might be too long to fit in docstrings. > > > > I don't know how much there would be for special functions and > > whether it is? > > difficult to maintain those notes. However, I think it would be > > good to have > > notes that developers have already written available for future > > developers and users that are interested in technical details. > > > > > > Josef > > > > > > On Fri, Oct 20, 2017 at 2:01 AM, Ralf Gommers > > om> wrote: > > > > > > > > > On Thu, Oct 19, 2017 at 8:04 PM, Ted Pudlik > > > wrote: > > > > Concerning the actual formulas: there's a compromise between > > > > leaving them implicit and creating a separate LaTeX doc.? You > > > > could add the formulas to the docstring.? The LaTeX will render > > > > in the HTML version of the documentation (example).? I'm not > > > > sure how the maintainers feel about this, though (this is just > > > > a suggestion from a "private citizen"). > > > > > > > In general: using LaTeX can be a good idea, the one thing that > > > has to be kept in mind is readability as plain text (important > > > both for reading docstrings in IPython terminal and when working > > > on the code in an editor). Best to add LaTeX formulas to the > > > Notes section rather than in the first sentences. And avoid usage > > > of things like \left[ that make the rendered html slightly > > > prettier but the actual math much harder to read as plain text. > > > > > > Here's a recent PR with discussion about various LaTeX styles: ht > > > tps://github.com/scipy/scipy/pull/7756. The style that got merged > > > is about right. > > > > > > Cheers, > > > Ralf > > > > > > > > > > > > > > > > > > > On Thu, Oct 19, 2017 at 11:59 AM Adam > > > > wrote: > > > > > Okay cool; thanks for the helpful reply! > > > > > > > > > > I'll look at Gosper's method and see how it compares with > > > > > Buhring's method. > > > > > For now I'll plan on doing a PR that implements one of these > > > > > two methods.? I > > > > > was just worried that I might end up doing a lot of work on a > > > > > PR that > > > > > implements Buhring's series only to have a reviewer reject it > > > > > saying "Well, > > > > > you should have used such-and-such's algorithm which is must > > > > > faster, much > > > > > more accurate, etc." > > > > > > > > > > I'll also hold off on adding a latex doc to the repo of the > > > > > actual formulas > > > > > used for the b-a=integer special case (unless I hear > > > > > otherwise). > > > > > > > > > > Thanks again! > > > > > > > > > > --Adam > > > > > > > > > > -----Original Message----- > > > > > From: Joshua Wilson > > > > > Sent: Thursday, October 19, 2017 9:35 AM > > > > > To: SciPy Developers List > > > > > Subject: Re: [SciPy-Dev] Fixing a bug with scipy's > > > > > hypergeometric function > > > > > hyp2f1 > > > > > > > > > > Hey Adam, > > > > > > > > > > > Does this sound like a worthwhile PR? > > > > > > > > > > Yes, definitely > > > > > > > > > > > Does the implementation sound reasonable? > > > > > > > > > > It's been a while since I've thought about this, but if I > > > > > recall > > > > > correctly the problematic region you've found is one that > > > > > comes up > > > > > quite frequently--see e.g. page 14 in > > > > > > > > > > http://fredrikj.net/math/hypgeom.pdf > > > > > > > > > > Floating around in the ether is a method credited to Bill > > > > > Gosper for > > > > > handling that region which also uses a recurrence relation > > > > > (maybe > > > > > related to/the same as in the paper you cited)? I can never > > > > > seem to > > > > > find the original reference (dead link), but I've attached > > > > > someone's > > > > > writeup of it. > > > > > > > > > > So, your implementation sounds reasonable, but if you really > > > > > want to > > > > > dig into it you could check out the Gosper stuff and see how > > > > > they > > > > > compare. > > > > > > > > > > > Can the PR implement formulas/methods that don't appear in > > > > > the literature? > > > > > > Is it going to be a problem if I implement this limit case > > > > > in the PR? > > > > > > > > > > It's implicit in the literature, so I think it's fine. > > > > > > > > > > > I don't what reference I would place hyp2f1's doc string > > > > > > > > > > The Buhring paper. The formula is something that an informed > > > > > reader > > > > > could figure out after reading it. > > > > > > > > > > > I would be wiling to maybe add a latex doc to the PR > > > > > (placed somewhere in > > > > > > the doc folder?) > > > > > > > > > > If I recall correctly people were opposed to adding LaTeX > > > > > docs. (But > > > > > maybe I recall incorrectly; if so please someone correct me.) > > > > > I also > > > > > have various special function write ups that might be handy > > > > > for future > > > > > devs... maybe in a separate repo? > > > > > > > > > > On Wed, Oct 18, 2017 at 6:47 PM, Adam > > > > > wrote: > > > > > > Hello guys, > > > > > > > > > > > > I've found a small region in the complex plane where > > > > > scipy's > > > > > > implementation > > > > > > of the hypergeometric function hyp2f1 fails. I've > > > > > documented this error in > > > > > > issue 8054 on github. > > > > > > > > > > > > I am willing to submit a PR that fixes this issue. My PR > > > > > would basically > > > > > > implement the analytic continuation formula given in this > > > > > paper: (Buhring, > > > > > > An Analytic Continuation of the Hypergeometric Series). > > > > > I've already > > > > > > implemented this series in some prototype code written in > > > > > Fortran and it > > > > > > agrees well with the values returned by mpmath's > > > > > implementation of hyp2f1. > > > > > > > > > > > > Before I attempt a PR, I just wanted to touch base and ask > > > > > the group the > > > > > > following: > > > > > > > > > > > > 1) Does this sound like a worthwhile PR? The failure region > > > > > is somewhat > > > > > > small and I don't know with what urgency people would want > > > > > this fixed. > > > > > > > > > > > > 2) Does the implementation sound reasonable? My background > > > > > is physics and > > > > > > so > > > > > > I haven't done a complete literature search looking for the > > > > > *fastest* > > > > > > algorithm. All I can say that the Buhring's formula works > > > > > and my > > > > > > implementation only seems to be about %50 slower than the > > > > > current hyp2f1 > > > > > > (at > > > > > > points in the complex plane where both methods converge). I > > > > > would only > > > > > > apply > > > > > > Buhring's series in the region where hyp2f1 currently > > > > > diverges. > > > > > > > > > > > > 3) Can the PR implement formulas/methods that don't appear > > > > > in the > > > > > > literature? Buhring's paper *only* gives the analytic > > > > > continuation for the > > > > > > case where the difference between the a/b parameters is NOT > > > > > an integer. > > > > > > When > > > > > > a-b=m, the limit case of his series can be derived using a > > > > > method > > > > > > described > > > > > > in "The Special Functions and Their Approximations" by Y. > > > > > Luke (as Buhling > > > > > > mentions in his paper). I've derived the formula for this > > > > > limit case and > > > > > > have an implementation of it that produces values in > > > > > agreement with > > > > > > mpmath. > > > > > > Is it going to be a problem if I implement this limit case > > > > > in the PR? I > > > > > > ask > > > > > > because I don't what reference I would place hyp2f1's doc > > > > > string. I would > > > > > > be > > > > > > wiling to maybe add a latex doc to the PR (placed somewhere > > > > > in the doc > > > > > > folder?) that contains the formula so that future scipy > > > > > devs have > > > > > > something > > > > > > to reference when reviewing hyp2f1's source code. > > > > > > > > > > > > Anyways, let me know if my idea for a PR sounds like a good > > > > > idea! I > > > > > > apologize for the longish email, but this is my first time > > > > > trying to > > > > > > contribute to scipy... > > > > > > > > > > > > --Adam > > > > > > > > > > > > _______________________________________________ > > > > > > SciPy-Dev mailing list > > > > > > SciPy-Dev at python.org > > > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SciPy-Dev mailing list > > > > > SciPy-Dev at python.org > > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > > > _______________________________________________ > > > > > SciPy-Dev mailing list > > > > > SciPy-Dev at python.org > > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > > _______________________________________________ > > > > SciPy-Dev mailing list > > > > SciPy-Dev at python.org > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > > > _______________________________________________ > > > SciPy-Dev mailing list > > > SciPy-Dev at python.org > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.craig.wilson at gmail.com Thu Oct 26 21:52:17 2017 From: josh.craig.wilson at gmail.com (Joshua Wilson) Date: Thu, 26 Oct 2017 20:52:17 -0500 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: <1509067578.16218.3.camel@physicist.net> References: <1508370462.5994.94.camel@physicist.net> <1508548981.3961.10.camel@physicist.net> <1509067578.16218.3.camel@physicist.net> Message-ID: > I do in fact get a bunch of html in the folders build/html, but the html for hyp2f1 doesn't contain my edits If I recall correctly, Sphinx doesn't detect changes in the `_ufuncs` extension module. Maybe try forcing a complete rebuild with `make SPHINXOPTS=-Ea html`. On Thu, Oct 26, 2017 at 8:26 PM, Adam wrote: > Hey guys, > > How do I view the html version of a functions docstring? I've added my > Buhring reference to the docstring and I want to see how it renders in HTML. > > I've tried both methods described in > https://github.com/scipy/scipy/blob/master/doc/README.txt but neither of > them worked. > > When I try: > (scipy-dev) adam at adam-P7xxDM-G:~/scipy-dev/scipy$ python setup.py > build_sphinx > I get: > (...blah...blah...) > usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] > or: setup.py --help [cmd1 cmd2 ...] > or: setup.py --help-commands > or: setup.py cmd --help > error: invalid command 'build_sphinx' > > When I try : > (scipy-dev) adam at adam-P7xxDM-G:~/scipy-dev/scipy/doc$ make html > > I do in fact get a bunch of html in the folders build/html, but the html for > hyp2f1 doesn't contain my edits. I've tried building html after > reinstalling my dev version of scipy, but that didn't change anything. > > Thanks for any help! > > --Adam > > On Fri, 2017-10-20 at 18:23 -0700, Adam wrote: > > I can certainly add the formulas to the doc string if that's what people > want. My only concern is that the a-b=m case involves about a page of > formula's and would take a lot of space in the doc string (I've attached the > pdf from my latex file of the formulas). Originally I was thinking that the > docstring would just contain some reference to the pdf document, e.g., "See > the pdf at location X for the method used when a-b is an integer." > > But like I said, I can put them wherever they need to go; I justed wanted to > make sure that future maintainers have some reference as to what the code is > trying to do... > > --Adam > > On Fri, 2017-10-20 at 08:54 -0400, josef.pktd at gmail.com wrote: > > One possibility: > Currently the only more extensive Latex based documentation is in the > tutorial. > I think it would be possible to add a technical appendix or something like > that > to the scipy.special tutorial, a bit similar to the distributions formulas > attached to the > stats tutorial. > > For example Boost, last time I checked, had long documentation for the > special > functions, which might be too long to fit in docstrings. > > I don't know how much there would be for special functions and whether it is > difficult to maintain those notes. However, I think it would be good to have > notes that developers have already written available for future > developers and users that are interested in technical details. > > > Josef > > > On Fri, Oct 20, 2017 at 2:01 AM, Ralf Gommers > wrote: > > > > On Thu, Oct 19, 2017 at 8:04 PM, Ted Pudlik wrote: > > Concerning the actual formulas: there's a compromise between leaving them > implicit and creating a separate LaTeX doc. You could add the formulas to > the docstring. The LaTeX will render in the HTML version of the > documentation (example). I'm not sure how the maintainers feel about this, > though (this is just a suggestion from a "private citizen"). > > > In general: using LaTeX can be a good idea, the one thing that has to be > kept in mind is readability as plain text (important both for reading > docstrings in IPython terminal and when working on the code in an editor). > Best to add LaTeX formulas to the Notes section rather than in the first > sentences. And avoid usage of things like \left[ that make the rendered html > slightly prettier but the actual math much harder to read as plain text. > > Here's a recent PR with discussion about various LaTeX styles: > https://github.com/scipy/scipy/pull/7756. The style that got merged is about > right. > > Cheers, > Ralf > > > > > On Thu, Oct 19, 2017 at 11:59 AM Adam wrote: > > Okay cool; thanks for the helpful reply! > > I'll look at Gosper's method and see how it compares with Buhring's method. > For now I'll plan on doing a PR that implements one of these two methods. I > was just worried that I might end up doing a lot of work on a PR that > implements Buhring's series only to have a reviewer reject it saying "Well, > you should have used such-and-such's algorithm which is must faster, much > more accurate, etc." > > I'll also hold off on adding a latex doc to the repo of the actual formulas > used for the b-a=integer special case (unless I hear otherwise). > > Thanks again! > > --Adam > > -----Original Message----- > From: Joshua Wilson > Sent: Thursday, October 19, 2017 9:35 AM > To: SciPy Developers List > Subject: Re: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function > hyp2f1 > > Hey Adam, > >> Does this sound like a worthwhile PR? > > Yes, definitely > >> Does the implementation sound reasonable? > > It's been a while since I've thought about this, but if I recall > correctly the problematic region you've found is one that comes up > quite frequently--see e.g. page 14 in > > http://fredrikj.net/math/hypgeom.pdf > > Floating around in the ether is a method credited to Bill Gosper for > handling that region which also uses a recurrence relation (maybe > related to/the same as in the paper you cited)? I can never seem to > find the original reference (dead link), but I've attached someone's > writeup of it. > > So, your implementation sounds reasonable, but if you really want to > dig into it you could check out the Gosper stuff and see how they > compare. > >> Can the PR implement formulas/methods that don't appear in the literature? >> Is it going to be a problem if I implement this limit case in the PR? > > It's implicit in the literature, so I think it's fine. > >> I don't what reference I would place hyp2f1's doc string > > The Buhring paper. The formula is something that an informed reader > could figure out after reading it. > >> I would be wiling to maybe add a latex doc to the PR (placed somewhere in >> the doc folder?) > > If I recall correctly people were opposed to adding LaTeX docs. (But > maybe I recall incorrectly; if so please someone correct me.) I also > have various special function write ups that might be handy for future > devs... maybe in a separate repo? > > On Wed, Oct 18, 2017 at 6:47 PM, Adam wrote: >> Hello guys, >> >> I've found a small region in the complex plane where scipy's >> implementation >> of the hypergeometric function hyp2f1 fails. I've documented this error in >> issue 8054 on github. >> >> I am willing to submit a PR that fixes this issue. My PR would basically >> implement the analytic continuation formula given in this paper: (Buhring, >> An Analytic Continuation of the Hypergeometric Series). I've already >> implemented this series in some prototype code written in Fortran and it >> agrees well with the values returned by mpmath's implementation of hyp2f1. >> >> Before I attempt a PR, I just wanted to touch base and ask the group the >> following: >> >> 1) Does this sound like a worthwhile PR? The failure region is somewhat >> small and I don't know with what urgency people would want this fixed. >> >> 2) Does the implementation sound reasonable? My background is physics and >> so >> I haven't done a complete literature search looking for the *fastest* >> algorithm. All I can say that the Buhring's formula works and my >> implementation only seems to be about %50 slower than the current hyp2f1 >> (at >> points in the complex plane where both methods converge). I would only >> apply >> Buhring's series in the region where hyp2f1 currently diverges. >> >> 3) Can the PR implement formulas/methods that don't appear in the >> literature? Buhring's paper *only* gives the analytic continuation for the >> case where the difference between the a/b parameters is NOT an integer. >> When >> a-b=m, the limit case of his series can be derived using a method >> described >> in "The Special Functions and Their Approximations" by Y. Luke (as Buhling >> mentions in his paper). I've derived the formula for this limit case and >> have an implementation of it that produces values in agreement with >> mpmath. >> Is it going to be a problem if I implement this limit case in the PR? I >> ask >> because I don't what reference I would place hyp2f1's doc string. I would >> be >> wiling to maybe add a latex doc to the PR (placed somewhere in the doc >> folder?) that contains the formula so that future scipy devs have >> something >> to reference when reviewing hyp2f1's source code. >> >> Anyways, let me know if my idea for a PR sounds like a good idea! I >> apologize for the longish email, but this is my first time trying to >> contribute to scipy... >> >> --Adam >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at python.org >> https://mail.python.org/mailman/listinfo/scipy-dev >> > > > > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > From Former at physicist.net Fri Oct 27 16:56:49 2017 From: Former at physicist.net (Adam) Date: Fri, 27 Oct 2017 13:56:49 -0700 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: References: <1508370462.5994.94.camel@physicist.net> <1508548981.3961.10.camel@physicist.net> <1509067578.16218.3.camel@physicist.net> Message-ID: <1509137809.3025.9.camel@physicist.net> I figured it out and it appears I wasn't running _generate_ufuncs.py beforehand... That said, the generated HTML still doesn't render my equations as a latex equation. ?That is to say, my output looks like: Is there a way of generating HTML that renders the latex equations? Like it appears on the?https://docs.scipy.org/doc/scipy/reference/gener ated/scipy.special.hyp2f1.html Bonus question: Is the 2nd author of the first reference misspelled, i.e., Jjie [sic]? ?Shouldn't the entire reference be:S. Zhang, J. Jin "Computation of Special Functions", Wiley, 1996? See?h ttps://books.google.com/books/about/Computation_of_special_functions.ht ml?id=ASfvAAAAMAAJ I can fix the first reference in my PR as well... --Adam On Thu, 2017-10-26 at 20:52 -0500, Joshua Wilson wrote: > > > > I do in fact get a bunch of html in the folders build/html, but the > > html for hyp2f1 doesn't contain my edits > If I recall correctly, Sphinx doesn't detect changes in the `_ufuncs` > extension module. Maybe try forcing a complete rebuild with `make > SPHINXOPTS=-Ea html`. > > On Thu, Oct 26, 2017 at 8:26 PM, Adam wrote: > > > > Hey guys, > > > > How do I view the html version of a functions docstring???I've > > added my > > Buhring reference to the docstring and I want to see how it renders > > in HTML. > > > > I've tried both methods described in > > https://github.com/scipy/scipy/blob/master/doc/README.txt but > > neither of > > them worked. > > > > When I try: > > (scipy-dev) adam at adam-P7xxDM-G:~/scipy-dev/scipy$ python setup.py > > build_sphinx > > I get: > > (...blah...blah...) > > usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] > > ...] > > ?or: setup.py --help [cmd1 cmd2 ...] > > ?or: setup.py --help-commands > > ?or: setup.py cmd --help > > error: invalid command 'build_sphinx' > > > > When I try : > > (scipy-dev) adam at adam-P7xxDM-G:~/scipy-dev/scipy/doc$ make html > > > > I do in fact get a bunch of html in the folders build/html, but the > > html for > > hyp2f1 doesn't contain my edits.??I've tried building html after > > reinstalling my dev version of scipy, but that didn't change > > anything. > > > > Thanks for any help! > > > > --Adam > > > > On Fri, 2017-10-20 at 18:23 -0700, Adam wrote: > > > > I can certainly add the formulas to the doc string if that's what > > people > > want.??My only concern is that the a-b=m case involves about a page > > of > > formula's and would take a lot of space in the doc string (I've > > attached the > > pdf from my latex file of the formulas). Originally I was thinking > > that the > > docstring would just contain some reference to the pdf document, > > e.g., "See > > the pdf at location X for the method used when a-b is an integer." > > > > But like I said, I can put them wherever they need to go; I justed > > wanted to > > make sure that future maintainers have some reference as to what > > the code is > > trying to do... > > > > --Adam > > > > On Fri, 2017-10-20 at 08:54 -0400, josef.pktd at gmail.com wrote: > > > > One possibility: > > Currently the only more extensive Latex based documentation is in > > the > > tutorial. > > I think it would be possible to add a technical appendix or > > something like > > that > > to the scipy.special tutorial, a bit similar to the distributions > > formulas > > attached to the > > stats tutorial. > > > > For example Boost, last time I checked, had long documentation for > > the > > special > > functions, which might be too long to fit in docstrings. > > > > I don't know how much there would be for special functions and > > whether it is > > difficult to maintain those notes. However, I think it would be > > good to have > > notes that developers have already written available for future > > developers and users that are interested in technical details. > > > > > > Josef > > > > > > On Fri, Oct 20, 2017 at 2:01 AM, Ralf Gommers > > > > wrote: > > > > > > > > On Thu, Oct 19, 2017 at 8:04 PM, Ted Pudlik > > wrote: > > > > Concerning the actual formulas: there's a compromise between > > leaving them > > implicit and creating a separate LaTeX doc.??You could add the > > formulas to > > the docstring.??The LaTeX will render in the HTML version of the > > documentation (example).??I'm not sure how the maintainers feel > > about this, > > though (this is just a suggestion from a "private citizen"). > > > > > > In general: using LaTeX can be a good idea, the one thing that has > > to be > > kept in mind is readability as plain text (important both for > > reading > > docstrings in IPython terminal and when working on the code in an > > editor). > > Best to add LaTeX formulas to the Notes section rather than in the > > first > > sentences. And avoid usage of things like \left[ that make the > > rendered html > > slightly prettier but the actual math much harder to read as plain > > text. > > > > Here's a recent PR with discussion about various LaTeX styles: > > https://github.com/scipy/scipy/pull/7756. The style that got merged > > is about > > right. > > > > Cheers, > > Ralf > > > > > > > > > > On Thu, Oct 19, 2017 at 11:59 AM Adam wrote: > > > > Okay cool; thanks for the helpful reply! > > > > I'll look at Gosper's method and see how it compares with Buhring's > > method. > > For now I'll plan on doing a PR that implements one of these two > > methods.??I > > was just worried that I might end up doing a lot of work on a PR > > that > > implements Buhring's series only to have a reviewer reject it > > saying "Well, > > you should have used such-and-such's algorithm which is must > > faster, much > > more accurate, etc." > > > > I'll also hold off on adding a latex doc to the repo of the actual > > formulas > > used for the b-a=integer special case (unless I hear otherwise). > > > > Thanks again! > > > > --Adam > > > > -----Original Message----- > > From: Joshua Wilson > > Sent: Thursday, October 19, 2017 9:35 AM > > To: SciPy Developers List > > Subject: Re: [SciPy-Dev] Fixing a bug with scipy's hypergeometric > > function > > hyp2f1 > > > > Hey Adam, > > > > > > > > Does this sound like a worthwhile PR? > > Yes, definitely > > > > > > > > Does the implementation sound reasonable? > > It's been a while since I've thought about this, but if I recall > > correctly the problematic region you've found is one that comes up > > quite frequently--see e.g. page 14 in > > > > http://fredrikj.net/math/hypgeom.pdf > > > > Floating around in the ether is a method credited to Bill Gosper > > for > > handling that region which also uses a recurrence relation (maybe > > related to/the same as in the paper you cited)? I can never seem to > > find the original reference (dead link), but I've attached > > someone's > > writeup of it. > > > > So, your implementation sounds reasonable, but if you really want > > to > > dig into it you could check out the Gosper stuff and see how they > > compare. > > > > > > > > Can the PR implement formulas/methods that don't appear in the > > > literature? > > > Is it going to be a problem if I implement this limit case in the > > > PR? > > It's implicit in the literature, so I think it's fine. > > > > > > > > I don't what reference I would place hyp2f1's doc string > > The Buhring paper. The formula is something that an informed reader > > could figure out after reading it. > > > > > > > > I would be wiling to maybe add a latex doc to the PR (placed > > > somewhere in > > > the doc folder?) > > If I recall correctly people were opposed to adding LaTeX docs. > > (But > > maybe I recall incorrectly; if so please someone correct me.) I > > also > > have various special function write ups that might be handy for > > future > > devs... maybe in a separate repo? > > > > On Wed, Oct 18, 2017 at 6:47 PM, Adam wrote: > > > > > > Hello guys, > > > > > > I've found a small region in the complex plane where scipy's > > > implementation > > > of the hypergeometric function hyp2f1 fails. I've documented this > > > error in > > > issue 8054 on github. > > > > > > I am willing to submit a PR that fixes this issue. My PR would > > > basically > > > implement the analytic continuation formula given in this paper: > > > (Buhring, > > > An Analytic Continuation of the Hypergeometric Series). I've > > > already > > > implemented this series in some prototype code written in Fortran > > > and it > > > agrees well with the values returned by mpmath's implementation > > > of hyp2f1. > > > > > > Before I attempt a PR, I just wanted to touch base and ask the > > > group the > > > following: > > > > > > 1) Does this sound like a worthwhile PR? The failure region is > > > somewhat > > > small and I don't know with what urgency people would want this > > > fixed. > > > > > > 2) Does the implementation sound reasonable? My background is > > > physics and > > > so > > > I haven't done a complete literature search looking for the > > > *fastest* > > > algorithm. All I can say that the Buhring's formula works and my > > > implementation only seems to be about %50 slower than the current > > > hyp2f1 > > > (at > > > points in the complex plane where both methods converge). I would > > > only > > > apply > > > Buhring's series in the region where hyp2f1 currently diverges. > > > > > > 3) Can the PR implement formulas/methods that don't appear in the > > > literature? Buhring's paper *only* gives the analytic > > > continuation for the > > > case where the difference between the a/b parameters is NOT an > > > integer. > > > When > > > a-b=m, the limit case of his series can be derived using a method > > > described > > > in "The Special Functions and Their Approximations" by Y. Luke > > > (as Buhling > > > mentions in his paper). I've derived the formula for this limit > > > case and > > > have an implementation of it that produces values in agreement > > > with > > > mpmath. > > > Is it going to be a problem if I implement this limit case in the > > > PR? I > > > ask > > > because I don't what reference I would place hyp2f1's doc string. > > > I would > > > be > > > wiling to maybe add a latex doc to the PR (placed somewhere in > > > the doc > > > folder?) that contains the formula so that future scipy devs have > > > something > > > to reference when reviewing hyp2f1's source code. > > > > > > Anyways, let me know if my idea for a PR sounds like a good idea! > > > I > > > apologize for the longish email, but this is my first time trying > > > to > > > contribute to scipy... > > > > > > --Adam > > > > > > _______________________________________________ > > > SciPy-Dev mailing list > > > SciPy-Dev at python.org > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > > > > > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unknown-WJZT8Y Type: image/png Size: 86595 bytes Desc: not available URL: From josh.craig.wilson at gmail.com Fri Oct 27 17:46:43 2017 From: josh.craig.wilson at gmail.com (Joshua Wilson) Date: Fri, 27 Oct 2017 16:46:43 -0500 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: <1509137809.3025.9.camel@physicist.net> References: <1508370462.5994.94.camel@physicist.net> <1508548981.3961.10.camel@physicist.net> <1509067578.16218.3.camel@physicist.net> <1509137809.3025.9.camel@physicist.net> Message-ID: > it appears I wasn't running _generate_ufuncs.py beforehand If _generate_ufuncs.py is in your repo then you aren't working with the master branch of SciPy. It was changed to _generate_pyx.py recently and is now run automatically as part of the build process. Make sure you update (or there will be a ton of merge conflicts when you submit the PR). > Is there a way of generating HTML that renders the latex equations? Maybe try make html-scipyorg. The first time you try it will probably complain that you are missing a git submodule, but it should also give instructions on how to fix that. > Is the 2nd author of the first reference misspelled Looks like it. On Fri, Oct 27, 2017 at 3:56 PM, Adam wrote: > I figured it out and it appears I wasn't running _generate_ufuncs.py > beforehand... > > That said, the generated HTML still doesn't render my equations as a latex > equation. That is to say, my output looks like: > > > *Is there a way of generating HTML that renders the latex equations?* > Like it appears on the https://docs.scipy.org/ > doc/scipy/reference/generated/scipy.special.hyp2f1.html > > *Bonus question: *Is the 2nd author of the first reference misspelled, > i.e., Jjie [sic]? Shouldn't the entire reference be: > S. Zhang, J. Jin "Computation of Special Functions", Wiley, 1996? See > > https://books.google.com/books/about/Computation_of_ > special_functions.html?id=ASfvAAAAMAAJ > > I can fix the first reference in my PR as well... > > --Adam > > On Thu, 2017-10-26 at 20:52 -0500, Joshua Wilson wrote: > > > I do in fact get a bunch of html in the folders build/html, but the html > for hyp2f1 doesn't contain my edits > > If I recall correctly, Sphinx doesn't detect changes in the `_ufuncs` > extension module. Maybe try forcing a complete rebuild with `make > SPHINXOPTS=-Ea html`. > > On Thu, Oct 26, 2017 at 8:26 PM, Adam wrote: > > > Hey guys, > > How do I view the html version of a functions docstring? I've added my > Buhring reference to the docstring and I want to see how it renders in > HTML. > > I've tried both methods described in > https://github.com/scipy/scipy/blob/master/doc/README.txt but neither of > them worked. > > When I try: > (scipy-dev) adam at adam-P7xxDM-G:~/scipy-dev/scipy$ python setup.py > build_sphinx > I get: > (...blah...blah...) > usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] > or: setup.py --help [cmd1 cmd2 ...] > or: setup.py --help-commands > or: setup.py cmd --help > error: invalid command 'build_sphinx' > > When I try : > (scipy-dev) adam at adam-P7xxDM-G:~/scipy-dev/scipy/doc$ make html > > I do in fact get a bunch of html in the folders build/html, but the html > for > hyp2f1 doesn't contain my edits. I've tried building html after > reinstalling my dev version of scipy, but that didn't change anything. > > Thanks for any help! > > --Adam > > On Fri, 2017-10-20 at 18:23 -0700, Adam wrote: > > I can certainly add the formulas to the doc string if that's what people > want. My only concern is that the a-b=m case involves about a page of > formula's and would take a lot of space in the doc string (I've attached > the > pdf from my latex file of the formulas). Originally I was thinking that the > docstring would just contain some reference to the pdf document, e.g., "See > the pdf at location X for the method used when a-b is an integer." > > But like I said, I can put them wherever they need to go; I justed wanted > to > make sure that future maintainers have some reference as to what the code > is > trying to do... > > --Adam > > On Fri, 2017-10-20 at 08:54 -0400, josef.pktd at gmail.com wrote: > > One possibility: > Currently the only more extensive Latex based documentation is in the > tutorial. > I think it would be possible to add a technical appendix or something like > that > to the scipy.special tutorial, a bit similar to the distributions formulas > attached to the > stats tutorial. > > For example Boost, last time I checked, had long documentation for the > special > functions, which might be too long to fit in docstrings. > > I don't know how much there would be for special functions and whether it > is > difficult to maintain those notes. However, I think it would be good to > have > notes that developers have already written available for future > developers and users that are interested in technical details. > > > Josef > > > On Fri, Oct 20, 2017 at 2:01 AM, Ralf Gommers > wrote: > > > > On Thu, Oct 19, 2017 at 8:04 PM, Ted Pudlik wrote: > > Concerning the actual formulas: there's a compromise between leaving them > implicit and creating a separate LaTeX doc. You could add the formulas to > the docstring. The LaTeX will render in the HTML version of the > documentation (example). I'm not sure how the maintainers feel about this, > though (this is just a suggestion from a "private citizen"). > > > In general: using LaTeX can be a good idea, the one thing that has to be > kept in mind is readability as plain text (important both for reading > docstrings in IPython terminal and when working on the code in an editor). > Best to add LaTeX formulas to the Notes section rather than in the first > sentences. And avoid usage of things like \left[ that make the rendered > html > slightly prettier but the actual math much harder to read as plain text. > > Here's a recent PR with discussion about various LaTeX styles: > https://github.com/scipy/scipy/pull/7756. The style that got merged is > about > right. > > Cheers, > Ralf > > > > > On Thu, Oct 19, 2017 at 11:59 AM Adam wrote: > > Okay cool; thanks for the helpful reply! > > I'll look at Gosper's method and see how it compares with Buhring's method. > For now I'll plan on doing a PR that implements one of these two > methods. I > was just worried that I might end up doing a lot of work on a PR that > implements Buhring's series only to have a reviewer reject it saying "Well, > you should have used such-and-such's algorithm which is must faster, much > more accurate, etc." > > I'll also hold off on adding a latex doc to the repo of the actual formulas > used for the b-a=integer special case (unless I hear otherwise). > > Thanks again! > > --Adam > > -----Original Message----- > From: Joshua Wilson > Sent: Thursday, October 19, 2017 9:35 AM > To: SciPy Developers List > Subject: Re: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function > hyp2f1 > > Hey Adam, > > > Does this sound like a worthwhile PR? > > Yes, definitely > > > Does the implementation sound reasonable? > > It's been a while since I've thought about this, but if I recall > correctly the problematic region you've found is one that comes up > quite frequently--see e.g. page 14 in > > http://fredrikj.net/math/hypgeom.pdf > > Floating around in the ether is a method credited to Bill Gosper for > handling that region which also uses a recurrence relation (maybe > related to/the same as in the paper you cited)? I can never seem to > find the original reference (dead link), but I've attached someone's > writeup of it. > > So, your implementation sounds reasonable, but if you really want to > dig into it you could check out the Gosper stuff and see how they > compare. > > > Can the PR implement formulas/methods that don't appear in the literature? > Is it going to be a problem if I implement this limit case in the PR? > > It's implicit in the literature, so I think it's fine. > > > I don't what reference I would place hyp2f1's doc string > > The Buhring paper. The formula is something that an informed reader > could figure out after reading it. > > > I would be wiling to maybe add a latex doc to the PR (placed somewhere in > the doc folder?) > > If I recall correctly people were opposed to adding LaTeX docs. (But > maybe I recall incorrectly; if so please someone correct me.) I also > have various special function write ups that might be handy for future > devs... maybe in a separate repo? > > On Wed, Oct 18, 2017 at 6:47 PM, Adam wrote: > > > Hello guys, > > I've found a small region in the complex plane where scipy's > implementation > of the hypergeometric function hyp2f1 fails. I've documented this error in > issue 8054 on github. > > I am willing to submit a PR that fixes this issue. My PR would basically > implement the analytic continuation formula given in this paper: (Buhring, > An Analytic Continuation of the Hypergeometric Series). I've already > implemented this series in some prototype code written in Fortran and it > agrees well with the values returned by mpmath's implementation of hyp2f1. > > Before I attempt a PR, I just wanted to touch base and ask the group the > following: > > 1) Does this sound like a worthwhile PR? The failure region is somewhat > small and I don't know with what urgency people would want this fixed. > > 2) Does the implementation sound reasonable? My background is physics and > so > I haven't done a complete literature search looking for the *fastest* > algorithm. All I can say that the Buhring's formula works and my > implementation only seems to be about %50 slower than the current hyp2f1 > (at > points in the complex plane where both methods converge). I would only > apply > Buhring's series in the region where hyp2f1 currently diverges. > > 3) Can the PR implement formulas/methods that don't appear in the > literature? Buhring's paper *only* gives the analytic continuation for the > case where the difference between the a/b parameters is NOT an integer. > When > a-b=m, the limit case of his series can be derived using a method > described > in "The Special Functions and Their Approximations" by Y. Luke (as Buhling > mentions in his paper). I've derived the formula for this limit case and > have an implementation of it that produces values in agreement with > mpmath. > Is it going to be a problem if I implement this limit case in the PR? I > ask > because I don't what reference I would place hyp2f1's doc string. I would > be > wiling to maybe add a latex doc to the PR (placed somewhere in the doc > folder?) that contains the formula so that future scipy devs have > something > to reference when reviewing hyp2f1's source code. > > Anyways, let me know if my idea for a PR sounds like a good idea! I > apologize for the longish email, but this is my first time trying to > contribute to scipy... > > --Adam > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unknown-WJZT8Y Type: image/png Size: 86595 bytes Desc: not available URL: From Former at physicist.net Fri Oct 27 19:50:49 2017 From: Former at physicist.net (Adam) Date: Fri, 27 Oct 2017 16:50:49 -0700 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: References: <1508370462.5994.94.camel@physicist.net> <1508548981.3961.10.camel@physicist.net> <1509067578.16218.3.camel@physicist.net> <1509137809.3025.9.camel@physicist.net> Message-ID: <1509148249.3025.16.camel@physicist.net> Okay *that* worked! Thank you very much! > > If _generate_ufuncs.py is in your repo then you aren't working with > the master branch of SciPy. It was changed to _generate_pyx.py recently > and is now run automatically as part of the build process. Make sure > you update (or there will be a ton of merge conflicts when you submit > the PR). My repo actually does have _generate_pyx.py which is what I meant; I copied _generate_ufuncs.py from the comment header of add_newdocs.py. ?In my PR, I'll change these comments so they refer to the new _generate_pyx.py... I'll also fix the reference to "Computation of Special Functions" in my PR unless someone objects... On Fri, 2017-10-27 at 16:46 -0500, Joshua Wilson wrote: > > it appears I wasn't running _generate_ufuncs.py beforehand> > If _generate_ufuncs.py is in your repo then you aren't working with the master branch of SciPy. It was changed to _generate_pyx.py recently and is now run automatically as part of the build process. Make sure you update (or there will be a ton of merge conflicts when you submit the PR).> > >?Is there a way of generating HTML that renders the latex equations?> > Maybe try make html-scipyorg. The first time you try it will probably complain that you are missing a git submodule, but it should also give instructions on how to fix that.> > > Is the 2nd author of the first reference misspelled> > Looks like it. > On Fri, Oct 27, 2017 at 3:56 PM, Adam > > wrote: > > I figured it out and it appears I wasn't running _generate_ufuncs.py beforehand... > > > > That said, the generated HTML still doesn't render my equations as a latex equation.? That is to say, my output looks like: > > > > Is there a way of generating HTML that renders the latex equations? Like it appears on the?https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.hyp2f1.html > > > > Bonus question: Is the 2nd author of the first reference misspelled, i.e., Jjie [sic]?? Shouldn't the entire reference be:> > S. Zhang, J. Jin "Computation of Special Functions", Wiley, 1996? See?https://books.google.com/books/about/Computation_of_special_functions.html?id=ASfvAAAAMAAJ > > I can fix the first reference in my PR as well... > > --Adam> > > > On Thu, 2017-10-26 at 20:52 -0500, Joshua Wilson wrote: > > > > > > > > I do in fact get a bunch of html in the folders build/html, but the html for hyp2f1 doesn't contain my edits > > > If I recall correctly, Sphinx doesn't detect changes in the `_ufuncs` > > > extension module. Maybe try forcing a complete rebuild with `make > > > SPHINXOPTS=-Ea html`. > > > > > > On Thu, Oct 26, 2017 at 8:26 PM, Adam wrote: > > > > > > > > Hey guys, > > > > > > > > How do I view the html version of a functions docstring???I've added my > > > > Buhring reference to the docstring and I want to see how it renders in HTML. > > > > > > > > I've tried both methods described in > > > > https://github.com/scipy/scipy/blob/master/doc/README.txt but neither of > > > > them worked. > > > > > > > > When I try: > > > > (scipy-dev) adam at adam-P7xxDM-G:~/scipy-> > > > dev/scipy$ python setup.py > > > > build_sphinx > > > > I get: > > > > (...blah...blah...) > > > > usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] > > > > ?or: setup.py --help [cmd1 cmd2 ...] > > > > ?or: setup.py --help-commands > > > > ?or: setup.py cmd --help > > > > error: invalid command 'build_sphinx' > > > > > > > > When I try : > > > > (scipy-dev) adam at adam-P7xxDM-G:~/scipy-> > > > dev/scipy/doc$ make html > > > > > > > > I do in fact get a bunch of html in the folders build/html, but the html for > > > > hyp2f1 doesn't contain my edits.??I've tried building html after > > > > reinstalling my dev version of scipy, but that didn't change anything. > > > > > > > > Thanks for any help! > > > > > > > > --Adam > > > > > > > > On Fri, 2017-10-20 at 18:23 -0700, Adam wrote: > > > > > > > > I can certainly add the formulas to the doc string if that's what people > > > > want.??My only concern is that the a-b=m case involves about a page of > > > > formula's and would take a lot of space in the doc string (I've attached the > > > > pdf from my latex file of the formulas). Originally I was thinking that the > > > > docstring would just contain some reference to the pdf document, e.g., "See > > > > the pdf at location X for the method used when a-b is an integer." > > > > > > > > But like I said, I can put them wherever they need to go; I justed wanted to > > > > make sure that future maintainers have some reference as to what the code is > > > > trying to do... > > > > > > > > --Adam > > > > > > > > On Fri, 2017-10-20 at 08:54 -0400, josef.pktd at gmail.com wrote: > > > > > > > > One possibility: > > > > Currently the only more extensive Latex based documentation is in the > > > > tutorial. > > > > I think it would be possible to add a technical appendix or something like > > > > that > > > > to the scipy.special tutorial, a bit similar to the distributions formulas > > > > attached to the > > > > stats tutorial. > > > > > > > > For example Boost, last time I checked, had long documentation for the > > > > special > > > > functions, which might be too long to fit in docstrings. > > > > > > > > I don't know how much there would be for special functions and whether it is > > > > difficult to maintain those notes. However, I think it would be good to have > > > > notes that developers have already written available for future > > > > developers and users that are interested in technical details. > > > > > > > > > > > > Josef > > > > > > > > > > > > On Fri, Oct 20, 2017 at 2:01 AM, Ralf Gommers > > > > wrote: > > > > > > > > > > > > > > > > On Thu, Oct 19, 2017 at 8:04 PM, Ted Pudlik wrote: > > > > > > > > Concerning the actual formulas: there's a compromise between leaving them > > > > implicit and creating a separate LaTeX doc.??You could add the formulas to > > > > the docstring.??The LaTeX will render in the HTML version of the > > > > documentation (example).??I'm not sure how the maintainers feel about this, > > > > though (this is just a suggestion from a "private citizen"). > > > > > > > > > > > > In general: using LaTeX can be a good idea, the one thing that has to be > > > > kept in mind is readability as plain text (important both for reading > > > > docstrings in IPython terminal and when working on the code in an editor). > > > > Best to add LaTeX formulas to the Notes section rather than in the first > > > > sentences. And avoid usage of things like \left[ that make the rendered html > > > > slightly prettier but the actual math much harder to read as plain text. > > > > > > > > Here's a recent PR with discussion about various LaTeX styles: > > > > https://github.com/scipy/scipy/pull/7756. The style that got merged is about > > > > right. > > > > > > > > Cheers, > > > > Ralf > > > > > > > > > > > > > > > > > > > > On Thu, Oct 19, 2017 at 11:59 AM Adam wrote: > > > > > > > > Okay cool; thanks for the helpful reply! > > > > > > > > I'll look at Gosper's method and see how it compares with Buhring's method. > > > > For now I'll plan on doing a PR that implements one of these two methods.??I > > > > was just worried that I might end up doing a lot of work on a PR that > > > > implements Buhring's series only to have a reviewer reject it saying "Well, > > > > you should have used such-and-such's algorithm which is must faster, much > > > > more accurate, etc." > > > > > > > > I'll also hold off on adding a latex doc to the repo of the actual formulas > > > > used for the b-a=integer special case (unless I hear otherwise). > > > > > > > > Thanks again! > > > > > > > > --Adam > > > > > > > > -----Original Message----- > > > > From: Joshua Wilson > > > > Sent: Thursday, October 19, 2017 9:35 AM > > > > To: SciPy Developers List > > > > Subject: Re: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function > > > > hyp2f1 > > > > > > > > Hey Adam, > > > > > > > > > > > > > > Does this sound like a worthwhile PR? > > > > Yes, definitely > > > > > > > > > > > > > > Does the implementation sound reasonable? > > > > It's been a while since I've thought about this, but if I recall > > > > correctly the problematic region you've found is one that comes up > > > > quite frequently--see e.g. page 14 in > > > > > > > > http://fredrikj.net/math/hypgeom.pdf > > > > > > > > Floating around in the ether is a method credited to Bill Gosper for > > > > handling that region which also uses a recurrence relation (maybe > > > > related to/the same as in the paper you cited)? I can never seem to > > > > find the original reference (dead link), but I've attached someone's > > > > writeup of it. > > > > > > > > So, your implementation sounds reasonable, but if you really want to > > > > dig into it you could check out the Gosper stuff and see how they > > > > compare. > > > > > > > > > > > > > > Can the PR implement formulas/methods that don't appear in the literature? > > > > > Is it going to be a problem if I implement this limit case in the PR? > > > > It's implicit in the literature, so I think it's fine. > > > > > > > > > > > > > > I don't what reference I would place hyp2f1's doc string > > > > The Buhring paper. The formula is something that an informed reader > > > > could figure out after reading it. > > > > > > > > > > > > > > I would be wiling to maybe add a latex doc to the PR (placed somewhere in > > > > > the doc folder?) > > > > If I recall correctly people were opposed to adding LaTeX docs. (But > > > > maybe I recall incorrectly; if so please someone correct me.) I also > > > > have various special function write ups that might be handy for future > > > > devs... maybe in a separate repo? > > > > > > > > On Wed, Oct 18, 2017 at 6:47 PM, Adam wrote: > > > > > > > > > > Hello guys, > > > > > > > > > > I've found a small region in the complex plane where scipy's > > > > > implementation > > > > > of the hypergeometric function hyp2f1 fails. I've documented this error in > > > > > issue 8054 on github. > > > > > > > > > > I am willing to submit a PR that fixes this issue. My PR would basically > > > > > implement the analytic continuation formula given in this paper: (Buhring, > > > > > An Analytic Continuation of the Hypergeometric Series). I've already > > > > > implemented this series in some prototype code written in Fortran and it > > > > > agrees well with the values returned by mpmath's implementation of hyp2f1. > > > > > > > > > > Before I attempt a PR, I just wanted to touch base and ask the group the > > > > > following: > > > > > > > > > > 1) Does this sound like a worthwhile PR? The failure region is somewhat > > > > > small and I don't know with what urgency people would want this fixed. > > > > > > > > > > 2) Does the implementation sound reasonable? My background is physics and > > > > > so > > > > > I haven't done a complete literature search looking for the *fastest* > > > > > algorithm. All I can say that the Buhring's formula works and my > > > > > implementation only seems to be about %50 slower than the current hyp2f1 > > > > > (at > > > > > points in the complex plane where both methods converge). I would only > > > > > apply > > > > > Buhring's series in the region where hyp2f1 currently diverges. > > > > > > > > > > 3) Can the PR implement formulas/methods that don't appear in the > > > > > literature? Buhring's paper *only* gives the analytic continuation for the > > > > > case where the difference between the a/b parameters is NOT an integer. > > > > > When > > > > > a-b=m, the limit case of his series can be derived using a method > > > > > described > > > > > in "The Special Functions and Their Approximations" by Y. Luke (as Buhling > > > > > mentions in his paper). I've derived the formula for this limit case and > > > > > have an implementation of it that produces values in agreement with > > > > > mpmath. > > > > > Is it going to be a problem if I implement this limit case in the PR? I > > > > > ask > > > > > because I don't what reference I would place hyp2f1's doc string. I would > > > > > be > > > > > wiling to maybe add a latex doc to the PR (placed somewhere in the doc > > > > > folder?) that contains the formula so that future scipy devs have > > > > > something > > > > > to reference when reviewing hyp2f1's source code. > > > > > > > > > > Anyways, let me know if my idea for a PR sounds like a good idea! I > > > > > apologize for the longish email, but this is my first time trying to > > > > > contribute to scipy... > > > > > > > > > > --Adam > > > > > > > > > > ______________________________> > > > > _________________ > > > > > SciPy-Dev mailing list > > > > > SciPy-Dev at python.org > > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________> > > > _________________ > > > > SciPy-Dev mailing list > > > > SciPy-Dev at python.org > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > ______________________________> > > > _________________ > > > > SciPy-Dev mailing list > > > > SciPy-Dev at python.org > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > > > > > ______________________________> > > > _________________ > > > > SciPy-Dev mailing list > > > > SciPy-Dev at python.org > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > > > > > > > > > ______________________________> > > > _________________ > > > > SciPy-Dev mailing list > > > > SciPy-Dev at python.org > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > > > > > ______________________________> > > > _________________ > > > > SciPy-Dev mailing list > > > > SciPy-Dev at python.org > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > ______________________________> > > > _________________ > > > > SciPy-Dev mailing list > > > > SciPy-Dev at python.org > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > > > > > > ______________________________> > > > _________________ > > > > SciPy-Dev mailing list > > > > SciPy-Dev at python.org > > > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > ______________________________> > > _________________ > > > SciPy-Dev mailing list > > > SciPy-Dev at python.org > > > https://mail.python.org/mailman/listinfo/scipy-dev > > ______________________________> > _________________ > > > > SciPy-Dev mailing list > > SciPy-Dev at python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org> https://mail.python.org/mailman/listinfo/scipy-dev> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unknown-WJZT8Y Type: image/png Size: 86595 bytes Desc: not available URL: From josh.craig.wilson at gmail.com Fri Oct 27 20:26:52 2017 From: josh.craig.wilson at gmail.com (Joshua Wilson) Date: Fri, 27 Oct 2017 19:26:52 -0500 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: <1509148249.3025.16.camel@physicist.net> References: <1508370462.5994.94.camel@physicist.net> <1508548981.3961.10.camel@physicist.net> <1509067578.16218.3.camel@physicist.net> <1509137809.3025.9.camel@physicist.net> <1509148249.3025.16.camel@physicist.net> Message-ID: It might make sense to submit some of these smaller fixes as quick PRs. They will require little review and can get merged quickly, while the process for algorithm changes will likely take more time. - Josh On Fri, Oct 27, 2017 at 6:50 PM, Adam wrote: > Okay *that* worked! Thank you very much! > > > If _generate_ufuncs.py is in your repo then you aren't working with the > master branch of SciPy. It was changed to _generate_pyx.py recently and is > now run automatically as part of the build process. Make sure you update > (or there will be a ton of merge conflicts when you submit the PR). > > > My repo actually does have _generate_pyx.py which is what I meant; I > copied _generate_ufuncs.py from the comment header of add_newdocs.py. In > my PR, I'll change these comments so they refer to the new > _generate_pyx.py... > > I'll also fix the reference to "Computation of Special Functions" in my PR > unless someone objects... > > On Fri, 2017-10-27 at 16:46 -0500, Joshua Wilson wrote: > > > it appears I wasn't running _generate_ufuncs.py beforehand > > If _generate_ufuncs.py is in your repo then you aren't working with the > master branch of SciPy. It was changed to _generate_pyx.py recently and is > now run automatically as part of the build process. Make sure you update > (or there will be a ton of merge conflicts when you submit the PR). > > > Is there a way of generating HTML that renders the latex equations? > > Maybe try make html-scipyorg. The first time you try it will probably > complain that you are missing a git submodule, but it should also give > instructions on how to fix that. > > > Is the 2nd author of the first reference misspelled > > Looks like it. > > On Fri, Oct 27, 2017 at 3:56 PM, Adam wrote: > > I figured it out and it appears I wasn't running _generate_ufuncs.py > beforehand... > > That said, the generated HTML still doesn't render my equations as a latex > equation. That is to say, my output looks like: > > > *Is there a way of generating HTML that renders the latex equations?* > Like it appears on the https://docs.scipy.org/doc > /scipy/reference/generated/scipy.special.hyp2f1.html > > *Bonus question: *Is the 2nd author of the first reference misspelled, > i.e., Jjie [sic]? Shouldn't the entire reference be: > S. Zhang, J. Jin "Computation of Special Functions", Wiley, 1996? See > > https://books.google.com/books/about/Computation_of_spec > ial_functions.html?id=ASfvAAAAMAAJ > > I can fix the first reference in my PR as well... > > --Adam > > On Thu, 2017-10-26 at 20:52 -0500, Joshua Wilson wrote: > > > I do in fact get a bunch of html in the folders build/html, but the html > for hyp2f1 doesn't contain my edits > > If I recall correctly, Sphinx doesn't detect changes in the `_ufuncs` > extension module. Maybe try forcing a complete rebuild with `make > SPHINXOPTS=-Ea html`. > > On Thu, Oct 26, 2017 at 8:26 PM, Adam wrote: > > > Hey guys, > > How do I view the html version of a functions docstring? I've added my > Buhring reference to the docstring and I want to see how it renders in > HTML. > > I've tried both methods described in > https://github.com/scipy/scipy/blob/master/doc/README.txt but neither of > them worked. > > When I try: > (scipy-dev) adam at adam-P7xxDM-G:~/scipy-dev/scipy$ python setup.py > build_sphinx > I get: > (...blah...blah...) > usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] > or: setup.py --help [cmd1 cmd2 ...] > or: setup.py --help-commands > or: setup.py cmd --help > error: invalid command 'build_sphinx' > > When I try : > (scipy-dev) adam at adam-P7xxDM-G:~/scipy-dev/scipy/doc$ make html > > I do in fact get a bunch of html in the folders build/html, but the html > for > hyp2f1 doesn't contain my edits. I've tried building html after > reinstalling my dev version of scipy, but that didn't change anything. > > Thanks for any help! > > --Adam > > On Fri, 2017-10-20 at 18:23 -0700, Adam wrote: > > I can certainly add the formulas to the doc string if that's what people > want. My only concern is that the a-b=m case involves about a page of > formula's and would take a lot of space in the doc string (I've attached > the > pdf from my latex file of the formulas). Originally I was thinking that the > docstring would just contain some reference to the pdf document, e.g., "See > the pdf at location X for the method used when a-b is an integer." > > But like I said, I can put them wherever they need to go; I justed wanted > to > make sure that future maintainers have some reference as to what the code > is > trying to do... > > --Adam > > On Fri, 2017-10-20 at 08:54 -0400, josef.pktd at gmail.com wrote: > > One possibility: > Currently the only more extensive Latex based documentation is in the > tutorial. > I think it would be possible to add a technical appendix or something like > that > to the scipy.special tutorial, a bit similar to the distributions formulas > attached to the > stats tutorial. > > For example Boost, last time I checked, had long documentation for the > special > functions, which might be too long to fit in docstrings. > > I don't know how much there would be for special functions and whether it > is > difficult to maintain those notes. However, I think it would be good to > have > notes that developers have already written available for future > developers and users that are interested in technical details. > > > Josef > > > On Fri, Oct 20, 2017 at 2:01 AM, Ralf Gommers > wrote: > > > > On Thu, Oct 19, 2017 at 8:04 PM, Ted Pudlik wrote: > > Concerning the actual formulas: there's a compromise between leaving them > implicit and creating a separate LaTeX doc. You could add the formulas to > the docstring. The LaTeX will render in the HTML version of the > documentation (example). I'm not sure how the maintainers feel about this, > though (this is just a suggestion from a "private citizen"). > > > In general: using LaTeX can be a good idea, the one thing that has to be > kept in mind is readability as plain text (important both for reading > docstrings in IPython terminal and when working on the code in an editor). > Best to add LaTeX formulas to the Notes section rather than in the first > sentences. And avoid usage of things like \left[ that make the rendered > html > slightly prettier but the actual math much harder to read as plain text. > > Here's a recent PR with discussion about various LaTeX styles: > https://github.com/scipy/scipy/pull/7756. The style that got merged is > about > right. > > Cheers, > Ralf > > > > > On Thu, Oct 19, 2017 at 11:59 AM Adam wrote: > > Okay cool; thanks for the helpful reply! > > I'll look at Gosper's method and see how it compares with Buhring's method. > For now I'll plan on doing a PR that implements one of these two > methods. I > was just worried that I might end up doing a lot of work on a PR that > implements Buhring's series only to have a reviewer reject it saying "Well, > you should have used such-and-such's algorithm which is must faster, much > more accurate, etc." > > I'll also hold off on adding a latex doc to the repo of the actual formulas > used for the b-a=integer special case (unless I hear otherwise). > > Thanks again! > > --Adam > > -----Original Message----- > From: Joshua Wilson > Sent: Thursday, October 19, 2017 9:35 AM > To: SciPy Developers List > Subject: Re: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function > hyp2f1 > > Hey Adam, > > > Does this sound like a worthwhile PR? > > Yes, definitely > > > Does the implementation sound reasonable? > > It's been a while since I've thought about this, but if I recall > correctly the problematic region you've found is one that comes up > quite frequently--see e.g. page 14 in > > http://fredrikj.net/math/hypgeom.pdf > > Floating around in the ether is a method credited to Bill Gosper for > handling that region which also uses a recurrence relation (maybe > related to/the same as in the paper you cited)? I can never seem to > find the original reference (dead link), but I've attached someone's > writeup of it. > > So, your implementation sounds reasonable, but if you really want to > dig into it you could check out the Gosper stuff and see how they > compare. > > > Can the PR implement formulas/methods that don't appear in the literature? > Is it going to be a problem if I implement this limit case in the PR? > > It's implicit in the literature, so I think it's fine. > > > I don't what reference I would place hyp2f1's doc string > > The Buhring paper. The formula is something that an informed reader > could figure out after reading it. > > > I would be wiling to maybe add a latex doc to the PR (placed somewhere in > the doc folder?) > > If I recall correctly people were opposed to adding LaTeX docs. (But > maybe I recall incorrectly; if so please someone correct me.) I also > have various special function write ups that might be handy for future > devs... maybe in a separate repo? > > On Wed, Oct 18, 2017 at 6:47 PM, Adam wrote: > > > Hello guys, > > I've found a small region in the complex plane where scipy's > implementation > of the hypergeometric function hyp2f1 fails. I've documented this error in > issue 8054 on github. > > I am willing to submit a PR that fixes this issue. My PR would basically > implement the analytic continuation formula given in this paper: (Buhring, > An Analytic Continuation of the Hypergeometric Series). I've already > implemented this series in some prototype code written in Fortran and it > agrees well with the values returned by mpmath's implementation of hyp2f1. > > Before I attempt a PR, I just wanted to touch base and ask the group the > following: > > 1) Does this sound like a worthwhile PR? The failure region is somewhat > small and I don't know with what urgency people would want this fixed. > > 2) Does the implementation sound reasonable? My background is physics and > so > I haven't done a complete literature search looking for the *fastest* > algorithm. All I can say that the Buhring's formula works and my > implementation only seems to be about %50 slower than the current hyp2f1 > (at > points in the complex plane where both methods converge). I would only > apply > Buhring's series in the region where hyp2f1 currently diverges. > > 3) Can the PR implement formulas/methods that don't appear in the > literature? Buhring's paper *only* gives the analytic continuation for the > case where the difference between the a/b parameters is NOT an integer. > When > a-b=m, the limit case of his series can be derived using a method > described > in "The Special Functions and Their Approximations" by Y. Luke (as Buhling > mentions in his paper). I've derived the formula for this limit case and > have an implementation of it that produces values in agreement with > mpmath. > Is it going to be a problem if I implement this limit case in the PR? I > ask > because I don't what reference I would place hyp2f1's doc string. I would > be > wiling to maybe add a latex doc to the PR (placed somewhere in the doc > folder?) that contains the formula so that future scipy devs have > something > to reference when reviewing hyp2f1's source code. > > Anyways, let me know if my idea for a PR sounds like a good idea! I > apologize for the longish email, but this is my first time trying to > contribute to scipy... > > --Adam > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing listSciPy-Dev at python.orghttps://mail.python.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unknown-WJZT8Y Type: image/png Size: 86595 bytes Desc: not available URL: From ralf.gommers at gmail.com Sun Oct 29 06:18:42 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 29 Oct 2017 23:18:42 +1300 Subject: [SciPy-Dev] [gpaw-users] wrapper for Scalapack In-Reply-To: References: <57d2d270-9083-e1d6-6ed9-21de7f872154@mailoo.org> Message-ID: On Fri, Oct 6, 2017 at 10:37 PM, Anne Archibald wrote: > On Thu, Oct 5, 2017 at 8:36 PM Ralf Gommers > wrote: > >> On Fri, Oct 6, 2017 at 7:05 AM, wrote: >> >>> >>> But does distributed computing stay out of scope for SciPy after 1.0? >>> As a long term plan towards 2.0? >>> >> >> Such changes are worth discussing once in a while, usually sharpens the >> focus:) >> >> My first thoughts: >> - traditional stuff like MPI, BLACS, ScaLAPACK will likely always remain >> out of scope >> - we can consider new dependencies, but only if they do not make it >> harder to install SciPy >> - a few more likely changes would be to start allowing/supporting pandas >> data frames as inputs, broader use of simple (optional) parallelization >> with joblib or threading, and using dask under the hood. >> > Interesting thoughts, thanks Anne. This thread is a bit stale by now, but I still wanted to record my thoughts on the topic. > There seems to be a profusion of tools for parallelization, so choosing > just one to use as a basis for scipy's parallelization could be really > frustrating for users who have a reason to need a different one. > You're thinking about the relatively small fraction of power users here that would care (compared to the n_jobs= trivial parallelization users), and my first thought is that addressing that use case comes with costs that are possibly not worth the effort. > The exception, I would say, is the concurrent.futures interface. > In terms of user friendliness, I'd say concurrent.futures is pretty poor. This: with futures.ThreadPoolExecutor(max_workers=4) as executor: some_function(..., pool=executor.map) is much worse than: some_function(..., n_jobs=4) This is part of python (3), and it allows a limited but manageable and > useful amount of parallelization. It is also an interface other tools can > and do implement. For example, emcee is capable of taking advantage of > parallelization, but that parallelization happens entirely in one place: a > map is done to compute log-probabilities for a list of candidates. emcee is > agnostic about how this map works; by default it can use python's built-in > map, but emcee provides an "MPIPool" object that supplies a parallel map > that uses MPI, python's ThreadPoolExecutor and ProcessPoolExecutor also > provide such a parallel map, and (for example) dask provides an Executor > interface that allows such a map across a collection of dask instances. > > So: I think it would be good if scipy could incorporate the use of > Executors to achieve parallelism where that's available from the underlying > algorithms. From the user's point of view, this just means one or two more > optional arguments, in particular a "pool" argument from which futures are > generated. > It'd have to be two I think, like in emcee which has `*threads=1*, *pool=None`. *I'd say `threads` (or `n_jobs` as in scikit-learn and spatial.cKDTree) is the must-have if we go for more parallel support and `pool` is the power user one that would be a tradeoff. It would enable users of MPI, dask, etc., but on the other hand it makes the API more verbose, is more work to support, and a lot harder to test. IIRC joblib also does a lot of work to make ndarrays (and other objects?) pickleable to make parallelization work for a wider range of functions that plain multiprocessing. So I'm undecided on whether a `pool` keyword would make sense in scipy. In turn, it might make sense to implement a few new algorithms that can use > parallelism effectively. The global optimizers spring to mind as candidates > for this process, but in fact any local optimizer that needs a gradient but > has to compute it numerically can probably benefit from computing the > derivative in parallel. > Clustering functions would be another good candidate. > This sort of opportunistic parallelization is no substitute for something > like Scalapack or PaGMO, dedicated distributed computing algorithms, but it > is a way for scipy to allow easy parallelization where possible. > Agreed Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From bennet at umich.edu Sun Oct 29 08:14:41 2017 From: bennet at umich.edu (Bennet Fauber) Date: Sun, 29 Oct 2017 08:14:41 -0400 Subject: [SciPy-Dev] [gpaw-users] wrapper for Scalapack In-Reply-To: References: <57d2d270-9083-e1d6-6ed9-21de7f872154@mailoo.org> Message-ID: Ralf, and all, >> There seems to be a profusion of tools for parallelization, so choosing >> just one to use as a basis for scipy's parallelization could be really >> frustrating for users who have a reason to need a different one. > > You're thinking about the relatively small fraction of power users here that > would care (compared to the n_jobs= trivial parallelization users), > and my first thought is that addressing that use case comes with costs that > are possibly not worth the effort. You might consider separating that which can be done on one physical machine from that which requires (or expects) many. This was largely done by the R developers. The 'snow' library used rsh/ssh whereas the 'multicore' library used fork() and processors. Steve Weston and company have the 'foreach' library that provides a user interface to various backends that distribute the tasks appropriately. Only after many years of experience, they merged many functions into 'parallel' which became part of the base R. It would probably be good to try to coordinate efforts at parallelizing within SciPy, if you choose to go that route, with those who are trying to get this to work better at the program level, e.g., multiprocessing and ipyparallel. Whatever gets done, it would be good to have it work well with many of the ways that people are implementing parallel computing. As a cluster administrator and help desk person, I would also encourage you to think about how this would play out in a shared environment that is administered not by the scientist but by some system administrator who may have different ideas about what can and cannot be done with respect to intermachine communication and using multiple processes (for example, is ssh blocked? are user jobs put into cgroups to limit cores and memory?). Just a couple of thoughts from the sidelines; hopefully not too far off topic. From ralf.gommers at gmail.com Sun Oct 29 15:15:32 2017 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 30 Oct 2017 08:15:32 +1300 Subject: [SciPy-Dev] [gpaw-users] wrapper for Scalapack In-Reply-To: References: <57d2d270-9083-e1d6-6ed9-21de7f872154@mailoo.org> Message-ID: On Mon, Oct 30, 2017 at 1:14 AM, Bennet Fauber wrote: > Ralf, and all, > > >> There seems to be a profusion of tools for parallelization, so choosing > >> just one to use as a basis for scipy's parallelization could be really > >> frustrating for users who have a reason to need a different one. > > > > You're thinking about the relatively small fraction of power users here > that > > would care (compared to the n_jobs= trivial parallelization > users), > > and my first thought is that addressing that use case comes with costs > that > > are possibly not worth the effort. > > You might consider separating that which can be done on one physical > machine from that which requires (or expects) many. > > This was largely done by the R developers. The 'snow' library used > rsh/ssh whereas the 'multicore' library used fork() and processors. > Steve Weston and company have the 'foreach' library that provides a > user interface to various backends that distribute the tasks > appropriately. Only after many years of experience, they merged many > functions into 'parallel' which became part of the base R. > Thanks, always interesting to know the history of how designs evolved in related libraries/languages. > It would probably be good to try to coordinate efforts at > parallelizing within SciPy, if you choose to go that route, with those > who are trying to get this to work better at the program level, e.g., > multiprocessing and ipyparallel. Multiprocessing is exactly what I was talking about (use directly or via joblib, which is built on top of it). Ipyparallel is squarely aimed at use from within Jupyter, so not very relevant in the context of a library. Actually the implementation isn't too interesting I think (scipy.spatial.cKDTree uses threading rather than multiprocessing for example); having an easy and uniform API is what matters. Whatever gets done, it would be good > to have it work well with many of the ways that people are > implementing parallel computing. > > As a cluster administrator and help desk person, I would also > encourage you to think about how this would play out in a shared > environment that is administered not by the scientist but by some > system administrator who may have different ideas about what can and > cannot be done with respect to intermachine communication and using > multiple processes (for example, is ssh blocked? are user jobs put > into cgroups to limit cores and memory?). > The one thing I can think of is the design of `n_jobs=-1`, which means "use as many cores as present". This could pick up the limit on cores if that is defined in a standard way for a given OS. This must have come up for scikit-learn before I'd think. > Just a couple of thoughts from the sidelines; hopefully not too far off > topic. > Not at all. Thanks. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From Former at physicist.net Sun Oct 29 17:54:41 2017 From: Former at physicist.net (Adam) Date: Sun, 29 Oct 2017 14:54:41 -0700 Subject: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 In-Reply-To: References: <1508370462.5994.94.camel@physicist.net> <1508548981.3961.10.camel@physicist.net> <1509067578.16218.3.camel@physicist.net> <1509137809.3025.9.camel@physicist.net> <1509148249.3025.16.camel@physicist.net> Message-ID: <634DE32C08AE43DABCE9760C1323289D@DESKTOPPNU8RST> okay; tomorrow I?ll make a small PR that just fixes the reference type and the code comments referring to ?_generate_ufuncs.py?. I?ll grep the ?./special/? folder to see if I can find any other places that refer to ?_generate_ufuncs.py? --Adam From: Joshua Wilson Sent: Friday, October 27, 2017 5:26 PM To: SciPy Developers List Subject: Re: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 It might make sense to submit some of these smaller fixes as quick PRs. They will require little review and can get merged quickly, while the process for algorithm changes will likely take more time. - Josh On Fri, Oct 27, 2017 at 6:50 PM, Adam wrote: Okay *that* worked! Thank you very much! > If _generate_ufuncs.py is in your repo then you aren't working with the master branch of SciPy. It was changed to _generate_pyx.py recently and is now run automatically as part of the build process. Make sure you update (or there will be a ton of merge conflicts when you submit the PR). My repo actually does have _generate_pyx.py which is what I meant; I copied _generate_ufuncs.py from the comment header of add_newdocs.py. In my PR, I'll change these comments so they refer to the new _generate_pyx.py... I'll also fix the reference to "Computation of Special Functions" in my PR unless someone objects... On Fri, 2017-10-27 at 16:46 -0500, Joshua Wilson wrote: > it appears I wasn't running _generate_ufuncs.py beforehand If _generate_ufuncs.py is in your repo then you aren't working with the master branch of SciPy. It was changed to _generate_pyx.py recently and is now run automatically as part of the build process. Make sure you update (or there will be a ton of merge conflicts when you submit the PR). > Is there a way of generating HTML that renders the latex equations? Maybe try make html-scipyorg. The first time you try it will probably complain that you are missing a git submodule, but it should also give instructions on how to fix that. > Is the 2nd author of the first reference misspelled Looks like it. On Fri, Oct 27, 2017 at 3:56 PM, Adam wrote: I figured it out and it appears I wasn't running _generate_ufuncs.py beforehand... That said, the generated HTML still doesn't render my equations as a latex equation. That is to say, my output looks like: Is there a way of generating HTML that renders the latex equations? Like it appears on the https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.hyp2f1.html Bonus question: Is the 2nd author of the first reference misspelled, i.e., Jjie [sic]? Shouldn't the entire reference be: S. Zhang, J. Jin "Computation of Special Functions", Wiley, 1996? See https://books.google.com/books/about/Computation_of_special_functions.html?id=ASfvAAAAMAAJ I can fix the first reference in my PR as well... --Adam On Thu, 2017-10-26 at 20:52 -0500, Joshua Wilson wrote: I do in fact get a bunch of html in the folders build/html, but the html for hyp2f1 doesn't contain my edits If I recall correctly, Sphinx doesn't detect changes in the `_ufuncs` extension module. Maybe try forcing a complete rebuild with `make SPHINXOPTS=-Ea html`. On Thu, Oct 26, 2017 at 8:26 PM, Adam wrote: Hey guys, How do I view the html version of a functions docstring? I've added my Buhring reference to the docstring and I want to see how it renders in HTML. I've tried both methods described in https://github.com/scipy/scipy/blob/master/doc/README.txt but neither of them worked. When I try: (scipy-dev) adam at adam-P7xxDM-G:~/scipy-dev/scipy$ python setup.py build_sphinx I get: (...blah...blah...) usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: invalid command 'build_sphinx' When I try : (scipy-dev) adam at adam-P7xxDM-G:~/scipy-dev/scipy/doc$ make html I do in fact get a bunch of html in the folders build/html, but the html for hyp2f1 doesn't contain my edits. I've tried building html after reinstalling my dev version of scipy, but that didn't change anything. Thanks for any help! --Adam On Fri, 2017-10-20 at 18:23 -0700, Adam wrote: I can certainly add the formulas to the doc string if that's what people want. My only concern is that the a-b=m case involves about a page of formula's and would take a lot of space in the doc string (I've attached the pdf from my latex file of the formulas). Originally I was thinking that the docstring would just contain some reference to the pdf document, e.g., "See the pdf at location X for the method used when a-b is an integer." But like I said, I can put them wherever they need to go; I justed wanted to make sure that future maintainers have some reference as to what the code is trying to do... --Adam On Fri, 2017-10-20 at 08:54 -0400, josef.pktd at gmail.com wrote: One possibility: Currently the only more extensive Latex based documentation is in the tutorial. I think it would be possible to add a technical appendix or something like that to the scipy.special tutorial, a bit similar to the distributions formulas attached to the stats tutorial. For example Boost, last time I checked, had long documentation for the special functions, which might be too long to fit in docstrings. I don't know how much there would be for special functions and whether it is difficult to maintain those notes. However, I think it would be good to have notes that developers have already written available for future developers and users that are interested in technical details. Josef On Fri, Oct 20, 2017 at 2:01 AM, Ralf Gommers wrote: On Thu, Oct 19, 2017 at 8:04 PM, Ted Pudlik wrote: Concerning the actual formulas: there's a compromise between leaving them implicit and creating a separate LaTeX doc. You could add the formulas to the docstring. The LaTeX will render in the HTML version of the documentation (example). I'm not sure how the maintainers feel about this, though (this is just a suggestion from a "private citizen"). In general: using LaTeX can be a good idea, the one thing that has to be kept in mind is readability as plain text (important both for reading docstrings in IPython terminal and when working on the code in an editor). Best to add LaTeX formulas to the Notes section rather than in the first sentences. And avoid usage of things like \left[ that make the rendered html slightly prettier but the actual math much harder to read as plain text. Here's a recent PR with discussion about various LaTeX styles: https://github.com/scipy/scipy/pull/7756. The style that got merged is about right. Cheers, Ralf On Thu, Oct 19, 2017 at 11:59 AM Adam wrote: Okay cool; thanks for the helpful reply! I'll look at Gosper's method and see how it compares with Buhring's method. For now I'll plan on doing a PR that implements one of these two methods. I was just worried that I might end up doing a lot of work on a PR that implements Buhring's series only to have a reviewer reject it saying "Well, you should have used such-and-such's algorithm which is must faster, much more accurate, etc." I'll also hold off on adding a latex doc to the repo of the actual formulas used for the b-a=integer special case (unless I hear otherwise). Thanks again! --Adam -----Original Message----- From: Joshua Wilson Sent: Thursday, October 19, 2017 9:35 AM To: SciPy Developers List Subject: Re: [SciPy-Dev] Fixing a bug with scipy's hypergeometric function hyp2f1 Hey Adam, Does this sound like a worthwhile PR? Yes, definitely Does the implementation sound reasonable? It's been a while since I've thought about this, but if I recall correctly the problematic region you've found is one that comes up quite frequently--see e.g. page 14 in http://fredrikj.net/math/hypgeom.pdf Floating around in the ether is a method credited to Bill Gosper for handling that region which also uses a recurrence relation (maybe related to/the same as in the paper you cited)? I can never seem to find the original reference (dead link), but I've attached someone's writeup of it. So, your implementation sounds reasonable, but if you really want to dig into it you could check out the Gosper stuff and see how they compare. Can the PR implement formulas/methods that don't appear in the literature? Is it going to be a problem if I implement this limit case in the PR? It's implicit in the literature, so I think it's fine. I don't what reference I would place hyp2f1's doc string The Buhring paper. The formula is something that an informed reader could figure out after reading it. I would be wiling to maybe add a latex doc to the PR (placed somewhere in the doc folder?) If I recall correctly people were opposed to adding LaTeX docs. (But maybe I recall incorrectly; if so please someone correct me.) I also have various special function write ups that might be handy for future devs... maybe in a separate repo? On Wed, Oct 18, 2017 at 6:47 PM, Adam wrote: Hello guys, I've found a small region in the complex plane where scipy's implementation of the hypergeometric function hyp2f1 fails. I've documented this error in issue 8054 on github. I am willing to submit a PR that fixes this issue. My PR would basically implement the analytic continuation formula given in this paper: (Buhring, An Analytic Continuation of the Hypergeometric Series). I've already implemented this series in some prototype code written in Fortran and it agrees well with the values returned by mpmath's implementation of hyp2f1. Before I attempt a PR, I just wanted to touch base and ask the group the following: 1) Does this sound like a worthwhile PR? The failure region is somewhat small and I don't know with what urgency people would want this fixed. 2) Does the implementation sound reasonable? My background is physics and so I haven't done a complete literature search looking for the *fastest* algorithm. All I can say that the Buhring's formula works and my implementation only seems to be about %50 slower than the current hyp2f1 (at points in the complex plane where both methods converge). I would only apply Buhring's series in the region where hyp2f1 currently diverges. 3) Can the PR implement formulas/methods that don't appear in the literature? Buhring's paper *only* gives the analytic continuation for the case where the difference between the a/b parameters is NOT an integer. When a-b=m, the limit case of his series can be derived using a method described in "The Special Functions and Their Approximations" by Y. Luke (as Buhling mentions in his paper). I've derived the formula for this limit case and have an implementation of it that produces values in agreement with mpmath. Is it going to be a problem if I implement this limit case in the PR? I ask because I don't what reference I would place hyp2f1's doc string. I would be wiling to maybe add a latex doc to the PR (placed somewhere in the doc folder?) that contains the formula so that future scipy devs have something to reference when reviewing hyp2f1's source code. Anyways, let me know if my idea for a PR sounds like a good idea! I apologize for the longish email, but this is my first time trying to contribute to scipy... --Adam _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev -------------------------------------------------------------------------------- _______________________________________________ SciPy-Dev mailing list SciPy-Dev at python.org https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unknown-WJZT8Y Type: image/png Size: 86595 bytes Desc: not available URL: From marc.barbry at mailoo.org Mon Oct 30 04:25:11 2017 From: marc.barbry at mailoo.org (marc) Date: Mon, 30 Oct 2017 09:25:11 +0100 Subject: [SciPy-Dev] [gpaw-users] wrapper for Scalapack In-Reply-To: References: <57d2d270-9083-e1d6-6ed9-21de7f872154@mailoo.org> Message-ID: <2660e630-e97f-4f37-c42d-d17d2418b7a6@mailoo.org> Dear all, I'm glad to see that the Scipy community look interested by this topic. As I pointed out with the first mail of this thread, we started an implementation of ScaLapack wrapper, you can find it at the following repository, https://gitlab.com/mbarbry/python-scalapack We try to use the same method that have been use in Scipy for the Blas/Lapack wrapper (using f2py). The wrapper is already functional, but the installation is not as straightforward that I would hope and only very few routines are implemented? for the moment. So any help is more than welcome. Best regards, Marc On 10/29/2017 08:15 PM, Ralf Gommers wrote: > > > On Mon, Oct 30, 2017 at 1:14 AM, Bennet Fauber > wrote: > > Ralf, and all, > > >> There seems to be a profusion of tools for parallelization, so > choosing > >> just one to use as a basis for scipy's parallelization could be > really > >> frustrating for users who have a reason to need a different one. > > > > You're thinking about the relatively small fraction of power > users here that > > would care (compared to the n_jobs= trivial > parallelization users), > > and my first thought is that addressing that use case comes with > costs that > > are possibly not worth the effort. > > You might consider separating that which can be done on one physical > machine from that which requires (or expects) many. > > This was largely done by the R developers.? The 'snow' library used > rsh/ssh whereas the 'multicore' library used fork() and processors. > Steve Weston and company have the 'foreach' library that provides a > user interface to various backends that distribute the tasks > appropriately.? Only after many years of experience, they merged many > functions into 'parallel' which became part of the base R. > > > Thanks, always interesting to know the history of how designs evolved > in related libraries/languages. > > > It would probably be good to try to coordinate efforts at > parallelizing within SciPy, if you choose to go that route, with those > who are trying to get this to work better at the program level, e.g., > multiprocessing and ipyparallel. > > > Multiprocessing is exactly what I was talking about (use directly or > via joblib, which is built on top of it). Ipyparallel is squarely > aimed at use from within Jupyter, so not very relevant in the context > of a library. > > Actually the implementation isn't too interesting I think > (scipy.spatial.cKDTree uses threading rather than multiprocessing for > example); having an easy and uniform API is what matters. > > Whatever gets done, it would be good > to have it work well with many of the ways that people are > implementing parallel computing. > > As a cluster administrator and help desk person, I would also > encourage you to think about how this would play out in a shared > environment that is administered not by the scientist but by some > system administrator who may have different ideas about what can and > cannot be done with respect to intermachine communication and using > multiple processes (for example, is ssh blocked? are user jobs put > into cgroups to limit cores and memory?). > > > The one thing I can think of is the design of `n_jobs=-1`, which means > "use as many cores as present". This could pick up the limit on cores > if that is defined in a standard way for a given OS. This must have > come up for scikit-learn before I'd think. > > > Just a couple of thoughts from the sidelines; hopefully not too > far off topic. > > > Not at all. Thanks. > > Ralf > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: