6 ms·

Sometimes I wake up suddenly at night, sweating, terrified, and crying like a baby, because python+numpy has become a sort of standard in numerical computing.

• stochastic_monk 8y ago
  Would this be solved by inclusion of numpy into python’s standard library? Is there a chance it might? I know it was behind syntax changed in 3.
  • enriquto 8y ago
    What do you mean exactly? Can I do matrix products and slices without importing anything? Yes, that would solve the problem. But I do not think that this would be possible without major changes in the language itself. This is not a library problem, it is a focus problem of the language. The language supports strings and dictionaries natively, as basic data types, but not numeric arrays.
    • hprotagonist 8y ago
      yes it does. nobody actually uses them, but a non-list ordered sequence of values is actually part of the library. https://docs.python.org/3/library/array.html https://docs.python.org/3/library/array.html
      • stochastic_monk 8y ago
        For one-dimensional arrays, python's array can be faster. It's also directly accessible through the Python C API/Cython's wrapping of it, which makes it convenient to use.
  • dagw 8y ago
    You don't have to include all of numpy into python standard library. Unifying python's existing 'array' package with numpy arrays and allowing logical and arithmetic operation and the functions in the standard lib 'math' package to operate on those arrays would get you very far. Then you can still have numpy as a separate package for people who wanted more advanced functions.
• mlthoughts2018 8y ago
  Python has statically typed arrays in the standard library: in the array module (e.g. array.array). It’s not used much for scientific computing because numpy made a better tool. Also, the list data structure in Python is a contiguous memory array... it’s just designed to store a contiguous array of PyObject pointers, and the use case for list is exactly when the flexibility and abstraction of using PyObject data structures is more important than raw performance. You would use numpy arrays or special jitted functions or custom C-level data structures you write in Cython, etc. etc., when raw performance is the higher priority.
  • enriquto 8y ago
    My point exactly. Python was not thought from the beginning as a language for numerical computing, and when you try to force it for that, there is a lot of friction. Just having to "import" a library to have sane support for arrays is silly.
    • SketchySeaBeast 8y ago
      I feel like that's the point of Python - only provide the barebones of what you might need initially, and then make importing the rest fast and easy. For most use cases Pythons default collections work just fine (what does an array have that a list doesn't for everyday use?), but if you need more power, just import and go.
      • enriquto 8y ago
        From my point of view, numeric arrays are barebones, and strings and dictionaries are fancy data structures that I never need, but they are nevertheless elevated as features of the language itself. It would seem much more natural if it was the other way round. In my everyday life I solve linear systems in octave by doing "x=A\b", but in python it becomes very cumbersome.
• amelius 8y ago
  On the contrary, I prefer my languages lightweight, and capable of allowing arrays (and strings, dictionaries, etc) to be implemented by libraries.
  • enriquto 8y ago
    > On the contrary, I prefer my languages lightweight, and capable of allowing arrays (and strings, dictionaries, etc) to be implemented by libraries. I agree with this philosophy! But that is certainly not at all the case with python, where fancy strings and even fancier dictionaries are readily available at the language level, instead of being implemented as separate libraries that you have to import. If Python did not support strings nor dictionaries as basic data types, you might have a point. But it does, and it chooses to ignore multidimensional arrays and their basic operations. This is weird, and even a bit offensive when all you need to do is dealing with such arrays of numbers. You always feel like an "outsider", unlike when you program in octave or julia, for example.
    • altairiumblue 8y ago
      To give a different perspective: - the existence of tools for working with strings and dictionaries doesn't take away from numpy at all - I have never been offended by a programming language or felt like an outsider while using numpy
      • mcabbott 8y ago
        It always seems a bit weird to me that np.einsum needs to parse a string in its own private syntax. I guess it's a good thing that at least it has tools for this!
    • jordigh 8y ago
      Semi-inactive Octave dev here. Even though I use Python every day, and I have used scipy often, I still reach for Octave whenever I need a quick calculation that I don't feel like turning into a big project. And yeah, it's nice that matrices are first-class objects. Sometimes I miss 1-dimensional arrays or sensible strings, but it's not a big deal, and for quick, short things, the Octave syntax is still a lot easier to deal with than Python. Most of Octave's users describe themselves as "not a programmer", despite using a programming language, so I think there's still room for this kind of software in the world.
• altairiumblue 8y ago
  I'm not sure I understand your point. What's the downside of numpy arrays being "non-native"?
• whatshisface 8y ago
  The secret of compiled languages (like Rust and Go) is that they are all mainly designed to implement compilers. After all, self-hosting is almost always the first and most formative software engineering goal. ;)
• BeetleB 8y ago
  Dunno man. I used MATLAB for most of my thesis, and once I discovered NumPy, I switched all my code to it in a heartbeat. Yes, MATLAB is better for matrix manipulation. For everything else, Python is better. My productivity went up quite a bit.