Skip to content

P
pytensor
提交 bf053fca authored 作者: Francesco Visin's avatar Francesco Visin
浏览文件
操作

Improve dev start guide and extending theano

- Move the contribution requirements on top, so that contributors read them even if they know how to setup GitHub - Fix minor errors - Remove commented code in elemwise
上级 043cdaea
隐藏空白字符变更
内嵌 并排
正在显示 包含 207 行增加 和 212 行删除
doc/dev_start_guide.txt
浏览文件 @ bf053fca
...@@ -45,180 +45,10 @@ To get up to speed, you'll need to ...@@ -45,180 +45,10 @@ To get up to speed, you'll need to
.. _nose: http://nose.readthedocs.org/en/latest/ .. _nose: http://nose.readthedocs.org/en/latest/
Installation and configuration
==============================
To obtain developer access: register with `GitHub
<http://www.github.com/>`_ and create a fork of `Theano
<http://www.github.com/Theano/Theano>`_.
This will create your own Theano project on GitHub, referred later
as "YourProfile/Theano", or "origin", from which you will be able to
contribute to the original Theano/Theano, also called "central".
Create a local copy
-------------------
Clone your fork locally with
.. code-block:: bash
git clone git@github.com:YOUR_GITHUB_LOGIN/Theano.git
For this URL to work, you must set your public ssh keys inside your
`github account setting <https://github.com/settings/ssh>`_.
From your local repository, your own fork on GitHub will be called "origin".
Then, add a reference to the original ("central") Theano repository with
.. code-block:: bash
git remote add central git://github.com/Theano/Theano.git
You can choose another name than "central" to reference Theano/Theano
(for instance, NumPy uses "upstream"), but this documentation will stick
to "central."
You can then test your installation of Theano by following the steps of
:ref:`testing_installation`.
Using your local copy
---------------------
To update your library to the latest revision, you should have a local branch
that tracks central/master. You can add one (named "trunk" here) with:
.. code-block:: bash
git fetch central
git branch trunk central/master
Once you have such a branch, in order to update it, do:
.. code-block:: bash
git checkout trunk
git pull
Keep in mind that this branch should be "read-only": if you want to
patch Theano, you should work in another branch, like described in the
:ref:`dev_workflow` section below.
Configure Git
-------------
On your local machine, you need to configure git with basic informations:
.. code-block:: bash
git config --global user.email you@yourdomain.example.com
git config --global user.name "Your Name Comes Here"
You can also instruct git to use color in diff. For this, you need to
add those lines in the file ~/.gitconfig
.. code-block:: cfg
[color]
branch = auto
diff = auto
interactive = auto
status = auto
.. _dev_workflow:
Development Workflow
====================
Start a new local branch
------------------------
When working on a new feature in your own fork, start from an up-to-date copy
of the `master` branch (the principal one) of the central repository
(Theano/Theano on GitHub):
.. code-block:: bash
git fetch central
git checkout -b my_shiny_feature central/master
.. note::
This last line is a shortcut for:
.. code-block:: bash
git branch my_shiny_feature central/master
git checkout my_shiny_feature
Submit your changes to the central repository
---------------------------------------------
Once your code is ready for others to review, you need to commit all the changes and then push your
branch to your github fork first:
.. code-block:: bash
git commit -a -m "your message here"
.. code-block:: bash
git push -u origin my_shiny_feature
Then, go to your fork's github page on the github website, select your
feature branch and hit the "Pull Request" button in the top right
corner. This will signal the maintainers that you wish to submit your
changes for inclusion in central/master.
If you don't get any feedback, bug us on the theano-dev mailing list.
Address reviewer comments
-------------------------
Your pull request will be reviewed by members of the core development
team. If your branch is not directly accepted, the reviewers will use
GitHub's system to add "notes", either general (on the entire commit),
or "line notes", relative to a particular line of code.
In order to have the pull request accepted, you may have to answer
the reviewer's questions, you can do that on GitHub.
You may also have to edit your code to address their concerns. Some
of the usual requests include fixing typos in comments, adding or
correcting comments, adding unit tests in the test suite. In order to
do that, you should continue your edits in the same branch you used (in
this example, "my_shiny_feature"). For instance, if you changed your
working branch, you should first:
.. code-block:: bash
git checkout my_shiny_feature
Then, edit your code, and test it appropriately (see
:ref:`quality_contributions` below), and push it again to your GitHub
fork, like the first time (except the ``-u`` option is only needed the
first time):
.. code-block:: bash
git push origin my_shiny_feature
The pull request to the central repository will then be automatically
updated by GitHub. However, the reviewers will not be automatically
notified of your revision, so it is advised to reply to the comments on
GitHub, to let them know that you have submitted a fix.
.. _quality_contributions: .. _quality_contributions:
Tips for Quality Contributions Requirements for Quality Contributions
============================== ======================================
* All the code should be properly tested. * All the code should be properly tested.
...@@ -303,32 +133,35 @@ To setup VIM: ...@@ -303,32 +133,35 @@ To setup VIM:
git clone https://github.com/VundleVim/Vundle.vim.git ~/.vim/bundle/Vundle.vim git clone https://github.com/VundleVim/Vundle.vim.git ~/.vim/bundle/Vundle.vim
#. Edit ``~/.vimrc`` and add the lines:: #. Edit ``~/.vimrc`` and add the lines:
.. code-block:: txt .. code-block:: python
set nocompatible " be iMproved, required set nocompatible " be iMproved, required
filetype off " required filetype off " required
" set the runtime path to include Vundle and initialize " set the runtime path to include Vundle and initialize
set rtp+=~/.vim/bundle/Vundle.vim set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin() call vundle#begin()
Plugin 'gmarik/Vundle.vim' " let Vundle manage Vundle (required!) Plugin 'gmarik/Vundle.vim' " let Vundle manage Vundle (required!)
Plugin 'scrooloose/syntastic' Plugin 'scrooloose/syntastic'
Plugin 'jimf/vim-pep8-text-width' Plugin 'jimf/vim-pep8-text-width'
" Syntastic settings " Syntastic settings
" You can run checkers explicitly by calling :SyntasticCheck <checker " You can run checkers explicitly by calling :SyntasticCheck <checker
let g:syntastic_python_checkers = ['flake8'] "use one of the following checkers: let g:syntastic_python_checkers = ['flake8'] "use one of the following checkers:
" flake8, pyflakes, pylint, python (native checker) " flake8, pyflakes, pylint, python (native checker)
let g:syntastic_enable_highlighting = 1 "highlight errors and warnings let g:syntastic_enable_highlighting = 1 "highlight errors and warnings
let g:syntastic_style_error_symbol = ">>" "error symbol let g:syntastic_style_error_symbol = ">>" "error symbol
let g:syntastic_warning_symbol = ">>" "warning symbol let g:syntastic_warning_symbol = ">>" "warning symbol
let g:syntastic_check_on_open = 1 let g:syntastic_check_on_open = 1
let g:syntastic_auto_jump = 0 "do not jump to errors when detected let g:syntastic_auto_jump = 0 "do not jump to errors when detected
#. Open a new vim and run ``:PluginInstall`` to automatically install the #. Open a new vim and run ``:PluginInstall`` to automatically install the
plugins. When the installation is done, close the installation "window" with ``:q``. From now on Vim will check for PEP8 errors and highlight them whenever a file is saved. plugins. When the installation is done, close the installation "window"
with ``:q``.
From now on Vim will check for PEP8 errors and highlight them whenever a
file is saved.
A few useful commands A few useful commands
""""""""""""""""""""" """""""""""""""""""""
...@@ -487,6 +320,175 @@ documentation: ...@@ -487,6 +320,175 @@ documentation:
.. automodule:: theano.misc.doubleop .. automodule:: theano.misc.doubleop
:members: :members:
Installation and configuration
==============================
To obtain developer access: register with `GitHub
<http://www.github.com/>`_ and create a fork of `Theano
<http://www.github.com/Theano/Theano>`_.
This will create your own Theano project on GitHub, referred later
as "YourProfile/Theano", or "origin", from which you will be able to
contribute to the original Theano/Theano, also called "central".
Create a local copy
-------------------
Clone your fork locally with
.. code-block:: bash
git clone git@github.com:YOUR_GITHUB_LOGIN/Theano.git
For this URL to work, you must set your public ssh keys inside your
`github account setting <https://github.com/settings/ssh>`_.
From your local repository, your own fork on GitHub will be called "origin".
Then, add a reference to the original ("central") Theano repository with
.. code-block:: bash
git remote add central git://github.com/Theano/Theano.git
You can choose another name than "central" to reference Theano/Theano
(for instance, NumPy uses "upstream"), but this documentation will stick
to "central."
You can then test your installation of Theano by following the steps of
:ref:`testing_installation`.
Using your local copy
---------------------
To update your library to the latest revision, you should have a local branch
that tracks central/master. You can add one (named "trunk" here) with:
.. code-block:: bash
git fetch central
git branch trunk central/master
Once you have such a branch, in order to update it, do:
.. code-block:: bash
git checkout trunk
git pull
Keep in mind that this branch should be "read-only": if you want to
patch Theano, you should work in another branch, like described in the
:ref:`dev_workflow` section below.
Configure Git
-------------
On your local machine, you need to configure git with basic informations:
.. code-block:: bash
git config --global user.email you@yourdomain.example.com
git config --global user.name "Your Name Comes Here"
You can also instruct git to use color in diff. For this, you need to
add those lines in the file ~/.gitconfig
.. code-block:: cfg
[color]
branch = auto
diff = auto
interactive = auto
status = auto
.. _dev_workflow:
Development Workflow
====================
Start a new local branch
------------------------
When working on a new feature in your own fork, start from an up-to-date copy
of the `master` branch (the principal one) of the central repository
(Theano/Theano on GitHub):
.. code-block:: bash
git fetch central
git checkout -b my_shiny_feature central/master
.. note::
This last line is a shortcut for:
.. code-block:: bash
git branch my_shiny_feature central/master
git checkout my_shiny_feature
Submit your changes to the central repository
---------------------------------------------
Once your code is ready for others to review, you need to commit all the changes and then push your
branch to your github fork first:
.. code-block:: bash
git commit -a -m "your message here"
.. code-block:: bash
git push -u origin my_shiny_feature
Then, go to your fork's github page on the github website, select your
feature branch and hit the "Pull Request" button in the top right
corner. This will signal the maintainers that you wish to submit your
changes for inclusion in central/master.
If you don't get any feedback, bug us on the theano-dev mailing list.
Address reviewer comments
-------------------------
Your pull request will be reviewed by members of the core development
team. If your branch is not directly accepted, the reviewers will use
GitHub's system to add "notes", either general (on the entire commit),
or "line notes", relative to a particular line of code.
In order to have the pull request accepted, you may have to answer
the reviewer's questions, you can do that on GitHub.
You may also have to edit your code to address their concerns. Some
of the usual requests include fixing typos in comments, adding or
correcting comments, adding unit tests in the test suite. In order to
do that, you should continue your edits in the same branch you used (in
this example, "my_shiny_feature"). For instance, if you changed your
working branch, you should first:
.. code-block:: bash
git checkout my_shiny_feature
Then, edit your code, and test it appropriately (see
:ref:`quality_contributions` below), and push it again to your GitHub
fork, like the first time (except the ``-u`` option is only needed the
first time):
.. code-block:: bash
git push origin my_shiny_feature
The pull request to the central repository will then be automatically
updated by GitHub. However, the reviewers will not be automatically
notified of your revision, so it is advised to reply to the comments on
GitHub, to let them know that you have submitted a fix.
More Advanced Git Usage More Advanced Git Usage
======================= =======================
......
doc/extending/unittest.txt
浏览文件 @ bf053fca
...@@ -476,10 +476,8 @@ Here is an example showing how to use ``verify_grad`` on an Op instance: ...@@ -476,10 +476,8 @@ Here is an example showing how to use ``verify_grad`` on an Op instance:
.. testcode:: .. testcode::
def test_flatten_outdimNone(): def test_flatten_outdimNone():
""" # Testing gradient w.r.t. all inputs of an op (in this example the op
Testing gradient w.r.t. all inputs of an op (in this example the op # being used is Flatten(), which takes a single input).
being used is Flatten(), which takes a single input).
"""
a_val = numpy.asarray([[0,1,2],[3,4,5]], dtype='float64') a_val = numpy.asarray([[0,1,2],[3,4,5]], dtype='float64')
rng = numpy.random.RandomState(42) rng = numpy.random.RandomState(42)
tensor.verify_grad(tensor.Flatten(), [a_val], rng=rng) tensor.verify_grad(tensor.Flatten(), [a_val], rng=rng)
......
theano/tensor/elemwise.py
浏览文件 @ bf053fca
...@@ -356,11 +356,6 @@ class DimShuffle(Op): ...@@ -356,11 +356,6 @@ class DimShuffle(Op):
"if (strides[%(i)s] == 0) strides[%(i)s] = strides[%(i)s+1] * " "if (strides[%(i)s] == 0) strides[%(i)s] = strides[%(i)s+1] * "
"dimensions[%(i)s+1]" % dict(i=str(i))) "dimensions[%(i)s+1]" % dict(i=str(i)))
#
# PyObject* PyArray_New(PyTypeObject* subtype, int nd, npy_intp* dims,
# int type_num, npy_intp* strides, void* data,
# int itemsize, int flags, PyObject* obj)
#
close_bracket = [ close_bracket = [
# create a new array, # create a new array,
('%(res)s = (PyArrayObject*)PyArray_New(&PyArray_Type, ' ('%(res)s = (PyArrayObject*)PyArray_New(&PyArray_Type, '
...@@ -494,17 +489,17 @@ class Elemwise(OpenMPOp): ...@@ -494,17 +489,17 @@ class Elemwise(OpenMPOp):
variable number of inputs), whereas the numpy function may variable number of inputs), whereas the numpy function may
not have varargs. not have varargs.
Examples Note
-------- ----
>>> Elemwise(add) # represents + on tensors (x + y) | Elemwise(add) represents + on tensors (x + y)
>>> Elemwise(add, {0 : 0}) # represents the += operation (x += y) | Elemwise(add, {0 : 0}) represents the += operation (x += y)
>>> Elemwise(add, {0 : 1}) # represents += on the second argument (y += x) | Elemwise(add, {0 : 1}) represents += on the second argument (y += x)
>>> Elemwise(mul)(rand(10, 5), rand(1, 5)) # the second input is completed | Elemwise(mul)(rand(10, 5), rand(1, 5)) the second input is completed \
>>> # along the first dimension to match the first input along the first dimension to match the first input
>>> Elemwise(true_div)(rand(10, 5), rand(10, 1)) # same but along the | Elemwise(true_div)(rand(10, 5), rand(10, 1)) same but along the \
>>> # second dimension second dimension
>>> Elemwise(int_div)(rand(1, 5), rand(10, 1)) # the output has size (10, 5) | Elemwise(int_div)(rand(1, 5), rand(10, 1)) the output has size (10, 5)
>>> Elemwise(log)(rand(3, 4, 5)) | Elemwise(log)(rand(3, 4, 5))
""" """
......
Markdown 格式
0% 或
您添加了 0 人 到此讨论。请谨慎行事。
请先完成此评论的编辑！
请 注册 或者 后发表评论