Intent notes for "Schaum's outline of theory and problems of mathematics for physics students"

intent.md

Schaum's outline of theory and problems of mathematics for physics students

Concepts with notations (are they within Intent Core?)

1. plus
2. minus
3. times
4. divide
5. divisible-by
6. equal
7. not-equal
8. smaller-than
9. greater-than
10. smaller-or-equal
11. greater-or-equal
12. power
13. square-root
14. root
15. ellipsis
16. vertical-ellipsis
17. pair
18. tuple
19. percent
20. ratio
21. repeating-decimal
22. point
23. gcd (greatest-common-divisor)
24. lcd (least-common-denominator)
25. absolute-value
26. limit lim
27. tends-to
28. defined-as (line defined via equation, e.g. l : 2x + 1 = 0)
29. index
30. circled (used around <mn> numbers in "successive remainder" of a derivation)
31. imaginary-unit
32. infinity
33. evaluated-at
34. partial-derivative
35. first-derivative
36. second-derivative
37. third-derivative
38. derivative
39. differential
40. open-interval
41. closed-interval
42. open-closed-interval
43. closed-open-interval
44. integral
45. indefinite-integral
46. definite-integral
47. summation
48. factorial
49. combination
50. probability
51. set
52. intersection
53. union
54. sine
55. cosine
56. tangent
57. cotangent
58. secant
59. cosecant
60. arcsine
61. arccosine
62. arctangent
63. arccotangent
64. arcsecant
65. arccosecant
66. hyperbolic-sine
67. hyperbolic-cosine
68. hyperbolic-tangent
69. hyperbolic-cotangent
70. hyperbolic-secant
71. hyperbolic-cosecant
72. ray
73. directed-line-segment
74. segment
75. line
76. angle
77. inverse
78. name (do we use _($piece1,$piece2,...$piecen) or name($piece1,...)?)
79. logarithm
80. natural-logarithm
81. pi
82. cross-product (vector-product)
83. defined-as
84. vector
85. magnitude
86. scalar-product (dot-product)
87. polar-coordinate
88. determinant
89. binomial-coefficient
90. congruent
91. triple-of-direction-cosines (just triple?)
92. floor
93. ceiling
94. euler-number
95. Q: list-of-lists? e.g. (1,6; 6,1; 2,5; 5,2; 3,4; 4,3)
96. del-operator (used for gradient, diverge and curl, wiki)

Misc

1. list-separator
2. time-separator
3. interval-separator
4. where-separator ( : such-that?)

• some uses of ↔ and → which had unclear terminology, used in physics relationships
  • would have been equilibrium and yields in chemistry
  • or potentially if-and-only-if and maps-to in mathematics
  • but I am not sure what the physics nomenclature is

Units

1. foot ft

2. pound lbs

3. radian rad

4. meter m

5. kilometer km

6. centimeter cm

7. hour hr, h

8. year yr

9. minute min , ′

10. second s, ′′

11. dollar $

12. degree °

13. kelvin K

14. celsius C

15. fahrenheit F

16. mile mi

17. east E

18. west W

19. north N

20. south S

21. per s^{-1} ( "per second"? discussion)

22. Appendix B: table of 24 unit conversions

    • 

23. Appendix C,E: physical constants

    • speed-of-light, gravitational-constant, electron-mass, proton-mass, neutron-mass, electron-charge, plancks-constant, permitivity-constant, permeability-constant, bohr-radius
    • gravity-of-earth-surface, equatorial-radius-of-earth,
    • 

24. Greek prefixes:

    • atto, femto, pico, nano, micro, milli, centi, deci, deka, hecto, kilo, mega, giga, tera, peta

physics

1. fermi fm
2. farad F
3. microfarad μF
4. coulomb C
5. volt V
6. kilovolt kV
7. ampere A
8. watt W
9. joule J
10. newton N
11. ohm Ω
12. hertz Hz
13. siemens S
14. henry H
15. milligram mg
16. microampere mA

chemistry

1. atomic-mass {}^{227} Ac
2. isotope C^{14}

PROPERTIES

1. :quotient
2. :system-of-equations
   • Note: there is also a curious use of a matrix with a vertical border writing only the coefficients in each <tr>, the rest being understood
3. :group
   • parentheticals? Or is it intent values of paren-group, bracket-group, brace-group,...
4. :charge (e.g. +q in physics)
5. :permutation
6. :matrix
7. :chemical-formula
8. :unit

409 pages, as read through the New York Public Library e-book (with all complex math as PNG images).

A Google Books preview is available at:
https://www.google.com/books/edition/Schaum_s_Outline_of_Mathematics_for_Phys/co2syTUu-_cC?hl=en&gbpv=1

"Schaum's outline" -- takes me back to my undergraduate days where we used it (I can't remember for what topics). Or maybe it was high school. It was a looong time ago.

FYI: units. It's something not yet part of MathCAT, but since it appears we have settled on :unit, I should work on adding them one of these days. MathPlayer has 21 prefixes (yotta...yocto) and about 100 SI units, derived units, and English units, time units (e.g, "yr", "wk"), and a few others. It has both the abbreviation and the spoken (spelled out) name. Lots of translations also. No "fermi" though. The MathPlayer list is what I would use to seed my list for MathCAT and maybe the spec if we really want to list a bunch of units.

I think for chemistry, atomic-mass and isotope are both covered by the :ChemicalElement property as would ions.

Can you give an example of something covered by :group?

atomic-mass and isotope are both covered by the :ChemicalElement property

The spec text and guidelines w.r.t Core currently do not contain text about "concept inclusion in Core based on a property".
We may want to add that, but I suspect I will ask to then catalog which concepts are implied by a property as documentation to each Core property. Hard to predict otherwise.

I also don't recall if we clearly specified the "lowercase dash-case" rule, so that what you wrote switches from :ChemicalElement to :chemical-element.

Can you give an example of something covered by :group?

I was fishing for the briefest possible name, not sure :group was the best choice.
We discussed how to annotate the special meanings of () [] {} groups, but not how to annotate their original fencing/grouping/parenthetical meaning, which just "groups together" arguments and sub-expressions.

So something like a classic use of:

$$ f \left\{ \frac{2 [ x \times (y-z) ]}{x} , \frac{ 3 [ y \times (x-z)]}{y} \right\} = 0 $$

where each use of () [] {} is meant for simple grouping (of precedence or arguments) and has no special standalone meaning.

btw @NSoiffer note that units can be ambiguous to "guess" from the :unit annotation.
The examples from just this book are - as listed above:

• both coulomb and celsius use the capital C letter.
• both siemens and south use capital S
• both newton and north use capital N
• both fahrenheit and farad use capital F
• both west and watt use capital W

I'm sure there are other examples, this is just one book.

Edit: a potential way out is to introduce more properties. for the compass directions, there is a term of cardinal direction, which can lead to a :cardinal-direction property.

Similarly for :si-unit and :imperial-unit. But coulomb and celsius are both used in SI, so one may even need :temperature. A slippery slope of adding ever more granular properties...

I'm impressed you found some conflicts. MathPlayer doesn't support compass directions, so those weren't a problem. They really aren't units, so having a different property makes sense.

As for C and F, the "out" I used is that they often are preceded by a degree sign, so that was required to get it right. Not everyone uses ℃/℉ (U+2103/U+2109 or a two char sequence), but it is a way to resolve that conflict.

If you find more, I'd love to know about them to see if there is a workaround or not.

@NSoiffer great if they can be resolved with a clear organization.

To me these kinds of concerns are great markers for what should be getting well-documented in the Core Concept/Properties lists, to increase their usability.

For example, stating that "the two Celsius notations that will be guessed via :unit are the U+2103 character, as well as °C (U+00B0 U+0043)". The 2-char variant is what is currently used in e.g. the wiki page on Celsius.

Edit: broader scope for my example text.
Edit2: And I guess we should even call out the exact MathML markup expected, since here <mi>°C</mi> and <mo>°</mo><mi>C</mi>, and then <mo>°C</mo> are distinctly different. Is only one correct?

I think many properties require more discussion than concept names because of their more nebulous nature: they aren't "say the name and the arguments, potentially modified by a fixity property. So yes, I agree we need to write documentation describing their intended usage.

However, picking up on your "Is only one correct?" comment: there is better and worse MathML and I suspect (we don't have experience), there is better and worse usage of intent and properties. I think it is almost always better to use a Unicode char for a purpose than to put together multiple characters for it (exceptions include the super-scripted numbers). So I would recommend <mi>°C</mi> as the form that is documented as that is a unit. <mo>°</mo><mi>C</mi> together is a unit, but neither separately is one, so I think the unit property would be on a containing mrow (which probably won't get generated by software). Actually what I said isn't true. <mo>°</mo> could be a measure of angle, so it could be a unit, but it is a very different unit than °C.

There is software that may not generate wrapping mrows, but there are clear examples of software that already do generate wrapping mrows (latexml is one). So we ought to expect both, if they aren't clearly wrong uses of the spec.

To distill a complete motivating example, we'd need to answer if:

<!-- this should always work in Core -->
<mrow intent="celsius">
  <mo>°</mo><mi>C</mi>
</mrow>
<mi intent="celsius">℃</mi>
<mi intent="celsius">°C</mi>
<mo intent="celsius">°C</mo>

<!-- should this work in Core? -->
<mrow intent=":unit">
  <mo>°</mo><mi>C</mi>
</mrow>
<mi intent=":unit">℃</mi>
<mi intent=":unit">°C</mi>
<mo intent=":unit">°C</mo>

The first four terms should always work for the concept name, but the last one is poor MathML because Celsius is not an operator, and in general, units are not operators. Actually, several of them are poor MathML (see later).

The :unit cases are more of a judgement call as to what we want to say. MathCAT goes through a repair process. It likely would repair something with <mo intent=":unit"> to be an mi and probably also repair the two character °C to be the single character ℃. I suspect I would also repair the <mrow> to be the single char mi while I was at it. The goal of the repair is present the matching rules with a single thing to match against. I doubt other software would do the same. So the judgement call is whether we expect generating software to generate just one of the forms or whether we require the consuming software to do more work and consume all of the possible forms including this one not mentioned:

<mrow intent=":unit">
  <mo>°</mo><mo>C</mo>
</mrow>

and some not mentioned that "incorrectly" use mtext (which happens because that's a way to get a non-italic 'C'). I think it comes down to whether we want to be more strict in what is appropriate MathML when using intent properties or whether we want to continue the very laissez faire attitude that MathML has traditionally had.

Not to nitpick, but the MathML you used isn't really correct. When mi is used, it should be (for example)

<mi mathvariant="normal" intent="celsius">℃</mi>

Also, when ° is used, it should be a superscript . So that's even more things that potentially we might require AT to recognize.

Thank you for the extended detail. This is exactly the kind of information we should include in whichever note describes :unit and other properties like it, so that they can be both generated and consumed with some confidence.