From a35305be70fe1a80b45e088bff5637e2b3b107c0 Mon Sep 17 00:00:00 2001 From: Fernando Perez Date: Sat, 28 May 2011 18:39:52 -0700 Subject: [PATCH] Restructuring and updating docs --- .gitignore | 5 +- datarray/LICENSE | 6 - doc/Makefile | 4 +- doc/source/basic_data_array.rst | 54 +---- doc/source/conf.py | 3 +- doc/source/data_array_discussion.rst | 86 ------- doc/source/data_summit_proposal.rst | 56 ++++- .../design_questions/data_array_overview.rst | 109 ++++++++- doc/source/design_questions/index.rst | 8 - doc/source/design_questions/issues.rst | 223 +++++++++--------- doc/source/design_questions/license_info.rst | 3 - .../design_questions/licenses/la_license.rst | 72 ------ doc/source/index.rst | 9 +- doc/source/license.rst | 16 ++ doc/source/licenses/numpydoc_license.rst | 102 ++++++++ .../licenses/pandas_license.rst | 4 + doc/source/other_projects/index.rst | 15 ++ .../larry_overview.rst | 0 .../pandas_overview.rst | 0 doc/source/printing.rst | 3 +- doc/sphinxext/LICENSE.txt | 97 -------- 21 files changed, 422 insertions(+), 453 deletions(-) delete mode 100644 doc/source/data_array_discussion.rst delete mode 100644 doc/source/design_questions/license_info.rst delete mode 100644 doc/source/design_questions/licenses/la_license.rst create mode 100644 doc/source/licenses/numpydoc_license.rst rename doc/source/{design_questions => }/licenses/pandas_license.rst (96%) mode change 100755 => 100644 create mode 100644 doc/source/other_projects/index.rst rename doc/source/{design_questions => other_projects}/larry_overview.rst (100%) rename doc/source/{design_questions => other_projects}/pandas_overview.rst (100%) delete mode 100644 doc/sphinxext/LICENSE.txt diff --git a/.gitignore b/.gitignore index 5128d74..7292ea9 100644 --- a/.gitignore +++ b/.gitignore @@ -3,7 +3,7 @@ # setup.py working directory build # setup.py dist directory -./dist +dist/ # Documentation build files doc/build # Editor temporary/working/backup files @@ -27,3 +27,6 @@ doc/build ./.shelf # Mac droppings .DS_Store + +# Build products +MANIFEST diff --git a/datarray/LICENSE b/datarray/LICENSE index 6ed22ee..8f7c999 100644 --- a/datarray/LICENSE +++ b/datarray/LICENSE @@ -104,9 +104,3 @@ DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - - -numpydoc license ----------------- - -The numpydoc license is in datarray/doc/sphinxext/LICENSE.txt diff --git a/doc/Makefile b/doc/Makefile index bc1f8d4..70296b8 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -11,7 +11,9 @@ PAPEROPT_a4 = -D latex_paper_size=a4 PAPEROPT_letter = -D latex_paper_size=letter ALLSPHINXOPTS = -d build/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source -.PHONY: help clean html dirhtml pickle json htmlhelp qthelp latex changes linkcheck doctest +.PHONY: help clean html dirhtml pickle json htmlhelp qthelp latex changes linkcheck doctest all + +all: html help: @echo "Please use \`make ' where is one of" diff --git a/doc/source/basic_data_array.rst b/doc/source/basic_data_array.rst index 9da334f..996c963 100644 --- a/doc/source/basic_data_array.rst +++ b/doc/source/basic_data_array.rst @@ -70,7 +70,7 @@ The names and the position have to be the same, and the above example should raise an error. At least for now we will raise an error, and review later. With "labels" ------------- +------------- Constructing a DataArray such that an Axis has labels, for example: @@ -108,55 +108,6 @@ By normal "numpy" slicing: >>> narr.axis.a[0].axes == narr[0,:].axes True -Through the "axis slicer" ``aix`` attribute: - - >>> narr[ narr.aix.b[:2].c[-1] ] - DataArray([[ 0., 0.]]) - ('a', 'b') - >>> narr[ narr.aix.c[-1].b[:2] ] - DataArray([[ 0., 0.]]) - ('a', 'b') - >>> narr[ narr.aix.c[-1].b[:2] ] == narr[:,:2,-1] - DataArray([[ True, True]], dtype=bool) - ('a', 'b') - -The Axis Indexing object (it's a stuple) ----------------------------------------- - -The ``aix`` attribute is a property which generates a "stuple" (special/slicing tuple):: - - @property - def aix(self): - # Returns an anonymous slicing tuple that knows - # about this array's geometry - return stuple( ( slice(None), ) * self.ndim, - axes = self.axes ) - - -The stuple should have a reference to a group of Axis objects that describes an -array's geometry. If the stuple is associated with a specific Axis, then when -sliced itself, it can create a slicing tuple for the array with the given -geometry. -: - - >>> narr.aix - (slice(None, None, None), slice(None, None, None), slice(None, None, None)) - >>> narr.names - ('a', 'b', 'c') - >>> narr.aix.b[0] - (slice(None, None, None), 0, slice(None, None, None)) - -**Note** -- the ``aix`` attribute provides some shorthand syntax for the following: - - >>> narr.axis.c[-1].axis.b[:2] - DataArray([[ 0., 0.]]) - ('a', 'b') - -The mechanics are slightly different (using ``aix``, a slicing tuple is created -up-front before ``__getitem__`` is called), but functionality is the same. -**Question** -- Is it convenient enough to include the ``aix`` slicer? should -it function differently? - Also, slicing with ``newaxis`` is implemented: >>> arr = np.arange(24).reshape((3,2,4)) @@ -178,7 +129,7 @@ Axis with length-1 at the original index of the named Axis: (3, 1, 2, 4) Slicing and labels ------------------ +------------------ It is also possible to use labels in any of the slicing syntax above: @@ -516,4 +467,3 @@ a[i] valid cases: - i: integer => normal numpy scalar indexing, one less dim than x - i: slice: numpy view slicing. same dims as x, must recover the labels - i: list/array: numpy fancy indexing, as long as the index list is 1d only. - diff --git a/doc/source/conf.py b/doc/source/conf.py index ab8711a..0add79e 100644 --- a/doc/source/conf.py +++ b/doc/source/conf.py @@ -130,7 +130,8 @@ # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['_static'] +#html_static_path = ['_static'] +html_static_path = [] # If not '', a 'Last updated on:' timestamp is inserted at every page bottom, # using the given strftime format. diff --git a/doc/source/data_array_discussion.rst b/doc/source/data_array_discussion.rst deleted file mode 100644 index 0d72385..0000000 --- a/doc/source/data_array_discussion.rst +++ /dev/null @@ -1,86 +0,0 @@ -(my thoughts on) What Is The DataArray? -======================================= - -* 1st and foremost, **an ndarray**, in N dimensions, with any dtype -* has means to locate data more descriptively (IE, with custom names - for dimensions/axes, and custom names for indices along any axis) - -:: - - >>> darr = DataArray(np.random.randn(2,3,4), ('ex', 'why', 'zee')) - >>> darr.sum(axis='ex') - DataArray([[-0.39052695, -2.07493873, 1.19664474, 0.36681094], - [-1.04287781, 0.5767191 , -0.35425298, 1.10468356], - [ 0.08331866, -0.36532857, 0.12905265, -1.94559672]]) - ('why', 'zee') - >>> for subarr in darr.axis.why: - ... print subarr.shape, subarr.labels - ... - (2, 4) ('ex', 'zee') - (2, 4) ('ex', 'zee') - (2, 4) ('ex', 'zee') - -* An axis "label" can always stand in for an axis number; an index - "tick" can (in some TBD sense) stand in for an integer index -* if anything is **more restrictive** in operations, for example - -:: - - >>> ndarr_ones = np.ones((10,10,10)) - >>> ndarr_twos = np.ones((10,10,10))*2 - >>> ndarr_3s = ndarr_ones + ndarr_twos # OK! - >>> darr_abc = DataArray(ndarr_ones, ('a', 'b', 'c')) - >>> darr_bac = DataArray(ndarr_twos, ('b', 'a', 'c')) - >>> darr_wtf = darr_abc + darr_bac # BAD! frames are rotated - -(and my very own thoughts on) What The DataArray Is Not -======================================================= - -Unions And Intersections ------------------------- - -DataArray may broadcast with certain union rules for adapting -metadata, but it does not do any data union/intersection rule for -operations. For example, the result of adding an array with axes ('a', 'c') with an -array with axis 'c' takes on information from the "superset" of -axes. This is analogous to ndarray taking on shape information from -the superset of shapes. - -:: - - >>> darr_abc[:,0,:] - DataArray([[ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.], - ... - [ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]]) - ('a', 'c') - >>> darr_bac[0,0] - DataArray([ 2., 2., 2., 2., 2., 2., 2., 2., 2., 2.]) - ('c',) - >>> darr_abc[:,0,:] + darr_bac[0,0] - DataArray([[ 3., 3., 3., 3., 3., 3., 3., 3., 3., 3.], - ... - [ 3., 3., 3., 3., 3., 3., 3., 3., 3., 3.]]) - ('a', 'c') - -But it will not fill or trim any dimension to fit the shape of a -fellow operand's array (it seems this violation is simply caught at the C-level of an ndarray):: - - >>> darr_abc[:,0,:] + darr_bac[0,0,:5] - ------------------------------------------------------------ - Traceback (most recent call last): - File "", line 1, in - ValueError: shape mismatch: objects cannot be broadcast to a single shape - -For me, this looks like the **domain of utility functions** (or -possibly utility methods that yield new DataArrays). - -Namespace ---------- - -It would be good practice to keep all the dynamically generated -DataArray attributes (eg, Axis labels) removed from the top-level -array attribute list. This is what we currently have as "axis". - -It might(?) be a good idea to put all future special purpose methods -under that object too. - diff --git a/doc/source/data_summit_proposal.rst b/doc/source/data_summit_proposal.rst index 3873d04..65e948f 100644 --- a/doc/source/data_summit_proposal.rst +++ b/doc/source/data_summit_proposal.rst @@ -18,9 +18,59 @@ behaviour:: # get the nth axis object (particularly if not named) >>> a.axes[n] - # get an "axes indexer" object for the indicated objects + # get an "axes indexer" object for the indicated objects. >>> a.axes('stocks', 'date') + +This indexer object returns something that is meant to be indexed with as many +dimensions as it was passed arguments, but that will, upon indexing, return +arrays with dimensions ordered just like the original underlying array. +The reason that I think that this is more natural is that the information that +you have is all available at the point where you are constructing the slicer, +you don't need to go rummaging around the code to find the correct order of the +axes from where the array was originally defined. It also potentially permits +you to use underlying arrays with different axis orders in the same code +unambiguously. + +There was also the thought that with numerical arguments that this would fill a +hole in the current numpy API for arbitrary re-ordering of axes in a view for +slicing (essentially a super-generalized transpose-ish sort of thing) + +I think that the result of the slicing operation retains the original ordering, +but the slices provided to a.axes()[] need to match the order of the arguments +to a.axes. + +So in other words, when you do + + +tslicer = a.axes('t') + +then + +tslicer['a':'z'] + +returns an array with axes x, y, z, t in that order, but sliced as +a[:,:,:,'a':'z'] + +When you have: + +xyslicer = a.axes('x', 'y') +yxslicer = a.axes('y', 'x') + +then I would expect to do: + +xyslicer[x1:x2, y1:y2] + +but + +yxslicer[y1:y2, x1:x2] + +However, these are two equivalent ways of writing a[x1:x2, y1:y2, :, :] + + + +:: + # actually do the slicing: equivalent to a[100, 0:2, :] >>> a.axes('stocks', 'date')['aapl':'goog',100] @@ -35,9 +85,11 @@ have to supply a keyword argument to the axes call:: >>> date_mapper = DictMapper(...) >>> a = DataArray( ..., axes=(('date', date_mapper), ... )) - # do mapped indexing + # do mapped indexing XXX - this might not have been the final decision >>> a.axes('stocks', 'date', mapped=True)['aapl':'goog', datetime.date(2011, 1, 1):datetime.date(2011, 5, 14)] + # For mapped indexing + The exact semantics of mapping are yet to be determined, but the thought is that there would be standard mappers to do things like interpolation, mapped integer indexing. diff --git a/doc/source/design_questions/data_array_overview.rst b/doc/source/design_questions/data_array_overview.rst index 532c190..b4315c9 100644 --- a/doc/source/design_questions/data_array_overview.rst +++ b/doc/source/design_questions/data_array_overview.rst @@ -1,6 +1,6 @@ -========= -DataArray -========= +============================== + DataArray: some design notes +============================== A DataArray is a subclass of the basic Numpy ndarray object that provides an explicit mechanism for attaching information to the *axes* of the underlying @@ -14,7 +14,7 @@ complement the rich semantics that numpy has for the *contents* of an array, encapsulated its dtype machinery for structured/record arrays. Arrays with named / labeled axes -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +================================ ndarrays extended to have an explicit "hypercross" of axes, each with names (possibly defaulted). @@ -38,7 +38,7 @@ names (possibly defaulted). * axes may be transposed Arrays with named axes, whose named axes have ticks -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +=================================================== each named axis has tick labels @@ -59,11 +59,98 @@ each named axis has tick labels x.t_slice( *args ) --> same as above, but perform t_slice slicing on the enumerated axes +(my thoughts on) What Is The DataArray? +======================================= + +* 1st and foremost, **an ndarray**, in N dimensions, with any dtype +* has means to locate data more descriptively (IE, with custom names + for dimensions/axes, and custom names for indices along any axis) + +:: + + >>> darr = DataArray(np.random.randn(2,3,4), ('ex', 'why', 'zee')) + >>> darr.sum(axis='ex') + DataArray([[-0.39052695, -2.07493873, 1.19664474, 0.36681094], + [-1.04287781, 0.5767191 , -0.35425298, 1.10468356], + [ 0.08331866, -0.36532857, 0.12905265, -1.94559672]]) + ('why', 'zee') + >>> for subarr in darr.axis.why: + ... print subarr.shape, subarr.labels + ... + (2, 4) ('ex', 'zee') + (2, 4) ('ex', 'zee') + (2, 4) ('ex', 'zee') + +* An axis "label" can always stand in for an axis number; an index + "tick" can (in some TBD sense) stand in for an integer index +* if anything is **more restrictive** in operations, for example + +:: + + >>> ndarr_ones = np.ones((10,10,10)) + >>> ndarr_twos = np.ones((10,10,10))*2 + >>> ndarr_3s = ndarr_ones + ndarr_twos # OK! + >>> darr_abc = DataArray(ndarr_ones, ('a', 'b', 'c')) + >>> darr_bac = DataArray(ndarr_twos, ('b', 'a', 'c')) + >>> darr_wtf = darr_abc + darr_bac # BAD! frames are rotated + +(and my very own thoughts on) What The DataArray Is Not +======================================================= + +Unions And Intersections +------------------------ + +DataArray may broadcast with certain union rules for adapting +metadata, but it does not do any data union/intersection rule for +operations. For example, the result of adding an array with axes ('a', 'c') with an +array with axis 'c' takes on information from the "superset" of +axes. This is analogous to ndarray taking on shape information from +the superset of shapes. + +:: + + >>> darr_abc[:,0,:] + DataArray([[ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.], + ... + [ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]]) + ('a', 'c') + >>> darr_bac[0,0] + DataArray([ 2., 2., 2., 2., 2., 2., 2., 2., 2., 2.]) + ('c',) + >>> darr_abc[:,0,:] + darr_bac[0,0] + DataArray([[ 3., 3., 3., 3., 3., 3., 3., 3., 3., 3.], + ... + [ 3., 3., 3., 3., 3., 3., 3., 3., 3., 3.]]) + ('a', 'c') + +But it will not fill or trim any dimension to fit the shape of a +fellow operand's array (it seems this violation is simply caught at the C-level of an ndarray):: + + >>> darr_abc[:,0,:] + darr_bac[0,0,:5] + ------------------------------------------------------------ + Traceback (most recent call last): + File "", line 1, in + ValueError: shape mismatch: objects cannot be broadcast to a single shape + +For me, this looks like the **domain of utility functions** (or +possibly utility methods that yield new DataArrays). + +Namespace +--------- + +It would be good practice to keep all the dynamically generated +DataArray attributes (eg, Axis labels) removed from the top-level +array attribute list. This is what we currently have as "axis". + +It might(?) be a good idea to put all future special purpose methods +under that object too. + + Lessons Learned -^^^^^^^^^^^^^^^ +=============== "Smart" Indexing -**************** +---------------- The smart indexing implemented by Larry is very full featured. I believe the design of using lists to separating labels from integers in mixed indexing is a @@ -72,7 +159,7 @@ confusion created by mixed indexing and is a good argument for discouraging/not allowing it. "Smart" Arithmetic -****************** +------------------ * Larry makes attempts to align its arrays when performing arithmetic, so as to operate on identical coordinates. @@ -80,13 +167,13 @@ allowing it. * It does not broadcast Ideas -^^^^^ +===== Axis Slicing -************ +------------ Use Case: chained axis slicing ------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ slicing on an axis returns a new DataArray:: diff --git a/doc/source/design_questions/index.rst b/doc/source/design_questions/index.rst index 9928daa..43d25de 100644 --- a/doc/source/design_questions/index.rst +++ b/doc/source/design_questions/index.rst @@ -8,16 +8,8 @@ Contents: :maxdepth: 1 data_array_overview.rst - larry_overview.rst - pandas_overview.rst issues.rst -License Info -============ - -Bits of documentation were cut-and-paste'd from Larry and Pandas - -:doc:`license_info` Indices and tables ================== diff --git a/doc/source/design_questions/issues.rst b/doc/source/design_questions/issues.rst index 52db3d1..9baa673 100644 --- a/doc/source/design_questions/issues.rst +++ b/doc/source/design_questions/issues.rst @@ -1,82 +1,82 @@ -====== -Issues -====== +======== + Issues +======== Questions and issues about the datarray prototype. .. contents:: -Ticks -===== +Labels +====== -Ticks are a relatively new addition to datarrays. The labels of a datarrays -identify the axes of the array. The ticks of a datarray identify the elements -along an axis. Both labels and ticks are optional. +Labels are a relatively new addition to datarrays. The labels of a datarrays +identify the axes of the array. The labels of a datarray identify the elements +along an axis. Both labels and labels are optional. -Axis._tick_dict is not updated when ticks are changed -""""""""""""""""""""""""""""""""""""""""""""""""""""" +Axis._label_dict is not updated when labels are changed +""""""""""""""""""""""""""""""""""""""""""""""""""""""" Example:: >> dar = DataArray([1, 2], [('time', ['A', 'B'])]) - >> dar.axis.time._tick_dict + >> dar.axis.time._label_dict {'A': 0, 'B': 1} - >> dar.axis.time.ticks[0] = 'X' - >> dar.axis.time.ticks + >> dar.axis.time.labels[0] = 'X' + >> dar.axis.time.labels ['X', 'B'] - >> dar.axis.time._tick_dict + >> dar.axis.time._label_dict {'A': 0, 'B': 1} Possible solutions: -#. Don't allow ticks to be changed -#. Only allow ticks to be changed through a method that also updates _tick_dict -#. Don't store _tick_dict, create on the fly as needed +#. Don't allow labels to be changed +#. Only allow labels to be changed through a method that also updates _label_dict +#. Don't store _label_dict, create on the fly as needed -pandas, I believe, makes the ticks immutable (#1). larry allows the ticks to +pandas, I believe, makes the labels immutable (#1). larry allows the labels to be changed and calculates the mapping dict on the fly (#3). -Can I have ticks without labels? -"""""""""""""""""""""""""""""""" +Can I have labels without axis names? +""""""""""""""""""""""""""""""""""""" -I'd like to use ticks without labels. At the moment that is not possible:: +I'd like to use labels without names. At the moment that is not possible:: >>> DataArray([1, 2], [(None, ('a', 'b'))]) - ValueError: ticks only supported when Axis has a label + ValueError: labels only supported when Axis has a name Well, it is possible:: >>> dar = DataArray([1, 2], [('tmp', ('a', 'b'))]) - >>> dar.set_label(0, None) + >>> dar.set_name(0, None) >>> dar.axes - (Axis(label=None, index=0, ticks=('a', 'b')),) + (Axis(name=None, index=0, labels=('a', 'b')),) -Add a ticks input parameter? -"""""""""""""""""""""""""""" +Add a labels input parameter? +""""""""""""""""""""""""""""" -What do you think of adding a ``ticks`` parameter to DataArray? +What do you think of adding a ``labels`` parameter to DataArray? Current behavior:: >>> dar = DataArray([[1, 2], [3, 4]], (('row', ['A','B']), ('col', ['C', 'D']))) >>> dar.axes - (Axis(label='row', index=0, ticks=['A', 'B']), -  Axis(label='col', index=1, ticks=['C', 'D'])) + (Axis(name='row', index=0, labels=['A', 'B']), +  Axis(name='col', index=1, labels=['C', 'D'])) -Proposed ticks as separate input parameter:: +Proposed labels as separate input parameter:: - >>> DataArray([[1, 2], [3, 4]], labels=('row', 'col'), ticks=[['A', 'B'], ['C', 'D']]) + >>> DataArray([[1, 2], [3, 4]], names=('row', 'col'), labels=[['A', 'B'], ['C', 'D']]) I think this would make it easier for new users to construct a DataArray with -ticks just from looking at the DataArray signature. It would match the -signature of Axis. My use case is to use ticks only and not names axes (at +labels just from looking at the DataArray signature. It would match the +signature of Axis. My use case is to use labels only and not names axes (at first), so:: - >>> DataArray([[1, 2], [3, 4]], ticks=[['A', 'B'], ['C', 'D']]) + >>> DataArray([[1, 2], [3, 4]], labels=[['A', 'B'], ['C', 'D']]) instead of the current:: @@ -84,28 +84,28 @@ instead of the current:: It might also cause less typos (parentheses matching) at the command line. -Having separate labels and ticks input parameters would also leave the option -open to allow any hashable object, like a tuple, to be used as a label. -Currently tuples have a special meaning, the (labels, ticks) tuple. +Having separate names and labels input parameters would also leave the option +open to allow any hashable object, like a tuple, to be used as a name. +Currently tuples have a special meaning, the (names, labels) tuple. -Create Axis._tick_dict when needed? -""""""""""""""""""""""""""""""""""" +Create Axis._label_dict when needed? +"""""""""""""""""""""""""""""""""""" -How about creating Axis._tick_dict on the fly when needed (but not saving it)? +How about creating Axis._label_dict on the fly when needed (but not saving it)? **Pros** -- Faster datarray creation (it does look like you get _tick_dict for free - since you need to check that the ticks are unique anyway, but set() +- Faster datarray creation (it does look like you get _label_dict for free + since you need to check that the labels are unique anyway, but set() is faster) - Faster datarray copy - Use less memory - Easier to archive - Simplify Axis -- Prevent user from doing ``dar.axes[0]._tick_dict['a'] = 10`` +- Prevent user from doing ``dar.axes[0]._label_dict['a'] = 10`` - Catches (on calls to ``make_slice`` and ``keep``) user mischief like - dar.axes[0].ticks = ('a', 'a') -- No need to update Axis._tick_dict when user changes ticks + dar.axes[0].labels = ('a', 'a') +- No need to update Axis._label_dict when user changes labels **Cons** @@ -116,7 +116,7 @@ How about creating Axis._tick_dict on the fly when needed (but not saving it)? Axis, axes ========== -Datarrays were created from the need to label the axes of a numpy array. +Datarrays were created from the need to name the axes of a numpy array. datarray1 + datarrat2 = which axes? """"""""""""""""""""""""""""""""""" @@ -132,13 +132,13 @@ Make two datarrays:: >> dar12 = dar1 + dar2 >> dar12.axes - (Axis(label='time', index=0, ticks=['A1', 'B1']),) + (Axis(name='time', index=0, labels=['A1', 'B1']),) ``dar1`` on the right-hand side:: >> dar21 = dar2 + dar1 >> dar21.axes - (Axis(label='time', index=0, ticks=['A2', 'B2']),) + (Axis(name='time', index=0, labels=['A2', 'B2']),) So a binary operation returns the axes from the left-hand side? No. Seems the left most non-None axes are used:: @@ -146,7 +146,7 @@ left most non-None axes are used:: >> dar3 = DataArray([1, 2]) >> dar31 = dar3 + dar1 >> dar31.axes - (Axis(label='time', index=0, ticks=['A1', 'B1']),) + (Axis(name='time', index=0, labels=['A1', 'B1']),) So binary operation may returns parts of both axes:: @@ -155,8 +155,8 @@ So binary operation may returns parts of both axes:: >> dar12 = dar1 + dar2 >> dar12.axes - (Axis(label='row', index=0, ticks=['a', 'b']), - Axis(label='col', index=1, ticks=['A', 'B'])) + (Axis(name='row', index=0, labels=['a', 'b']), + Axis(name='col', index=1, labels=['A', 'B'])) Is that the intended behavior? @@ -208,17 +208,17 @@ DataArray.__getitem__ this:: names = [a.name for a in self.axes] # If an Axis gets sliced out entirely, then any following - # unlabeled Axis in the array will spontaneously change name. + # unnamed Axis in the array will spontaneously change name. # So anticipate the name change here. reduction = 0 adjustments = [] for k in key: adjustments.append(reduction) if not isinstance(k, slice): - # reduce the idx # on the remaining default labels + # reduce the idx # on the remaining default names reduction -= 1 - names = [n if a.label else '_%d'%(a.index+r) + names = [n if a.name else '_%d'%(a.index+r) for n, a, r in zip(names, self.axes, adjustments)] for slice_or_int, name in zip(key, names): @@ -228,8 +228,8 @@ DataArray.__getitem__ this:: self.shape = old_shape _set_axes(self, old_axes) -could be replaces with -:: +could be replaced with:: + if isinstance(key, tuple): self.axes = self.axes[key] @@ -242,17 +242,17 @@ Why not make DataArray.axes a list instead of a tuple? Then user can replace an axis from one datarray to another, can pop an Axis, etc. -Can axis labels be anything besides None or str? -"""""""""""""""""""""""""""""""""""""""""""""""" +Can axis names be anything besides None or str? +""""""""""""""""""""""""""""""""""""""""""""""" -from http://projects.scipy.org/numpy/wiki/NdarrayWithNamedAxes: "Axis labels +from http://projects.scipy.org/numpy/wiki/NdarrayWithNamedAxes: "Axis names (the name of a dimension) must be valid Python identifiers." I don't know what that means. -It would be nice if axis labels could be anything hashable like str, +It would be nice if axis names could be anything hashable like str, datetime.date(), int, tuple. -But labels must be strings to do indexing like this:: +But names must be strings to do indexing like this:: >>> dar = DataArray([[1, 2], [3, 4]], (('row', ['A','B']), ('col', ['C', 'D']))) >>> dar.axis.row['A'] @@ -294,8 +294,8 @@ Time the creation of a datarray:: >> from datarray import DataArray >> import datarray - >> labels = [('row', idx1), ('col', idx2)] - >> timeit datarray.DataArray(arr, labels) + >> names = [('row', idx1), ('col', idx2)] + >> timeit datarray.DataArray(arr, names) 1000 loops, best of 3: 160 us per loop Time the creation of a pandas DataMatrix. A DataMatrix it is also a subclass @@ -310,10 +310,10 @@ larry is not a subclass of numpy's ndarray, I think that is one reason it is faster to create:: >> import la - >> label = [idx1, idx2] - >> timeit la.larry(arr, label) + >> name = [idx1, idx2] + >> timeit la.larry(arr, name) 100000 loops, best of 3: 13.5 us per loop - >> timeit la.larry(arr, label, integrity=False) + >> timeit la.larry(arr, name, integrity=False) 1000000 loops, best of 3: 1.25 us per loop Also both datarray and DataMatrix make a mapping dictionary when the data @@ -326,12 +326,12 @@ simple as ``dar1 + dar2`` creates a datarray. Direct access to array? """"""""""""""""""""""" -Labels and ticks add overhead. Sometimes, after aligning my datarrays, I would +Names and labels add overhead. Sometimes, after aligning my datarrays, I would like to work directly with the numpy arrays. Is there a way to do that with datarrays? -For example, with a labeled array, `larry `_, -the underlying numpy array is always accessible as the attribute ``x``:: +For example, with a named array, larry_, the underlying numpy array is always +accessible as the attribute ``x``:: >>> import la >>> lar = la.larry([1, 2, 3]) @@ -339,6 +339,8 @@ the underlying numpy array is always accessible as the attribute ``x``:: array([1, 2, 3]) >>> lar.x = myfunc(lar.x) +.. _larry: http://github.com/kwgoodman/la + This might be one solution (base):: >> from datarray import DataArray @@ -371,27 +373,26 @@ Support for alignment? """""""""""""""""""""" Will datarray provide any support for those who want binary operations between -two datarrays to join labels or ticks using various join methods? +two datarrays to join names or labels using various join methods? -`A use case `_ from -`larry `_: +`A use case `_ from larry_: By default, binary operations between two larrys use an inner join of the -labels (the intersection of the labels):: +names (the intersection of the names):: >>> lar1 = larry([1, 2]) >>> lar2 = larry([1, 2, 3]) >>> lar1 + lar2 - label_0 + name_0 0 1 x array([2, 4]) -The sum of two larrys using an outer join (union of the labels):: +The sum of two larrys using an outer join (union of the names):: >>> la.add(lar1, lar2, join='outer') - label_0 + name_0 0 1 2 @@ -407,13 +408,13 @@ How can datarrays be aligned? """"""""""""""""""""""""""""" What's an outer join (or inner, left, right) along an axis of two datarrays if -one datarray has ticks and the other doesn't? +one datarray has labels and the other doesn't? Background: It is often useful to align two datarrays before performing binary operations -such as +, -, *, /. Two datarrays are aligned when both datarrays have the same -labels and ticks along all axes. +such as +, -, \*, /. Two datarrays are aligned when both datarrays have the same +names and labels along all axes. Aligned:: @@ -424,16 +425,16 @@ Aligned:: Unaligned:: - >> dar1 = DataArray([1, 2], labels=("time",)) - >> dar2 = DataArray([3, 4], labels=("distance",)) + >> dar1 = DataArray([1, 2], names=("time",)) + >> dar2 = DataArray([3, 4], names=("distance",)) >> dar1.axes == dar2.axes False Unaligned but returns aligned since Axis.__eq__ doesn't (yet) check for -equality of ticks:: +equality of labels:: - >> dar1 = DataArray([1, 2], labels=[("time", ['A', 'B'])]) - >> dar2 = DataArray([1, 2], labels=[("time", ['A', 'different'])]) + >> dar1 = DataArray([1, 2], names=[("time", ['A', 'B'])]) + >> dar2 = DataArray([1, 2], names=[("time", ['A', 'different'])]) >> dar1.axes == dar2.axes True @@ -441,23 +442,24 @@ Let's say we make an add function with user control of the join method:: >>> add(dar1, dar2, join='outer') -Since datarray allows empty axis labels (None) and ticks (None), what does an -outer join mean if dar1 has ticks but dar2 doesn't:: +Since datarray allows empty axis names (None) and labels (None), what does an +outer join mean if dar1 has labels but dar2 doesn't:: - >>> dar1 = DataArray([1, 2], labels=[("time", ['A', 'B'])]) - >>> dar2 = DataArray([1, 2], labels=[("time",)]) + >>> dar1 = DataArray([1, 2], names=[("time", ['A', 'B'])]) + >>> dar2 = DataArray([1, 2], names=[("time",)]) What would the following return? :: + >>> add(dar1, dar2, join='outer') -larry requires all axes to have ticks, if none are given then the ticks default +larry requires all axes to have labels, if none are given then the labels default to range(n). datarray.reshape """""""""""""""" -Reshape operations scramble labels and ticks. Some numpy functions and +Reshape operations scramble names and labels. Some numpy functions and array methods use reshape. Should reshape convert a datarray to an array? Looks like datarray will need unit tests for every numpy function and array @@ -481,45 +483,50 @@ as numpy arrays? A datarray can be broken down to the following components: - data (store directly as numpy array) -- labels (store as object array since it contains None and str and covert +- names (store as object array since it contains None and str and covert back on load?) -- ticks (each axis stored as numpy array with axis number stored as HDF5 - Dataset attribute, but then ticks along any one axis must be homogeneous +- labels (each axis stored as numpy array with axis number stored as HDF5 + Dataset attribute, but then labels along any one axis must be homogeneous in dtype) -- Dictionary of tick index mappings (ignore, recreate on load) +- Dictionary of label index mappings (ignore, recreate on load) (I need to write a function that saves an Axis object to HDF5.) -If I don't save Axis._tick_dict, would I have to worry about a user changing +If I don't save Axis._label_dict, would I have to worry about a user changing the mapping? :: + >>> dar.axes[0] - Axis(label='one', index=0, ticks=('a', 'b')) - >>> dar.axes[0]._tick_dict + Axis(name='one', index=0, labels=('a', 'b')) + >>> dar.axes[0]._label_dict {'a': 0, 'b': 1} - >>> dar.axes[0]._tick_dict['a'] = 10 - >>> dar.axes[0]._tick_dict + >>> dar.axes[0]._label_dict['a'] = 10 + >>> dar.axes[0]._label_dict {'a': 10, 'b': 1} -Can labels and ticks be changed? +Can names and labels be changed? """""""""""""""""""""""""""""""" -Ticks can be changed:: +Labels can be changed:: >>> dar = DataArray([1, 2], [('row', ['A','B'])]) >>> dar.axes - (Axis(label='row', index=0, ticks=['A', 'B']),) - >>> dar.axes[0].ticks[0] = 'CHANGED' + (Axis(name='row', index=0, labels=['A', 'B']),) + >>> dar.axes[0].labels[0] = 'CHANGED' >>> dar.axes - (Axis(label='row', index=0, ticks=['CHANGED', 'B']),) + (Axis(name='row', index=0, labels=['CHANGED', 'B']),) -But Axis._tick_dict is not updated when user changes ticks. +But Axis._label_dict is not updated when user changes labels. -And so can labels:: +And so can names:: - >>> dar.set_label(0, 'new label') + >>> dar.set_name(0, 'new name') >>> dar DataArray([1, 2]) - ('new label',) + ('new name',) + +Fancy Indexing +"""""""""""""" +It's not implemented at all yet. \ No newline at end of file diff --git a/doc/source/design_questions/license_info.rst b/doc/source/design_questions/license_info.rst deleted file mode 100644 index 98b8913..0000000 --- a/doc/source/design_questions/license_info.rst +++ /dev/null @@ -1,3 +0,0 @@ -:doc:`Larry license ` - -:doc:`Pandas license ` diff --git a/doc/source/design_questions/licenses/la_license.rst b/doc/source/design_questions/licenses/la_license.rst deleted file mode 100644 index b60547f..0000000 --- a/doc/source/design_questions/licenses/la_license.rst +++ /dev/null @@ -1,72 +0,0 @@ -:: - - larry is distributed under a BSD license. Parts of Scipy and numpydoc, which - both have BSD licenses, are included in larry. - - --------------------------------------------------------------------------- - la license: - - Copyright (c) 2008, 2009, 2010, Archipel Asset Management AB. - All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions are met: - - * Redistributions of source code must retain the above copyright notice, - this list of conditions and the following disclaimer. - - * Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in the - documentation and/or other materials provided with the distribution. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" - AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE - ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE - LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR - CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF - SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS - INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN - CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) - ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE - POSSIBILITY OF SUCH DAMAGE. - - --------------------------------------------------------------------------- - SciPy license: - - Copyright (c) 2001, 2002 Enthought, Inc. - All rights reserved. - - Copyright (c) 2003-2009 SciPy Developers. - All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions are met: - - a. Redistributions of source code must retain the above copyright notice, - this list of conditions and the following disclaimer. - b. Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in the - documentation and/or other materials provided with the distribution. - c. Neither the name of the Enthought nor the names of its contributors - may be used to endorse or promote products derived from this software - without specific prior written permission. - - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" - AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE - ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR - ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL - DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR - SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER - CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT - LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY - OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH - DAMAGE. - - --------------------------------------------------------------------------- - numpydoc license: - - The numpydoc license is in la/doc/sphinxext/LICENSE.txt - diff --git a/doc/source/index.rst b/doc/source/index.rst index d212b31..93c8110 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -18,9 +18,12 @@ Contents: .. toctree:: :maxdepth: 1 - design_questions/index.rst - basic_data_array.rst - ndarray_methods.rst + design_questions/index + basic_data_array + ndarray_methods + printing + data_summit_proposal + other_projects/index license Indices and tables diff --git a/doc/source/license.rst b/doc/source/license.rst index 724ac81..a922a5e 100644 --- a/doc/source/license.rst +++ b/doc/source/license.rst @@ -1 +1,17 @@ .. include:: ../../datarray/LICENSE + +Other Licenses +-------------- + +Throughout the writing of datarray we have relied heavily on Pandas, as well as +using numpydoc. These are the relevant licenses: + +:doc:`Pandas ` + +:doc:`Numpydoc ` + +.. toctree:: + :hidden: + + licenses/numpydoc_license + licenses/pandas_license diff --git a/doc/source/licenses/numpydoc_license.rst b/doc/source/licenses/numpydoc_license.rst new file mode 100644 index 0000000..e0aeb9a --- /dev/null +++ b/doc/source/licenses/numpydoc_license.rst @@ -0,0 +1,102 @@ +================== + Numpydoc License +================== + +The files: + +- numpydoc.py +- autosummary.py +- autosummary_generate.py +- docscrape.py +- docscrape_sphinx.py +- phantom_import.py + +have the following license:: + + Copyright (C) 2008 Stefan van der Walt , Pauli Virtanen + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions are + met: + + 1. Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + 2. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in + the documentation and/or other materials provided with the + distribution. + + THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, + INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR + SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING + IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + POSSIBILITY OF SUCH DAMAGE. + + ------------------------------------------------------------------------------- + The files + - compiler_unparse.py + - comment_eater.py + - traitsdoc.py + have the following license: + + This software is OSI Certified Open Source Software. + OSI Certified is a certification mark of the Open Source Initiative. + + Copyright (c) 2006, Enthought, Inc. + All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions are met: + + * Redistributions of source code must retain the above copyright notice, this + list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright notice, + this list of conditions and the following disclaimer in the documentation + and/or other materials provided with the distribution. + * Neither the name of Enthought, Inc. nor the names of its contributors may + be used to endorse or promote products derived from this software without + specific prior written permission. + + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND + ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR + ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + + + ------------------------------------------------------------------------------- + The files + - only_directives.py + - plot_directive.py + originate from Matplotlib (http://matplotlib.sf.net/) which has + the following license: + + Copyright (c) 2002-2008 John D. Hunter; All Rights Reserved. + + 1. This LICENSE AGREEMENT is between John D. Hunter (“JDH”), and the Individual or Organization (“Licensee”) accessing and otherwise using matplotlib software in source or binary form and its associated documentation. + + 2. Subject to the terms and conditions of this License Agreement, JDH hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use matplotlib 0.98.3 alone or in any derivative version, provided, however, that JDH’s License Agreement and JDH’s notice of copyright, i.e., “Copyright (c) 2002-2008 John D. Hunter; All Rights Reserved” are retained in matplotlib 0.98.3 alone or in any derivative version prepared by Licensee. + + 3. In the event Licensee prepares a derivative work that is based on or incorporates matplotlib 0.98.3 or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to matplotlib 0.98.3. + + 4. JDH is making matplotlib 0.98.3 available to Licensee on an “AS IS” basis. JDH MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, JDH MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF MATPLOTLIB 0.98.3 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. + + 5. JDH SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF MATPLOTLIB 0.98.3 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING MATPLOTLIB 0.98.3, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. + + 6. This License Agreement will automatically terminate upon a material breach of its terms and conditions. + + 7. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between JDH and Licensee. This License Agreement does not grant permission to use JDH trademarks or trade name in a trademark sense to endorse or promote products or services of Licensee, or any third party. + + 8. By copying, installing or otherwise using matplotlib 0.98.3, Licensee agrees to be bound by the terms and conditions of this License Agreement. + diff --git a/doc/source/design_questions/licenses/pandas_license.rst b/doc/source/licenses/pandas_license.rst old mode 100755 new mode 100644 similarity index 96% rename from doc/source/design_questions/licenses/pandas_license.rst rename to doc/source/licenses/pandas_license.rst index a7eae64..9cd3fa0 --- a/doc/source/design_questions/licenses/pandas_license.rst +++ b/doc/source/licenses/pandas_license.rst @@ -1,3 +1,7 @@ +==================== + The Pandas License +==================== + :: Copyright (c) 2008-2009 AQR Capital Management, LLC diff --git a/doc/source/other_projects/index.rst b/doc/source/other_projects/index.rst new file mode 100644 index 0000000..30e0260 --- /dev/null +++ b/doc/source/other_projects/index.rst @@ -0,0 +1,15 @@ +================ + Other projects +================ + +The following are closely related projects that have heavily influenced the +design of datarray. Both Larry and Pandas target slightly higher level +problems than datarray, but the intended outcome is for datarray to provide +a base object on which projects like these can more easily build their +domain-specific tools with a common foundation. + +.. toctree:: + :maxdepth: 1 + + larry_overview.rst + pandas_overview.rst diff --git a/doc/source/design_questions/larry_overview.rst b/doc/source/other_projects/larry_overview.rst similarity index 100% rename from doc/source/design_questions/larry_overview.rst rename to doc/source/other_projects/larry_overview.rst diff --git a/doc/source/design_questions/pandas_overview.rst b/doc/source/other_projects/pandas_overview.rst similarity index 100% rename from doc/source/design_questions/pandas_overview.rst rename to doc/source/other_projects/pandas_overview.rst diff --git a/doc/source/printing.rst b/doc/source/printing.rst index dc82a3c..a20cc42 100644 --- a/doc/source/printing.rst +++ b/doc/source/printing.rst @@ -19,7 +19,7 @@ the code in numpy.core.arrayprint is - largely untouched for the last 13 years! Its output can be aesthetically suboptimal in some cases. When printing large -arrays of floats, for example, it will wrap every line like this: +arrays of floats, for example, it will wrap every line like this:: [[ 0.00000000e+00 1.00000000e-04 2.00000000e-04 ..., 4.70000000e-03 4.80000000e-03 4.90000000e-03] @@ -85,4 +85,3 @@ beginning of the matrix, dots, and a few of these from the end of the matrix. Then put all those back into the grid-maker. If there are more than 30 or so dimensions, we are sad. - diff --git a/doc/sphinxext/LICENSE.txt b/doc/sphinxext/LICENSE.txt deleted file mode 100644 index e00efc3..0000000 --- a/doc/sphinxext/LICENSE.txt +++ /dev/null @@ -1,97 +0,0 @@ -------------------------------------------------------------------------------- - The files - - numpydoc.py - - autosummary.py - - autosummary_generate.py - - docscrape.py - - docscrape_sphinx.py - - phantom_import.py - have the following license: - -Copyright (C) 2008 Stefan van der Walt , Pauli Virtanen - -Redistribution and use in source and binary forms, with or without -modification, are permitted provided that the following conditions are -met: - - 1. Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - 2. Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - -THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR -IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED -WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE -DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, -INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES -(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR -SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, -STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING -IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE -POSSIBILITY OF SUCH DAMAGE. - -------------------------------------------------------------------------------- - The files - - compiler_unparse.py - - comment_eater.py - - traitsdoc.py - have the following license: - -This software is OSI Certified Open Source Software. -OSI Certified is a certification mark of the Open Source Initiative. - -Copyright (c) 2006, Enthought, Inc. -All rights reserved. - -Redistribution and use in source and binary forms, with or without -modification, are permitted provided that the following conditions are met: - - * Redistributions of source code must retain the above copyright notice, this - list of conditions and the following disclaimer. - * Redistributions in binary form must reproduce the above copyright notice, - this list of conditions and the following disclaimer in the documentation - and/or other materials provided with the distribution. - * Neither the name of Enthought, Inc. nor the names of its contributors may - be used to endorse or promote products derived from this software without - specific prior written permission. - -THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND -ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED -WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE -DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR -ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES -(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; -LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON -ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS -SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - - -------------------------------------------------------------------------------- - The files - - only_directives.py - - plot_directive.py - originate from Matplotlib (http://matplotlib.sf.net/) which has - the following license: - -Copyright (c) 2002-2008 John D. Hunter; All Rights Reserved. - -1. This LICENSE AGREEMENT is between John D. Hunter (“JDH”), and the Individual or Organization (“Licensee”) accessing and otherwise using matplotlib software in source or binary form and its associated documentation. - -2. Subject to the terms and conditions of this License Agreement, JDH hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use matplotlib 0.98.3 alone or in any derivative version, provided, however, that JDH’s License Agreement and JDH’s notice of copyright, i.e., “Copyright (c) 2002-2008 John D. Hunter; All Rights Reserved” are retained in matplotlib 0.98.3 alone or in any derivative version prepared by Licensee. - -3. In the event Licensee prepares a derivative work that is based on or incorporates matplotlib 0.98.3 or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to matplotlib 0.98.3. - -4. JDH is making matplotlib 0.98.3 available to Licensee on an “AS IS” basis. JDH MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, JDH MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF MATPLOTLIB 0.98.3 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. - -5. JDH SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF MATPLOTLIB 0.98.3 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING MATPLOTLIB 0.98.3, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. - -6. This License Agreement will automatically terminate upon a material breach of its terms and conditions. - -7. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between JDH and Licensee. This License Agreement does not grant permission to use JDH trademarks or trade name in a trademark sense to endorse or promote products or services of Licensee, or any third party. - -8. By copying, installing or otherwise using matplotlib 0.98.3, Licensee agrees to be bound by the terms and conditions of this License Agreement. -