3 ms·
> mathematical notation has changed over the years. I agree. Math notation has changed in response to problems mathematicians have faced, and as their thinking
by abdullahkhalids 2y ago
> mathematical notation has changed over the years.
I agree. Math notation has changed in response to problems mathematicians have faced, and as their thinking have evolved. It should not change because tool builders for mathematicians - when the tool builders in most cases are not even professional mathematicians - decide some other notation is better.
> array.mean().round(digits=2)
might be good (it is not) when you are operating on one object. As soon as you have a binary operation (say multiplication), this notation completely breaks down. Because the operation is often symmetric, or "near" symmetric, meaning it is not so different as to write something as ridiculous as x.product(y).
But more importantly, (common/dominant) mathematics is functional in nature. It's decidedly not object oriented. Given a matrix, M, doing something like M.eigenvalues() is vomit-inducing because eigenvalues is not a property of a matrix M. For matrices, its a map from a set of linear transformations (of which M is merely one item) onto a set of numbers. It is its own thing, separate from M.
- adastra22 2y agoNow you're gatekeeping on who is a real mathematician? I don't think this subthread is going to be productive and I'm bowing out.
- nightlyherb 2y agoI'm not the GP, but I'm sorry you felt gatekeeped. I don't think GP conveyed "real mathematicians should do FP", but rather something else, so I'll try my best to share what I understood from that comment. Hope this makes you feel better. Even though the notation changed over the years, the paradigm of "numbers as immutable entities and pure functions" has been the dominant way that math is presented, compared to something like "encapsulated objects that interact with each other via sending messages". I don't think this has to be this way, and I do think that "real math" can also be laid out assuming principles of OOP. However, I do suspect it's the way it is because the laws of nature are unchanging, in contrast to the logic of a business application. Because Julia is a tool with the target audience of mathematicians and scientists, I think it's a sensible decision to embrace the usual way of thinking, as opposed to presenting a relatively different way of thinking which steepens the learning curve. Not because data and functions are fundamentally better than OOP, but because it's more pragmatic for the target audience.
- adastra22 2y agoI understood the other poster correctly. This view of mathematics is as limiting and ignorant as the other poster’s. The entire field of theoretical computer science, to which functional programming and type theory is closely tied, is a branch of mathematics. The Church-Turing thesis which gives both to our field equates the two at a very fundamental level. Questions about type theory, programming language design, and programmer ergonomics are fundamentally about math and applied math. Maybe you and the other poster have in mind specific fields of math, but then you need to make claims for why those fields are sufficiently different as to be exempt from applicability of any of the advances in notation observed in other fields. Your implicit assumption that you can divide computer science into a different bucket from “real math” is incorrect, and gatekeeping. As I said though, I don’t think this is a profitable debate to have here on HN.
- nightlyherb 2y agoOkay, I see what you mean. > Maybe you and the other poster have in mind specific fields of math, Yes, because this is about Julia, I assumed we are talking about the specific fields of math that happen to be commonly used in mathematical and scientific computing, such as the ones learned in university math and science courses. > Your implicit assumption that you can divide computer science into a different bucket from “real math” is incorrect, and gatekeeping. It is regretful that we had a miscommunication. I agree with you that computer science belongs into the same bucket as "real math". The thing is, in the context of Julia it is not easy to read "math" as "math, but not only the domains that Julia is concerned in, but really all fields of math, including theoretical computer science". At least thanks to your comment, I see what you mean more clearly, and I think it'll help some other potential readers as well. > but then you need to make claims for why those fields are sufficiently different as to be exempt from applicability of any of the advances in notation observed in other fields. I'm curious to know specifically about the specific advances of notation observed in other fields. By this you mean dot notation for method application? I'm unsure if `a.method(b).anotherMethod(c)` is more advanced than `a |> method(b) |> anotherMethod(c)` (Edit: or `(anotherMethod(c) . method(b))(a)`) notation-wise.
- nightlyherb 2y ago
- bee_rider 2y agoIn programming it is typical to have an “eig” function, or something of the sort, which returns the eigenvalues of a matrix. eig(M) seems no less vomit inducing than M.eigenvaues(). Usually when mathematicians want eigenvalues they write something like “Given a matrix M with eigenvalues \lambda” and the eigenvalues just show up.
- samatman 2y agoIn Julia: M = [1 2 3; 4 5 6; 7 8 9] λ = eigvals(M) Which is much the same.
- bee_rider 2y agoSure, my point is that even the math-y programming languages and libraries don’t map very well to how mathematicians seem to describe eigenvalues. Personally I think of them as a characteristic of the matrix (but I just write numerical software, I’m not a mathematician) and implement them as the result of a process. So I don’t really see any reason to favor either syntax or call one more mathematical.