7 ms·

Perhaps its time to rethink the sanctity of mathematical symbolic communication. Seriously, that equation borders on parody in attempting to relay a rather simp

Perhaps its time to rethink the sanctity of mathematical symbolic communication. Seriously, that equation borders on parody in attempting to relay a rather simple concept. We dont expect CS people to communicate concepts through compiled, machine language style syntax (minimum number of bits uber alles) so why not revisit the communication of mathematical concepts with weight given to clarity over compression?

Ar-Curunir 10y ago
Because mathematics is a very dense language; building in redundancy does not scale when you're reading mathematics papers.
- gravypod 10y ago
  Would it make sense to say "building in redundancy does not scale when you're reading source code"? Not to me it doesn't.
  - DollaWilliam 10y ago
    That's a false equivalency. Mathematics, in practice, is more of a domain specific language that encapsulates more and more precise information as you increase the level of abstraction. The levels of abstraction layer upon one another to be able to handle more complex concepts while retaining all of the underlying precision.
    - gravypod 10y ago
      > Mathematics, in practice, is more of a domain specific language that encapsulates more and more precise information as you increase the level of abstraction Isn't that the point of any DSL? Also, wasn't the advent of DSLs meant to make it easier for non-programmers to understand the flow of control in a system? I think generally the idea was to make things easier to understand by factoring out the complicated bits (implementation) and leveraging abstraction to provide clarity on top of an implementation. If this is the case for every DSL I and every other CS major designs, why should it not be the goal of every math major? Sure to you and many other math-centrist people these symbols are "how I learned it so it must be the best" but to everyone else it's difficult to grasp and hard to understand. The lingo is half the battle for most things but for math it seems like the lingo is the entire battle.
      - DollaWilliam 10y ago
        > The lingo is half the battle for most things but for math it seems like the lingo is the entire battle. There's a kernel of truth there. To abuse the DSL metaphor further, even mildly complicated mathematics concepts are only expressible using layer upon layer of ever-more-abstracted DSLs. Lower-level expansions of the building blocks to improve clarity for reading would be useless in practice, since mathematics is intended to be written and understood by humans and such an expansion would exceed our ability to keep the entire intended concept in our working memory. Proficiency in mathematics is proficiency with understanding and extending the lingo itself. Mathematics /is/ the lingo, which is why it can't be unraveled from it. >"how I learned it so it must be the best" Not at all. It is, however, a very practical approach to getting someone up to speed to be able to do actual mathematics (as opposed to the basic symbol manipulations that most people confuse with actual mathematics.)
  - userbinator 10y ago
    It makes sense to me, although perhaps at a different level --- IMHO redundancy is bad in source code in general, and if you base your development methodologies and practices on assuming that it's not, you end up with things like Enterprise Java and C#: huge, eye-bleedingly verbose monstrosities to perform the simplest of tasks.
    - gravypod 10y ago
      Just as with everything there is a sweet spot. I personally feel some things need to stay verbose while some things are implementation and not inherently needed. Before college, I didn't do any python. After touching the language because of a class I like some of the things they do. For instance: for i in range(10): print(i) This is a great way to show a way to print 0-9 to stdout. This is great. Contrary to this, you have a more c-like method of writing this. for (int i = 0; i < 10; i++) printf("%d\n", i); This is the same code, but we have a lot more stuff here that convey a lot of meaning. This is fine for me. The construct is dense, but it's not overly dense. It is simple because once you see it the first time, you will understand it and it will always make sense to you no matter how many years pass. I'm fine with this extra verbosity. On the other side of the spectrum you have this: map(print, range(10)) This is far fewer characters, but it's more difficult to understand. There are more things to understand if you've never done any functional programming. This sort of dense solution is frowned upon in many cases, especially since this sort of thing rarely scales efficiently in the sense of cognitive load. I did all of my CS labs using map/reduce formulas for CS100 and it did nothing but make things harder and drive a large appreciation for expanding statements into my heart.
      - chaoxu 10y ago
        That map is doing an impure operation. The order of application matters. Otherwise, for people who learned functional programming from the start, it's much easier to understand.
      - witty_username 10y ago
        I find the map solution simpler than the for loop as there is no loop variable.
  - Ar-Curunir 10y ago
    To clarify; mathematics talks about objects with increasing amounts of density; as you proceed up the abstraction stack into increasingly abstract topics, you need to be able to efficiently compress the topics you're already supposed to have mastered. Mathematics is for experts that have mastered the lower levels of the abstraction layer. You cannot study any subfield of math without having understood the basic definitions of the field. No amount of syntax rewriting is going to change that; those definitions are not going anywhere.
    - gravypod 10y ago
      "To clarify; software talks about objects with increasing amounts of complexity; as you proceed up the abstraction stack into increasingly abstract topics, you need to be able to efficiently compress the topics you're already supposed to have implemented." What I'd expect to follow here would be a statement about how your abstractions should be terse and verbose in the right ways. Terse in the implementation specific handling and verbose in the explanation of your abstract solution. "Software is for experts that have mastered the lower levels of the abstraction layer. You cannot study any subfield of systems programming without having understood the basic implementation of the underlying software. No amount of syntax rewriting is going to change that; those definitions are not going anywhere." I don't see how that statement would make any sense. I expect to be able to give anyone with the most basic of understandings of computers a piece of any code (from Assembly to high level Lisp code) from widely used software like the Linux kernel all the way to stock trading applications and I expect them to understand it by looking at it for a few seconds, reading the comments, and reading the names of the variables and functions. If the average person cannot do that, then it's bad code. Understand-ability is the only point of programming. To be understood by the computer and by a maintainer. I'd never say that obtuse notations for an abstraction should stay around. I'd replace the obtuse notation with a better abstraction.
      - yorwba 10y ago
        > I expect them to understand it by looking at it for a few seconds, reading the comments, and reading the names of the variables and functions. Mathematics also comes with comments, many papers essentially consists of one giant comment for the proof in the appendix. Granted, many variable names could be a bit less terse, but it's just easier to write "let f be an arbitrary function A -> B" once instead of using arbitraryFunctionMappingTheSetOf{DefinitionOfElementsOfA}toTheSetOf{DefinitionOfElementsOfB} every time.
  - wfo 10y ago
    You don't need to read or understand (most of) your source code because it is 90% libraries. Mathematics is built based on understanding all the concepts behind a subject, and it's written to express to another human clear rigorous thought. You cannot just black box everything away and choose to ignore it the way programmers do with source code and libraries. The metric for success with a program is "does the machine run it properly". The metric for success with a piece of mathematics is "do people who've done some reading in my field understand my new result". You can cheat in one but not in the other.
    - gravypod 10y ago
      > You don't need to read or understand (most of) your source code because it is 90% libraries That's just plain incorrect. I expect all code to be written to standards of which would allow anyone to read. > Mathematics is built based on understanding all the concepts behind a subject, and it's written to express to another human clear rigorous thought. Isn't abstraction designed to avoid this? To remove a solution from a problem domain? To work on it without integral knowledge of all; applications? If not then all of Computer Science has been doing it wrong. > You cannot just black box everything away and choose to ignore it the way programmers do with source code and libraries. We don't do that. We black box things that aren't related to the problem at hand by referring to them in a terse and understandable way. For instance if I want to use a fork join scheduler for parallel thread scheduler I don't need to write out all the code for a fork join scheduler. I just need to say "You probably know what this is, if not it's called a fork join scheduler and I'll interact with it via sending messages of run, runAll, etc" and be done with it. I wont use an obscure Greek letter to notate a Fork-Join as that's archaic and insane. > The metric for success with a program is "does the machine run it properly". The metric for success with a piece of mathematics is "do people who've done some reading in my field understand my new result". You can cheat in one but not in the other. The KPIs for software are as follows: functionality, maintainability, simplicity. In that order. There is no single goal of software but instead a multifaceted set of goals constantly working against each other yet CS people make room for an even balance. I don't see how this relates to you engaging in proving further information from other information. I don't see why math needs 40 non-terminal characters to type out a proof. I don't see why it can't be written in a way that is more approachable while not detrimental to the performance of current professionals. I also find it unfathomable that someone would think that the current way of doing things is the, all together, best way of doing things because that points a blind eye at the other two things I mentioned: "maintainability, simplicity". I wouldn't call any of the advanced math world "simple" or "maintainable".
- delinka 10y ago
  Dense and high-level. Like programming languages. You take a group of machine operations and represent those with an operator in a programming language. You take a group of programming statements, expressions, etc and represent them with a procedure. Group some procedures together into a category (or perhaps a 'class' of items.) Take a few lines of COBOL, compile it, and how much actual machine work does that represent? Lots. Very dense.
ajmurmann 10y ago
I think the goal of mathematical notation is precision rather than ambiguity. Yes, the example seems awfully complicated for what simple thing it's trying to state. However, if you read it out loud it still sounds complicated. It's a simple concept, but it's hard to communicate without room for ambiguity.
- paulftw 10y ago
  How do we know if the solution they chose to achieve that goal is the most efficient one? How did that notation evolve? Has it evolved at all? What if it's just a design by committee, with decisions made in the 17th century still affecting how modern papers are written? What if we think of the rulebook on "how to write math" as a codebase? Would it be a 3-4 centuries old codebase without any major refactorings done, ever?
  - deleted 10y ago
    [deleted]
  - pron 10y ago
    Notation has steadily advanced towards the more precise and concise, because it helps. Watch this interesting Lamport talk about the changes in notation: http://www.heidelberg-laureate-forum.org/blog/video/lecture-tuesday-september-23-2014-leslie-lamport/ http://www.heidelberg-laureate-forum.org/blog/video/lecture-...
billsix 10y ago
"Is an element of the set" "for all" "there exists". It's automata and computational theory 201, not parody
deleted 10y ago
[deleted]
jjoonathan 10y ago
∀+∃+{|} are the epitome of clarity over compression. Mathematicians like them for the same reason why many programmers like sophisticated static typing. They might not always improve the clarity of toy examples to beginners, but they certainly help improve the clarity of untamed, wart-ridden, real life problems to initiates. I think the first time I truly appreciated the power of ∀ and ∃ was during functional analysis when I found myself juggling an overwhelming number of different notions of continuity, convergence, smoothness and the like. ∀ and ∃ drew out the subtle distinctions that the blurry, imprecise words of the English language conspired to hide. They let me break down logic hairballs completely indigestible to my mammalian intuition into small chunks that I could individually process. Same idea as algebra. That's their purpose, and they're very good at it. Nothing I've encountered in the world of programming languages really comes close to doing their job. Don't fall in to the trap of assuming they're pointless just because they don't apply to your problems.
- kabdib 10y ago
  I use ∀ and ∃ and so forth, mostly in private notes. It's great shorthand. On the other hand, in MathLand we have conventions like saying "2x" when you want to multiply x by 2, but if you write "dx" you'd better know if you're doing calculus or not, because it means something totally different depending on context. Mathematical notation is pretty squishy. There are probably thousands of uses of every greek letter and their italic, bold and variously curlicue'd isomorphs. And it's mostly culture, with a lot of history, personalities and land-grabs thrown in. You can't necessarily crack open a paper without a lot of baggage-level context ("Oh yeah, this community uses brackets for things that community uses subscripts for, okay...") On the other hand, C++ is complicated and messy and also mostly a train wreck, but at least there's a standard you can go read. [I once thought it would be worthwhile to learn denotational semantics. The "at least one new hijacked hieroglyph must appear on every page" nature of the reading put me off it in short order. I had no idea where to start interpreting the notation other than maybe attending a class to get the proper starter culture. It was frustrating to see notation go in the "squishy" direction when I thought it should have been using something you could parse and run tools against. Oh well.]
  - 10y ago
zI48wj4rH9q8 10y ago
> that equation borders on parody in attempting to relay a rather simple concept. I can assure you the only parody I found was how simple it was compared to how big of a fuss is being made. The notation conveyed the concept of an onto function in exactly the right number of symbols. Every logic step was there, bared to the eye: A mapping from [1...N] to [1...N] such that for every output, there is an input that maps to it. As a sarcastic quip, what's so complicated about saying f[x]=y? (Equation wasn't the right word for you to use there). > We dont expect CS people to communicate concepts through compiled, machine language style syntax That is a complete misunderstanding of what this is. The symbols (and concepts) on this webpage are roughly equivalent to big-O notation in the Computer Science curriculum, in that they are taught in the first undergraduate course that tries to establish some theoretical basis for the subject.
- throwaway729 10y ago
  > As a sarcastic quip, what's so complicated about saying f[x]=y? IMO that line was the worst offender by far. Just use f(x), especially when you're giving an oral presentation to people who aren't familiar with the context in which the brackets are standards (TLA). Just because your formal system uses brackets for function application don't mean you need to obfuscate your slides.
yorwba 10y ago
> attempting to relay a rather simple concept This notation is not for relaying the concept of permutations, for that (good) mathematics textbooks would simply write this explanation in plain English. What the notation is good for is manipulating the notion of a permutation in a greater context, e.g. when you want to show that the functional composition of two permutations is itself a permutation, you can just replace this verbal description with the formal notation, shuffle around the symbols a bit, until you arrive at something that is obviously true. Try doing that using the verbose English description.

Ar-Curunir 10y ago

Because mathematics is a very dense language; building in redundancy does not scale when you're reading mathematics papers.

gravypod 10y ago
Would it make sense to say "building in redundancy does not scale when you're reading source code"? Not to me it doesn't.
- DollaWilliam 10y ago
  That's a false equivalency. Mathematics, in practice, is more of a domain specific language that encapsulates more and more precise information as you increase the level of abstraction. The levels of abstraction layer upon one another to be able to handle more complex concepts while retaining all of the underlying precision.
  - gravypod 10y ago
    > Mathematics, in practice, is more of a domain specific language that encapsulates more and more precise information as you increase the level of abstraction Isn't that the point of any DSL? Also, wasn't the advent of DSLs meant to make it easier for non-programmers to understand the flow of control in a system? I think generally the idea was to make things easier to understand by factoring out the complicated bits (implementation) and leveraging abstraction to provide clarity on top of an implementation. If this is the case for every DSL I and every other CS major designs, why should it not be the goal of every math major? Sure to you and many other math-centrist people these symbols are "how I learned it so it must be the best" but to everyone else it's difficult to grasp and hard to understand. The lingo is half the battle for most things but for math it seems like the lingo is the entire battle.
    - DollaWilliam 10y ago
      > The lingo is half the battle for most things but for math it seems like the lingo is the entire battle. There's a kernel of truth there. To abuse the DSL metaphor further, even mildly complicated mathematics concepts are only expressible using layer upon layer of ever-more-abstracted DSLs. Lower-level expansions of the building blocks to improve clarity for reading would be useless in practice, since mathematics is intended to be written and understood by humans and such an expansion would exceed our ability to keep the entire intended concept in our working memory. Proficiency in mathematics is proficiency with understanding and extending the lingo itself. Mathematics /is/ the lingo, which is why it can't be unraveled from it. >"how I learned it so it must be the best" Not at all. It is, however, a very practical approach to getting someone up to speed to be able to do actual mathematics (as opposed to the basic symbol manipulations that most people confuse with actual mathematics.)
- userbinator 10y ago
  It makes sense to me, although perhaps at a different level --- IMHO redundancy is bad in source code in general, and if you base your development methodologies and practices on assuming that it's not, you end up with things like Enterprise Java and C#: huge, eye-bleedingly verbose monstrosities to perform the simplest of tasks.
  - gravypod 10y ago
    Just as with everything there is a sweet spot. I personally feel some things need to stay verbose while some things are implementation and not inherently needed. Before college, I didn't do any python. After touching the language because of a class I like some of the things they do. For instance: for i in range(10): print(i) This is a great way to show a way to print 0-9 to stdout. This is great. Contrary to this, you have a more c-like method of writing this. for (int i = 0; i < 10; i++) printf("%d\n", i); This is the same code, but we have a lot more stuff here that convey a lot of meaning. This is fine for me. The construct is dense, but it's not overly dense. It is simple because once you see it the first time, you will understand it and it will always make sense to you no matter how many years pass. I'm fine with this extra verbosity. On the other side of the spectrum you have this: map(print, range(10)) This is far fewer characters, but it's more difficult to understand. There are more things to understand if you've never done any functional programming. This sort of dense solution is frowned upon in many cases, especially since this sort of thing rarely scales efficiently in the sense of cognitive load. I did all of my CS labs using map/reduce formulas for CS100 and it did nothing but make things harder and drive a large appreciation for expanding statements into my heart.
    - chaoxu 10y ago
      That map is doing an impure operation. The order of application matters. Otherwise, for people who learned functional programming from the start, it's much easier to understand.
    - witty_username 10y ago
      I find the map solution simpler than the for loop as there is no loop variable.
- Ar-Curunir 10y ago
  To clarify; mathematics talks about objects with increasing amounts of density; as you proceed up the abstraction stack into increasingly abstract topics, you need to be able to efficiently compress the topics you're already supposed to have mastered. Mathematics is for experts that have mastered the lower levels of the abstraction layer. You cannot study any subfield of math without having understood the basic definitions of the field. No amount of syntax rewriting is going to change that; those definitions are not going anywhere.
  - gravypod 10y ago
    "To clarify; software talks about objects with increasing amounts of complexity; as you proceed up the abstraction stack into increasingly abstract topics, you need to be able to efficiently compress the topics you're already supposed to have implemented." What I'd expect to follow here would be a statement about how your abstractions should be terse and verbose in the right ways. Terse in the implementation specific handling and verbose in the explanation of your abstract solution. "Software is for experts that have mastered the lower levels of the abstraction layer. You cannot study any subfield of systems programming without having understood the basic implementation of the underlying software. No amount of syntax rewriting is going to change that; those definitions are not going anywhere." I don't see how that statement would make any sense. I expect to be able to give anyone with the most basic of understandings of computers a piece of any code (from Assembly to high level Lisp code) from widely used software like the Linux kernel all the way to stock trading applications and I expect them to understand it by looking at it for a few seconds, reading the comments, and reading the names of the variables and functions. If the average person cannot do that, then it's bad code. Understand-ability is the only point of programming. To be understood by the computer and by a maintainer. I'd never say that obtuse notations for an abstraction should stay around. I'd replace the obtuse notation with a better abstraction.
    - yorwba 10y ago
      > I expect them to understand it by looking at it for a few seconds, reading the comments, and reading the names of the variables and functions. Mathematics also comes with comments, many papers essentially consists of one giant comment for the proof in the appendix. Granted, many variable names could be a bit less terse, but it's just easier to write "let f be an arbitrary function A -> B" once instead of using arbitraryFunctionMappingTheSetOf{DefinitionOfElementsOfA}toTheSetOf{DefinitionOfElementsOfB} every time.
- wfo 10y ago
  You don't need to read or understand (most of) your source code because it is 90% libraries. Mathematics is built based on understanding all the concepts behind a subject, and it's written to express to another human clear rigorous thought. You cannot just black box everything away and choose to ignore it the way programmers do with source code and libraries. The metric for success with a program is "does the machine run it properly". The metric for success with a piece of mathematics is "do people who've done some reading in my field understand my new result". You can cheat in one but not in the other.
  - gravypod 10y ago
    > You don't need to read or understand (most of) your source code because it is 90% libraries That's just plain incorrect. I expect all code to be written to standards of which would allow anyone to read. > Mathematics is built based on understanding all the concepts behind a subject, and it's written to express to another human clear rigorous thought. Isn't abstraction designed to avoid this? To remove a solution from a problem domain? To work on it without integral knowledge of all; applications? If not then all of Computer Science has been doing it wrong. > You cannot just black box everything away and choose to ignore it the way programmers do with source code and libraries. We don't do that. We black box things that aren't related to the problem at hand by referring to them in a terse and understandable way. For instance if I want to use a fork join scheduler for parallel thread scheduler I don't need to write out all the code for a fork join scheduler. I just need to say "You probably know what this is, if not it's called a fork join scheduler and I'll interact with it via sending messages of run, runAll, etc" and be done with it. I wont use an obscure Greek letter to notate a Fork-Join as that's archaic and insane. > The metric for success with a program is "does the machine run it properly". The metric for success with a piece of mathematics is "do people who've done some reading in my field understand my new result". You can cheat in one but not in the other. The KPIs for software are as follows: functionality, maintainability, simplicity. In that order. There is no single goal of software but instead a multifaceted set of goals constantly working against each other yet CS people make room for an even balance. I don't see how this relates to you engaging in proving further information from other information. I don't see why math needs 40 non-terminal characters to type out a proof. I don't see why it can't be written in a way that is more approachable while not detrimental to the performance of current professionals. I also find it unfathomable that someone would think that the current way of doing things is the, all together, best way of doing things because that points a blind eye at the other two things I mentioned: "maintainability, simplicity". I wouldn't call any of the advanced math world "simple" or "maintainable".
delinka 10y ago
Dense and high-level. Like programming languages. You take a group of machine operations and represent those with an operator in a programming language. You take a group of programming statements, expressions, etc and represent them with a procedure. Group some procedures together into a category (or perhaps a 'class' of items.) Take a few lines of COBOL, compile it, and how much actual machine work does that represent? Lots. Very dense.

ajmurmann 10y ago

I think the goal of mathematical notation is precision rather than ambiguity. Yes, the example seems awfully complicated for what simple thing it's trying to state. However, if you read it out loud it still sounds complicated. It's a simple concept, but it's hard to communicate without room for ambiguity.

paulftw 10y ago
How do we know if the solution they chose to achieve that goal is the most efficient one? How did that notation evolve? Has it evolved at all? What if it's just a design by committee, with decisions made in the 17th century still affecting how modern papers are written? What if we think of the rulebook on "how to write math" as a codebase? Would it be a 3-4 centuries old codebase without any major refactorings done, ever?
- deleted 10y ago
  [deleted]
- pron 10y ago
  Notation has steadily advanced towards the more precise and concise, because it helps. Watch this interesting Lamport talk about the changes in notation: http://www.heidelberg-laureate-forum.org/blog/video/lecture-tuesday-september-23-2014-leslie-lamport/ http://www.heidelberg-laureate-forum.org/blog/video/lecture-...

billsix 10y ago

"Is an element of the set" "for all" "there exists". It's automata and computational theory 201, not parody

deleted 10y ago

[deleted]

jjoonathan 10y ago

∀+∃+{|} are the epitome of clarity over compression. Mathematicians like them for the same reason why many programmers like sophisticated static typing. They might not always improve the clarity of toy examples to beginners, but they certainly help improve the clarity of untamed, wart-ridden, real life problems to initiates. I think the first time I truly appreciated the power of ∀ and ∃ was during functional analysis when I found myself juggling an overwhelming number of different notions of continuity, convergence, smoothness and the like. ∀ and ∃ drew out the subtle distinctions that the blurry, imprecise words of the English language conspired to hide. They let me break down logic hairballs completely indigestible to my mammalian intuition into small chunks that I could individually process. Same idea as algebra. That's their purpose, and they're very good at it. Nothing I've encountered in the world of programming languages really comes close to doing their job. Don't fall in to the trap of assuming they're pointless just because they don't apply to your problems.

kabdib 10y ago
I use ∀ and ∃ and so forth, mostly in private notes. It's great shorthand. On the other hand, in MathLand we have conventions like saying "2x" when you want to multiply x by 2, but if you write "dx" you'd better know if you're doing calculus or not, because it means something totally different depending on context. Mathematical notation is pretty squishy. There are probably thousands of uses of every greek letter and their italic, bold and variously curlicue'd isomorphs. And it's mostly culture, with a lot of history, personalities and land-grabs thrown in. You can't necessarily crack open a paper without a lot of baggage-level context ("Oh yeah, this community uses brackets for things that community uses subscripts for, okay...") On the other hand, C++ is complicated and messy and also mostly a train wreck, but at least there's a standard you can go read. [I once thought it would be worthwhile to learn denotational semantics. The "at least one new hijacked hieroglyph must appear on every page" nature of the reading put me off it in short order. I had no idea where to start interpreting the notation other than maybe attending a class to get the proper starter culture. It was frustrating to see notation go in the "squishy" direction when I thought it should have been using something you could parse and run tools against. Oh well.]
- 10y ago

zI48wj4rH9q8 10y ago

> that equation borders on parody in attempting to relay a rather simple concept. I can assure you the only parody I found was how simple it was compared to how big of a fuss is being made. The notation conveyed the concept of an onto function in exactly the right number of symbols. Every logic step was there, bared to the eye: A mapping from [1...N] to [1...N] such that for every output, there is an input that maps to it. As a sarcastic quip, what's so complicated about saying f[x]=y? (Equation wasn't the right word for you to use there). > We dont expect CS people to communicate concepts through compiled, machine language style syntax That is a complete misunderstanding of what this is. The symbols (and concepts) on this webpage are roughly equivalent to big-O notation in the Computer Science curriculum, in that they are taught in the first undergraduate course that tries to establish some theoretical basis for the subject.

throwaway729 10y ago
> As a sarcastic quip, what's so complicated about saying f[x]=y? IMO that line was the worst offender by far. Just use f(x), especially when you're giving an oral presentation to people who aren't familiar with the context in which the brackets are standards (TLA). Just because your formal system uses brackets for function application don't mean you need to obfuscate your slides.

yorwba 10y ago

> attempting to relay a rather simple concept This notation is not for relaying the concept of permutations, for that (good) mathematics textbooks would simply write this explanation in plain English. What the notation is good for is manipulating the notion of a permutation in a greater context, e.g. when you want to show that the functional composition of two permutations is itself a permutation, you can just replace this verbal description with the formal notation, shuffle around the symbols a bit, until you arrive at something that is obviously true. Try doing that using the verbose English description.