On 11/30/2011 6:09 AM, Giovanni Plantageneto wrote:
I find ConfigParser a bit low level, is there any function that
automatically reads everything from a file?
You could just use a dictionary for your params,
and import it from your configuration file.
If you insist on an ini format,
On 12/4/2011 1:43 AM, Charles R Harris wrote:
I don't think there are 5 active developers, let alone 11.
With hard work you might scrape together two or three.
Having 5 or 11 people making decisions for the two or
three actually doing the work isn't going to go over well.
Very true! But you
If I seed NumPy's random number generator, I get the
expected sequence. If I use the same seed for Python's
random number generator, I get a different sequence.
1. Why does the Python sequence differ from others?
2. Can I somehow put both MT's in a common state?
Thank you,
Alan Isaac
On Fri, Dec 30, 2011 at 15:13, Alan wrote:
If I seed NumPy's random number generator, I get the
expected sequence.
On 12/30/2011 10:36 AM, Robert Kern wrote:
What do you mean by expected? Where are these expectations coming
from? Other implementations of the Mersenne Twister?
Right.
On 1/31/2012 8:26 AM, Neal Becker wrote:
I was just bitten by this unexpected behavior:
In [24]: all ([i 0 for i in xrange (10)])
Out[24]: False
In [25]: all (i 0 for i in xrange (10))
Out[25]: True
Turns out:
In [31]: all is numpy.all
Out[31]: True
np.array([i 0 for i in xrange
On 1/31/2012 10:35 AM, Benjamin Root wrote:
A generator is an input that could be converted into an array.
def mygen():
i = 0
while True:
yield i
i += 1
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On 2/3/2012 5:16 AM, santhu kumar wrote:
x = nX3 vector.
mass = nX1 vector
inert = zeros((3,3))
for i in range(n):
ri = x[i,:].reshape(1,3)
inert = inert + mass[i,]*(sum(ri*ri)*eye(3) - dot(ri.T,ri))
This should buy you a bit.
xdot = (x*x).sum(axis=1)
for (massi,xi,xdoti)
On 2/3/2012 3:37 PM, josef.p...@gmail.com wrote:
res = - np.dot(x.T, mass*x)
res[np.arange(3), np.arange(3)] -= np.trace(res)
Nice!
Get some speed gain with slicing:
res = - np.dot(x.T, mass*x)
res.flat[slice(0,None,4)] -= np.trace(res)
Alan
___
On 2/14/2012 10:07 PM, Bruce Southey wrote:
The one thing that gets over looked here is that there is a huge
diversity of users with very different skill levels. But very few
people have an understanding of the core code. (In fact the other
thread about type-casting suggests that it is
On 2/15/2012 1:50 PM, Matthew Brett wrote:
I believe that leaving the governance informal and underspecified at
this stage would be a grave mistake, for everyone concerned.
To justify that concern, can you point to an
analogous case, where things went awry by not
formalizing the governance
On 2/15/2012 2:46 PM, Benjamin Root wrote:
I think it is only fair that the group occasionally pings this mailing-list
for important progress reports.
No offense intended, but that sounds like an unfunded mandate.
More useful would be an offer to liaison between the two.
Cheers,
Alan
On 2/15/2012 2:46 PM, Benjamin Root wrote:
The NA discussion is the perfect example where a governance structure would
help resolve disputes.
How? I'm not seeing it.
Who would have behaved differently and why?
Alan
___
NumPy-Discussion mailing
My analysis is fundamentally different than Matthew
and Benjamin's for a few reasons.
1. The problem has been miscast.
The economic interests of the developers *always*
has had an apparent conflict with the economic
interests of the users: users want developers to work more
on the
On 2/18/2012 10:20 AM, josef.p...@gmail.com wrote:
we need to streamline the code so the bunch of amateurs doesn't
understand what's going on and cannot effectively threaten a fork
anymore.
I don't mean to take today's peculiar post too seriously,
and your opening line undermines that. But
On 2/23/2012 7:20 PM, Travis Oliphant wrote:
https://www.surveymonkey.com/s/numpy_list_survey
After you complete the survey, I would really appreciate any feedback on
questions that could be improved, removed, or added.
I felt the survey was targeting business users rather than academic
On 2/25/2012 4:44 PM, James Bergstra wrote:
bincount([]) makes no sense,
I disagree:
http://permalink.gmane.org/gmane.comp.python.numeric.general/42041
but if a minlength argument is provided,
then the routine should succeed.
Definitely!
Alan Isaac
On 2/27/2012 10:10 AM, Paulo Jabardo wrote:
I have a few features that I believe would make text file easier for many
people. In some countries (most?) the decimal separator in real numbers is
not a point but a comma.
I think it would be very useful that the decimal separator be specified
On 2/27/2012 1:00 PM, Paulo Jabardo wrote:
First of all '.' isn't international notation
That is in fact a standard designation.
http://en.wikipedia.org/wiki/Decimal_mark#Influence_of_calculators_and_computers
Alan Isaac
___
NumPy-Discussion mailing
On 2/27/2012 2:28 PM, Pauli Virtanen wrote:
ISO specifies comma to be used in international standards
(ISO/IEC Directives, part 2 / 6.6.8.1):
http://isotc.iso.org/livelink/livelink?func=llobjId=10562502objAction=download
I do not think you are right.
I think that is a presentational
On 2/27/2012 2:47 PM, Matthew Brett wrote:
Maybe we can just agree it is an important option to have rather than
an unimportant one,
It depends on what you mean by option.
If you mean there should be conversion tools
from other formats to a specified supported
format, then I agree.
If you
http://docs.scipy.org/doc/numpy/reference/routines.matlib.html#module-numpy.matlib
promises a list of functions that does not appear (at the moment, anyway).
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On 4/25/2012 4:51 PM, Andreas H. wrote:
I would assume that most users see numpy
as infrastructure, they write their own code on top of it. As a normal
user of numpy, I wouldn't know where it would need improvement to suit
my needs because it already does all I need. (Okay, masked arrays are
On 6/8/2012 9:14 AM, Neal Becker wrote:
The fact that this proposed numpy behavior would not match python list
behavior
holds little weight for me.
It is not just Python behavior for lists.
It is the semantics for all sequence types.
Breaking this would be appalling.
Alan Isaac
On 7/12/2012 1:45 PM, Nathaniel Smith wrote:
I'd actually like to see out= as a kw-only arg.
That would be great.
Numpy 2.0?
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
I just noticed that 1.7 is scheduled to add a random.choice function.
I wonder if the best structure has been chosen. Specifically, it does
not provide for array flattening, and it does not provide for subarray
choice.
Back in 2006 (?) Robert Kern suggested something like the below
(forgive any
On 11/9/2012 12:21 PM, Nathaniel Smith wrote:
you might want to double-check that the
np.random.choice in 1.7 actually*does* give an error if the input
array is not 1-d
Any idea where I can look at the code?
I browsed github after failing to find
a productive search string, but failed
to
On 11/12/2012 8:59 AM, Sebastian Berg wrote:
https://github.com/numpy/numpy/blob/master/numpy/random/mtrand/mtrand.pyx#L919
Sounds like it should be pretty simple to add axis=None which would
change the current behavior very little, it would stop give an error
anymore for none 1-d arrays
On 11/12/2012 10:00 AM, Nathaniel Smith wrote:
I don't really have an opinion on whether those
things should be supported, or what the right API should be; I haven't
really thought about it. Maybe others on the list have opinions. I was
just saying that we have plenty of time to decide about
In a comment on the issue https://github.com/numpy/numpy/issues/2724 Sebastian
notes:
it could also be reasonable to have size=None as default and have it return a
scalar/the given axes removed in that case. That would be a real change
in functionality unfortunately, but it would make sense for
On 11/12/2012 12:16 PM, Sebastian Berg wrote:
So instead of taking a sequence of length 1, take an element as default.
Sebastien has proposed that np.random.choice return
a single *element* by default, not a 1d array of length 1.
He proposes to associate this with a default value of
On 11/12/2012 5:46 PM, Nathaniel Smith wrote:
Want to make a pull request?
Well, I'd be happy to help Sebastien to change the
code, but I'm not a git user.
And I'd have some questions. E.g., with `size=None`,
couldn't we just call Python's random.choice? And for
sampling without replacement,
On 11/12/2012 8:18 PM, Sebastian Berg wrote:
I have created a pull request
This is still a bit different than I thought you intended.
With `size=None` we don't get an element,
but rather a 0d array.
I thought the idea was to return an element in this case?
Alan
On 1/8/2013 1:48 PM, Olivier Delalleau wrote:
As I mentioned in another post, I also agree that it would make things
simpler and safer to just yield the same result as if we were using a
one-element array.
Yes!
Anything else is going to drive people insane,
especially new users.
Alan Isaac
I'm just a Python+NumPy user and not a CS type.
May I ask a naive question on this thread?
Given the work that has (as I understand it) gone into
making NumPy usable as a C library, why is the discussion not
going in a direction like the following:
What changes to the NumPy code base would be
On 1/9/2013 9:58 AM, Nathaniel Smith wrote:
I don't think most happy current numpy users are wishing they
could switch to writing Lisp on the JVM or vice-versa, so I don't
think it's surprising that no-one's jumped up to do this work.
Sure. I'm trying to look at this more from the Clojure
On Sun, Jan 13, 2013 at 11:24 PM, Robert Kern robert.k...@gmail.com wrote:
One alternative that does not expand the API with two-liners is to let
the ndarray.fill() method return self:
a = np.empty(...).fill(20.0)
On 1/13/2013 6:39 PM, Nathaniel Smith wrote:
This violates the
Just changing the subject line so a good suggestion
does not get lost ...
Alan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thanks Pierre for noting that np.tile already
provides a chunk of this functionality:
a = np.tile(5,(1,2,3))
a
array([[[5, 5, 5],
[5, 5, 5]]])
np.tile(1,a.shape)
array([[[1, 1, 1],
[1, 1, 1]]])
I had not realized a scalar first argument was possible.
Alan Isaac
Is it really better to have `permute` and `permuted`
than to add a keyword? (Note that these are actually
still ambiguous, except by convention.)
Btw, two separate issues seem to be running side by side.
i. should in-place operations return their result?
ii. how can we signal that an operation
x=[1,2,3,4,5,6]
ind=[1,3,9,3,4,1]
f=np.zeros(10)
np.bincount(ind,x)
hth,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
I'm hoping this discussion will return to the drawing the line question.
http://stackoverflow.com/questions/8108688/in-python-when-should-i-use-a-function-instead-of-a-method
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On 2/26/2013 1:11 PM, josef.p...@gmail.com wrote:
Alan was in favor of the dot method
I still really like this, and it probably violates
any simple rule for drawing the line.
Nevertheless it would be nice to have some
principle(s) other than the squeaky wheel principle
for thinking about such
On 3/1/2013 9:32 AM, Henry Gomersall wrote:
there should be an equivalent for floats that
unambiguously returns a range for the half open interval
If I've understood you:
start + stepsize*np.arange(nsteps)
fwiw,
Alan Isaac
___
NumPy-Discussion
One motivation of this thread was that
adding a step parameter to linspace might make
things easier for beginners.
I claim this thread has put the lie to that,
starting with the initial post. So what is the
persuasive case for the change?
Imo, the current situation is good:
use arange if you
Under what conditions should I expect fminbound
to call the supplied function with argument values
substantially outside the user-provided bounds?
Thanks,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On 3/15/2013 9:21 AM, Dmitrey wrote:
Temporary walkaround for a serious bug in FuncDesigner automatic
differentiation kernel due to a bug in some versions of Python or NumPy,
Are the suspected bugs documented somewhere?
Alan
PS The word 'banausic' is very rare in English.
Perhaps you meant
On 3/15/2013 3:34 PM, Dmitrey wrote:
the suspected bugs are not documented yet
I'm going to guess that the state of the F_i changes
when you use them as keys (i.e., when you call __le__.
It is very hard to imagine that this is a Python or NumPy bug.
Cheers,
Alan
On 4/3/2013 2:44 PM, huangkan...@gmail.com wrote:
I suggest add function dot to matrix
import numpy as np; x = np.arange(5); I = np.asmatrix(np.identity(5));
I.dot(x)
matrix([[ 0., 1., 2., 3., 4.]])
Alan Isaac
___
NumPy-Discussion mailing
On 4/10/2013 3:31 AM, Robert Kern wrote:
You cannot use objects that do not have a valid __eq__() (as in,
returns boolean True if and only if they are to be considered
equivalent for the purpose of dictionary lookup, otherwise returns
False) as dictionary keys. Your oofun object still violates
On 6/7/2013 12:30 PM, Will Lee wrote:
Can somebody tell me why these operations are not the same in numpy?
http://docs.python.org/2/reference/datamodel.html#object.__rmul__
hth,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
Le 12/06/2013 16:18, Nathaniel Smith a écrit :
Now imagine a new version of this page, if we add 'filled'. There will
be a list at the top with functions named:
empty
filled
ones
zeros
It's immediately obvious what all of these things do, and how they
differ from each other,
On 6/13/2013 4:36 PM, Benjamin Root wrote:
np.values() might be a decent alternative.
This could then reasonably support broadcasting
from the shape of the input to the shape of
the array.
Alan Isaac
___
NumPy-Discussion mailing list
On 6/14/2013 9:27 AM, Aldcroft, Thomas wrote:
If I just saw np.values(..) in some code I would never guess what it is doing
from the name
That suggests np.fromvalues.
But more important than the name I think
is allowing broadcasting of the values,
based on NumPy's broadcasting rules.
On 2013/06/14 5:15 AM, Alan G Isaac wrote:
But more important than the name I think
is allowing broadcasting of the values,
based on NumPy's broadcasting rules.
Broadcasting a scalar is then a special case,
even if it is the case that has dominated this thread.
On 6/14/2013 1:18 PM, Eric
On 6/29/2013 3:00 PM, Nathaniel wrote:
any objections to np.full?
Still curious:
why isn't ``tile`` the right name?
(It already exists.)
import numpy as np
np.tile(3.0, (2,3))
array([[ 3., 3., 3.],
[ 3., 3., 3.]])
If someone explained this, sorry to
have missed it.
Alan
On 6/29/2013 3:00 PM, Nathaniel wrote:
any objections to np.full?
On Sat, Jun 29, 2013 at 9:55 PM, Alan G Isaac wrote:
Still curious:
why isn't ``tile`` the right name?
(It already exists.)
import numpy as np
np.tile(3.0, (2,3))
array([[ 3., 3., 3.],
[ 3., 3., 3
and I don't see the problem with ``tile_like``.
On 6/29/2013 6:15 PM, Robert Kern wrote:
It makes no sense except in the scalar case.
I would think it makes sense in every case that
can be normally broadcast to the shape of the
paradigm array.
Anyway, I drop the suggestion.
Cheers,
Alan
On 7/5/2013 2:50 PM, Alan G Isaac wrote:
I see that CLARTG is here:
https://github.com/scipy/scipy/blob/master/scipy/sparse/linalg/eigen/arpack/ARPACK/SRC/sstqrb.f
But is there a Python interface in SciPy?
(Or any other SciPy access to Givens rotation?)
Sorry, that was SLARTG, whereas
With numpy arrays, I miss being able to spell a.conj().T as a.H,
as one can with numpy matrices.
Is adding this attribute to arrays ever under consideration?
Thanks,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
The docs for numpy.sign at
http://docs.scipy.org/doc/numpy/reference/generated/numpy.sign.html
do not indicate how complex numbers are handled. Currently, np.sign
appears to return the sign of the real part as a complex value.
Was this an explicit choice? Was x/abs(x) considered (for non-zero
On Sun, Jul 7, 2013 at 9:28 AM, Alan G Isaac alan.is...@gmail.com
mailto:alan.is...@gmail.com wrote:
I miss being able to spell a.conj().T as a.H, as one can
with numpy matrices.
On 7/7/2013 4:49 PM, Charles R Harris wrote:
There was a long thread about this back around 1.1 or so,
long
On 7/13/2013 1:46 PM, Nathaniel Smith wrote:
Why not just write
def H(a):
return a.conj().T
in your local namespace?
First of all, I am sympathetic to being conservative
about the addition of attributes!
But the question about adding a.H about the possibility of improving
- speed
I'm floating this thought even though it is not fleshed out.
On occasion, I run into the following problem:
I have a rectangular array A to which I want to append
a (probably) one dimensional vector b to make [A|b].
Of course this can be done as np.hstack((x,b[:,None]))
(or obscurely
On 7/18/2013 1:03 PM, Robert Kern wrote:
np.column_stack([x, b]) does everything you need.
So it does.
It's not referenced from the hstack or concatenate documentation.
Thanks!
Alan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On 7/18/2013 1:03 PM, Robert Kern wrote:
np.column_stack([x, b]) does everything you need.
I am curious: why is column_stack in numpy/lib/shape_base.py
while hstack and vstack are in numpy/core/shape_base.py ?
Thanks,
Alan
___
NumPy-Discussion
On 7/22/2013 3:10 PM, Nathaniel Smith wrote:
Having .T but not .H is an example of this split.
Hate to do this but ...
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
How much is the split a rule or just a convention, and
On 7/23/2013 4:36 AM, Dag Sverre Seljebotn wrote:
I'm +1 on another name for a method that does a copy. Which can
eventually be made redundant with A.H.copy(), if somebody ever takes on
the work to make that happen...but at least I think the path to that
should be kept open.
If that is the
On 7/23/2013 9:09 AM, Pauli Virtanen wrote:
.flat which I think
is rarely used
Until ``diagonal`` completes its transition,
use of ``flat`` seems the best way to reset
the diagonal on an array. Am I wrong?
I use it that way all the time.
Alan Isaac
I'm trying to understand the state of this discussion.
I believe that propoents of adding a .H attribute have
primarily emphasized
- readability (and general ease of use)
- consistency with matrix and masked array
- forward looking (to a future when .H can be a view)
The opponents have primarily
On 7/23/2013 5:08 PM, Dag Sverre Seljebotn wrote:
I disagree with this being forward looking, as it explicitly creates a
situation where code will break if .H becomes a view
Well yes, we cannot have everything.
Just like it is taking a while for ``diagonal``
to transition to providing a view,
On 7/23/2013 5:32 PM, josef.p...@gmail.com wrote:
Do we really need a one letter shorthand for `a.conj().T` ?
One way to assess this would be to propose removing
it from matrix and masked array objects. If the
yelping is loud enough, there is apparently need.
I suspect the yelping would be
On 7/23/2013 6:45 PM, Dag Sverre Seljebotn wrote:
It'd be great if you could try to incorporate it to create a more balanced
overview
Attempt 2:
I believe that propoents of adding a .H attribute have
primarily emphasized
- readability (and general ease of use, including in teaching)
-
On 7/24/2013 3:15 AM, Sebastian Haase wrote:
I feel that adding a method
.H()
would be the compromise !
Alan, could you live with that ?
I feel .H() now would get in the way of a .H attribute later,
which some have indicated could be added as an iterative
view in a future numpy. I'd rather
http://www.python.org/dev/peps/pep-0450/
https://groups.google.com/forum/#!topic/comp.lang.python/IV-3mobU7L0
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi Colin,
I'm just the messenger. I thought this list might be interested.
Feedback should go to Steven D'Aprano on comp.lang.python
I think the PEP makes it clear that the target is not secondary
students but rather users who want numerically robust versions
of some basic statistical
On 8/19/2013 2:37 AM, Juan Luis Cano wrote:
https://github.com/numpy/numpy/issues/2880
it was suggested that we deprecate and eventually remove the financial
functions in NumPy
It seems that this summary is a bit one-sided. There was also
a suggestion to move these into numpy.financial,
On 8/22/2013 10:32 PM, Warren Weckesser wrote:
Christoph
reported that this code:
```
import numpy as np
data = np.array([-0.375, -0.25, 0.0])
s = np.log(data)
```
does not generate two RuntimeWarnings when it is run with numpy 1.7.1
in a 32 bit Windows 8 environment (numpy 1.7.1
On 8/29/2013 3:48 PM, Ralf Gommers wrote:
Some context would have helped.
http://www.youtube.com/watch?v=y2R3FvS4xr4
fwiw,
Alan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 9/25/2013 3:06 AM, Edmondo Porcu wrote:
advice on how to create a matrix with certain characteristics :
- Every entry should be minimum 0 maximum 1 with a step of 0.1 (legal
values are 0,0.1,0.2,0.3 etc)
- The number of columns of the matrix is a parameter of this matrix creation
For + and * (and thus `dot`), this will fix something that is not broken.
It is in fact in conformance with a large literature on boolean arrays
and boolean matrices. That not everyone pays attention to this literature
does not constitute a reason to break the extant, correct behavior.
I'm sure
On Thu, Dec 5, 2013 at 8:05 PM, Alan G Isaac
alan.is...@gmail.com wrote:
For + and * (and thus `dot`), this will fix something that is not broken.
It is in fact in conformance with a large literature on boolean arrays
and boolean matrices.
On 12/6/2013 3:24 AM, Nathaniel Smith wrote
On 12/5/2013 11:14 PM, Alexander Belopolsky wrote:
did you find minus to be as useful?
It is also a correct usage.
I think a good approach to this is to first realize that
there were good reasons for the current behavior.
Alan Isaac
___
On 12/6/2013 12:23 PM, Alexander Belopolsky wrote:
What is the rationale for this:
-array(True) + array(True)
True
The minus is complementation.
So you are just writing
False or True
Alan Isaac
___
NumPy-Discussion mailing list
On 12/5/2013 11:14 PM, Alexander Belopolsky wrote:
did you find minus to be as useful?
On Fri, Dec 6, 2013 at 11:13 AM, Alan G Isaac
It is also a correct usage.
On 12/6/2013 12:23 PM, Alexander Belopolsky wrote:
Can you provide a reference?
For use of the minus sign, I don't have one
On 12/6/2013 1:35 PM, josef.p...@gmail.com wrote:
unary versus binary minus
Oh right; I consider binary `-` broken for
Boolean arrays. (Sorry Alexander; I did not
see your entire issue.)
I'd rather write ~ than unary - if that's what it is.
I agree. So I have no objection to elimination
of
On 12/6/2013 3:30 PM, josef.p...@gmail.com wrote:
6 `**` follows from 1.
Yes, but what really matters is that
linalg.matrix_power
give the correct (boolean) result.
Alan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On 12/6/2013 3:50 PM, Sebastian Berg wrote:
Both of these are currently not defined, they will just cause upcast to
int8.
What does currently mean?
`**` works fine for boolean arrays in 1.7.1.
(It's useless, but it works.)
Alan Isaac
___
For teaching it is certainly nice to have numpy.polynomial.polynomial.polyfit
providing modern (vs. traditional) parameter order, but
- it is rather buried
- np.polyfit uses traditional order and has the same name
I recall there was some controversy (?) over all of this,
but might it not be
On 1/26/2014 12:02 PM, Stéfan van der Walt wrote:
what would the output of
``group_by((key1, key2))``
I'd expect something named groupby to behave as below.
Alan
def groupby(seq, key):
from collections import defaultdict
groups = defaultdict(list)
for item in seq:
My comment is just on the name.
I'd expect something named `groupby`
to behave essentially like Mathematica's `GatherBy` command.
http://reference.wolfram.com/mathematica/ref/GatherBy.html
I think you are after something more like Matlab's grpstats:
On 2/6/2014 6:03 PM, David Goldsmith wrote:
So the substance of the utility function Stefan suggests is one line:
It's even easier than that:
np.mat('1 2;3 4').A
However the context is the introduction of the language
to students who have no programming experience, not
my personal convenience
On 2/9/2014 4:59 PM, alex wrote:
The ``numpy.matrix`` API provides a low barrier to using Python
for linear algebra, just as the pre-3 Python ``input`` function
and ``print`` statement provided low barriers to using Python for
automatically evaluating input and for printing output.
On the
On 2/9/2014 5:55 PM, alex wrote:
I'm working on the same kinds of problems in scipy development
(functions involving sparse matrices and abstract linear operators)
And how is numpy's matrix object getting in your way?
Your initial post simply treated the desirability of
deprecation as a given
On 2/10/2014 3:04 PM, Matthew Brett wrote:
I teach psychologists and neuroscientists mainly
I must suspect that notebook was not for
**undergraduate** psychology students.
At least, not the ones I usually meet.
SymPy is great but for those without background
it is at best awkward. It
On 2/10/2014 4:03 PM, Pauli Virtanen wrote:
What sparked this discussion (on Github) is that it is not possible to
write duck-typed code that works correctly for:
Do you mean one must start out with an 'asarray'?
Or more than that?
As I detailed in past discussion, the one thing
I really do
On 2/10/2014 4:08 PM, Matthew Brett wrote:
I think the active questions here are:
* Should we collect the discussion in coherent form somewhere?
* Should we add something to the np.matrix docstring and if so what?
* (Pauli's point): to what extent should we try to emulate the np.matrix API.
On 2/10/2014 4:28 PM, Pauli Virtanen wrote:
Starting with asarray won't work: sparse matrices are not subclasses
of ndarray.
I was focused on the `matrix` object.
For this object, an initial asarray is all it takes to use array code.
(Or ... not?) And it is a view, not a copy.
I don't have
On 2/10/2014 4:40 PM, alex wrote:
I really want to remove it
Can you articulate the problem created by its existence
that leads you to this view?
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On 2/10/2014 5:11 PM, Pauli Virtanen wrote:
The existence of np.matrix messes up the general agreement on ndarray
semantics in Python. The meaning of very basic code such as
A * B
A.sum(0)
A[0]
where A and B are NxN matrices of some sort now depends on the types
of A and
On 2/10/2014 7:39 PM, Pauli Virtanen wrote:
The issue here is semantics for basic linear algebra operations, such as
matrix multiplication, that work for different matrix objects, including
ndarrays.
I'll see if I can restate my suggestion in another way,
because I do not feel you are
1 - 100 of 624 matches
Mail list logo
