71–80 of 85 posts
About damned time. Writing your own stats library is like writing your own crypto.
You wouldn't write your own - numpy / scipy have everything you'll need.
Kudos to PHP for apparently being ahead of the curve among dynamic languages with regard to statistics. Another interesting, yet unmentioned option is Clojure/Incanter.
Just out of curiosity, I submitted this yesterday: https://news.ycombinator.com/item?id=6190603 The URL was http://www.python.org/dev/peps/pep-0450/ While this is http://www.python.org/dev/peps/pep-0450 That is, exactly the same except for a trailing slash. Doesn't the deduplication algorithm handle this case?
I posted an ASK PG [1] about this last month ago and got an angry email from (presumably) a mod. His point was totally valid - that PG 'aint go time fo' that' which is true, but I was just hoping to draw attention to it, as opposed to demand PG drop what he's doing right now and fix it. To be honest, I was quite surprised by the tone of the email. [1] https://news.ycombinator.com/item?id=5908075
Earlier quoted context omitted.
numpy is quite portable, I am not sure what you mean by not nearly portable enough. The reason why you can't do pip install numpy is pip's fault, there is nothing that numpy can do to make that work. Note that easy_install numpy does work on windows (without the need for a C compiler).
the problems I have had with numpy are endless. Usually I'll just prefer to write my own, because it's quicker. if you have tried to get numpy running on a cloud machine you'll know what I'm talking about. basically you will have to know how to compile from source, know some gcc, etc. the last time I tried to get it running I promised myself never to use numpy again.
If you're happy with the system-wide Python, try apt-get install python-numpy next time.
Earlier quoted context omitted.
scipy.stats distribution objects are a bit particular, that's a bit unfair to pin point them. Generally, numpy and scipy have much better docstrings than python stdlib itself.
Well, help(scipy.optimize.nonlin.Anderson) has the same problem, but you're right in that that failure mode is rare, and that numpy/scipy has good documentation. However, in the context of a stats library, I think it's okay to point out that scipy.stats has some annoying parts. ;) In all honesty, I seldom use NumPy and rarely use SciPy, so I can't judge that deeply. I know that when I read their respective code bases…
I don't see numpy being integrated in python anytime soon. I don't think it would bring much, and one would have to drop performance enhancement that rely on blas/lapack.
I think installing has improved a lot, and once pip + wheel matures, it should be easy to pip install numpy on windows.
Earlier quoted context omitted.
Per RFC3986/7, http://example.com/%60 and http://example.com/a are equivilant. (Indeed, all major browsers will request the latter regardless of what is input.) Equally, punycode encoded IRIs and the original IRI are equivilance. There is a whole section on equivilance in both of the RFCs (3967 includes 3986 by reference, so is a superset).
Browser equivalence is another thing entirely. Most browsers will accept http://www。google。com (because in Japanese '。' is '.'). But if you tried to request that actual resource it doesn't lead anywhere. But yeah HN should just use browser equivalence.
Following what the spec says for eqivilance makes sense, at least. Anything drastic is technically treating distinct URLs as equivilant.
Earlier quoted context omitted.
Well, help(scipy.optimize.nonlin.Anderson) has the same problem, but you're right in that that failure mode is rare, and that numpy/scipy has good documentation. However, in the context of a stats library, I think it's okay to point out that scipy.stats has some annoying parts. ;) In all honesty, I seldom use NumPy and rarely use SciPy, so I can't judge that deeply. I know that when I read their respective code bases…
Actually, I don't think the import * in numpy is anything else than historical artefact. Numpy just happens to be one of the oldest, still widely used python library (considering numpy started as numeric), as you point out. As for import speed, have you considered using lazy import in your script ? I don't see numpy being integrated in python anytime soon. I don't think it would bring much, and one would have to drop…
For examples, from http://mail.scipy.org/pipermail/numpy-discussion/2008-July/0... :
Robert Kern: Your use case isn't so typical and so suffers on the import time end of the balance
Stéfan van der Walt: I.e. most people don't start up NumPy all the time -- they import NumPy, and then do some calculations, which typically take longer than the import time. ... You need fast startup time, but most of our users need quick access to whichever functions they want (and often use from an interactive terminal).
I went back to the topic last year. Currently 25% of the import time is spent building some functions which are then exec'ed. At every single import. I contributed a patch, which has been hanging around for a year. I came back to it last week. I'll be working on an updated patch.
There's also about 7% of the startup time because numpy.testing imports unittest in order to get TestCase, so people can refer to numpy.testing.TestCase. Even though numpy does nothing to TestCase and some of numpy's own unit tests use unittest.TestCase instead. sigh. And there's nothing to be done to improve that case.
Regarding the age - yes, you're right. BTW, parts of PIL started in 1995, making it the oldest widely used package, I think. Do you know of anything older?
Earlier quoted context omitted.
> Permutations and combinations already exist within the itertools module. Not exactly. Given argument lists, Itertools provides result lists (actually, iterators for that purpose) with the original elements permuted and combined, but doesn't provide numerical results for numerical arguments, as shown here: http://arachnoid.com/binomial_probability I was referring to permutation and combination mathematical functions…
Put differently, you want the functions that count the number of permutations and combinations possible, not functions that yield/generate the actual permutations and combinations.
Earlier quoted context omitted.
Permutations and combinations already exist within the itertools module.
There is something deep about software that thwarts our dreams of making it re-usable, and makes debates about what primitives to put into the stdlib difficult. For one thing, it seems like we should be able to collectively determine a DAG of concepts, starting from simplest primitives and progressively building up derived concepts, like the tech tree in a game like Civilization, or Principia Mathematica. But that tr…
1. Better math training in school.
2. More kinds of applied math problems being routinely evaluated by Python and other languages.
3. More available memory and storage capacity.
All of which argue for larger math libraries with more functions and classes of functions.
> Presumably, most Python users don't need anything beyond what a financial calculator would provide, and anyone else should head to numpy.
I would normally agree, but the argument has been made in this thread that numpy can't be installed in some environments -- environments that easily support Python, but that don't accommodate numpy without great difficulty.
Earlier quoted context omitted.
NumPy is not nearly portable enough to do what you are describing as a user on a windows machine. You cannot simply do a `pip install numpy` into a virtualenv. Instead you must either install the package system-wide, or compile it yourself, which means getting a working MinGW environment or similar. Edit: Although, I do agree that NumPy being difficult to install is not, on its own, a good justification for the PEP.
numpy is quite portable, I am not sure what you mean by not nearly portable enough. The reason why you can't do pip install numpy is pip's fault, there is nothing that numpy can do to make that work. Note that easy_install numpy does work on windows (without the need for a C compiler).