3 ms·

>numpy has similar syntax to MATLAB and Julia Numpy has absolutely awful syntax compared to Julia or MATLAB. It is fundamentally limited by pythons syntax, whi

>numpy has similar syntax to MATLAB and Julia Numpy has absolutely awful syntax compared to Julia or MATLAB. It is fundamentally limited by pythons syntax, which was never meant to support the rich operations you can do in Julia. I have done quite a bit in both languages and it is extremely clear which language was designed for numerical analysis and which wasn't . >Python's type system is pretty rich and allows overloading all operators The language barely has support for type annotations. Duck typing is actually a very bad thing for doing numerical analysis, since you actually care a lot about the data types you are operating on. Pythons type system is so utterly inadequate that you need an external library to have things like proper float types.

mgaunard 2y ago
You're just repeating that it's bad without any argument. Numpy's syntax is the same as MATLAB's. Both MATLAB and Julia also use dynamic typing, though it is true Julia does have support for ad-hoc static typing through annotations in a way that is stricter than Python's. Numpy does provide all the traditional floating-point types.
- constantcrying 2y ago
  >Numpy's syntax is the same as MATLAB's. That is just plain false. Can you try reading the numpy documentation? They have an article about exactly that topic and even say that numpys Syntax is more verbose. If you read that documentation you would also realize that numpy has a different approach to Arrays than both MATLAB and Julia. Here: https://numpy.org/doc/stable/user/numpy-for-matlab-users.html https://numpy.org/doc/stable/user/numpy-for-matlab-users.htm... "MATLAB’s scripting language was created for linear algebra so the syntax for some array manipulations is more compact than NumPy’s."
  - mgaunard 2y ago
    The only difference is that MATLAB has more operators like matrix multiplication in addition to element-wise multiply, but that applies to Julia too.
    - constantcrying 2y ago
      No, that is not the only difference. I literally linked you an article in the numpy documentation which goes over dozens differences, large and small. I encourage you to read the section about the different numpy types, those concepts don't exist in MATLAB, where everything is an n-dimensional array and matrices as such don't exist as a special object. There are also many differences between Julia and MATALB, although Julia obviously borrowed a lot from MATALB, for the obvious reason that MATLAB had a similar design goal in it's language. That doesn't change that python inherently won't overcome the fact that it wasn't designed for numerical analysis, while both MATLAB and Julia were (although those also had somewhat different design objectives themselves, especially when it comes to the role of functions).
      - mgaunard 2y ago
        And that documentation just says all differences are minute, e.g. no matrix operators and zero-based indexing. The matrix type exists because the operators don't exist. Any good general-purpose programming language can enable any domain-specific language to be embedded within itself through its type system as a library. Numpy embeds array programming in Python, and arguably that approach is much more flexible than building separate domain-specific languages. At this point you're just grasping at straws and systematically modding down my posts because facts don't agree with your beliefs.
        constantcrying 2y ago
        It doesn't say they they are minute, because obviously they aren't. The fact alone that numpy has fundamental datatypes which don't exist in MATLAB should be enough to make it functionally distinct. Seriously please read the article and try to actually use these tools. You would very quickly realize just how different numpys approach is to MATLAB. Again, they don't even operate on the same types. MATLAB only knows the n-dimensional array, that data type doesn't exist in numpy where the array has quite a different fundamental structure, which becomes pretty clear if you read the article. I get that someone with little experience in both languages might be confused, purely looking from the outside they might seem similar, but if you are familiar with both you realize that they are very different and require you to approach implementations from different directions. Ultimately numpy was designed to fit into python, which will always limit it compared to a DSL.

mgaunard 2y ago

You're just repeating that it's bad without any argument. Numpy's syntax is the same as MATLAB's. Both MATLAB and Julia also use dynamic typing, though it is true Julia does have support for ad-hoc static typing through annotations in a way that is stricter than Python's. Numpy does provide all the traditional floating-point types.

constantcrying 2y ago
>Numpy's syntax is the same as MATLAB's. That is just plain false. Can you try reading the numpy documentation? They have an article about exactly that topic and even say that numpys Syntax is more verbose. If you read that documentation you would also realize that numpy has a different approach to Arrays than both MATLAB and Julia. Here: https://numpy.org/doc/stable/user/numpy-for-matlab-users.html https://numpy.org/doc/stable/user/numpy-for-matlab-users.htm... "MATLAB’s scripting language was created for linear algebra so the syntax for some array manipulations is more compact than NumPy’s."
- mgaunard 2y ago
  The only difference is that MATLAB has more operators like matrix multiplication in addition to element-wise multiply, but that applies to Julia too.
  - constantcrying 2y ago
    No, that is not the only difference. I literally linked you an article in the numpy documentation which goes over dozens differences, large and small. I encourage you to read the section about the different numpy types, those concepts don't exist in MATLAB, where everything is an n-dimensional array and matrices as such don't exist as a special object. There are also many differences between Julia and MATALB, although Julia obviously borrowed a lot from MATALB, for the obvious reason that MATLAB had a similar design goal in it's language. That doesn't change that python inherently won't overcome the fact that it wasn't designed for numerical analysis, while both MATLAB and Julia were (although those also had somewhat different design objectives themselves, especially when it comes to the role of functions).
    - mgaunard 2y ago
      And that documentation just says all differences are minute, e.g. no matrix operators and zero-based indexing. The matrix type exists because the operators don't exist. Any good general-purpose programming language can enable any domain-specific language to be embedded within itself through its type system as a library. Numpy embeds array programming in Python, and arguably that approach is much more flexible than building separate domain-specific languages. At this point you're just grasping at straws and systematically modding down my posts because facts don't agree with your beliefs.
      - constantcrying 2y ago
        It doesn't say they they are minute, because obviously they aren't. The fact alone that numpy has fundamental datatypes which don't exist in MATLAB should be enough to make it functionally distinct. Seriously please read the article and try to actually use these tools. You would very quickly realize just how different numpys approach is to MATLAB. Again, they don't even operate on the same types. MATLAB only knows the n-dimensional array, that data type doesn't exist in numpy where the array has quite a different fundamental structure, which becomes pretty clear if you read the article. I get that someone with little experience in both languages might be confused, purely looking from the outside they might seem similar, but if you are familiar with both you realize that they are very different and require you to approach implementations from different directions. Ultimately numpy was designed to fit into python, which will always limit it compared to a DSL.