- Notifications
You must be signed in to change notification settings - Fork 133
equations revamped #483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
equations revamped #483
Conversation
| First PDF in this branch: |
| fixes #470 |
| Julie requested some space between ) and x. There were five occurrences of this in 2.5.3. I have added a "think space" using , between ) and x: Not sure if this is a good move. Here is the result. See pages 180 and 184 (including footnote 55). Here is the resulting sicpjs.pdf of this branch: |
| @TobiasWrigstad can you review this PR? |
| @martin-henz I liked the thin spaces but it seems they were removed almost immediately? How come? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think everything looks good. I liked the thin spaces, but I suspect there is a good reason to remove them. And it is certainly readable both with and without.
| \[k_1f(n) \leq R(n) \leq k_2f(n)\] | ||
| \[ | ||
| \begin{array}{lll} | ||
| k_1f(n) & \leq & R(n) \quad \leq \quad k_2f(n) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very minor comment: the subscripts of k overlap with the serif of the f. Moving from k_1 and k_2 to e.g. k and k' would solve this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not proposing that we make that change. Just pointing it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added thin spaces , after k_1 and k_2 to avoid the overlap. This now looks the same as in SICP.
| {\left[ (y+1)x^2 +(y^2 +1)x+(y-1)\right]\cdot \left[(y-2) | ||
| x+(y^3 +7)\right]} | ||
| \begin{array}{l} | ||
| {\left[ (y+1)x^2 +(y^2 +1)x+(y-1)\right]\cdot \left[(y-2)x+(y^3 +7)\right]} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought the thin space looked good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the explanation is in the email. Let's LaTeX do this and not micro-manage, unless we have to, as in the case of k_1 f(...) and k_2 f(...)
| propagates its value through the network as described above. This | ||
| sets <SCHEMEINLINE>F</SCHEMEINLINE> to 77, which is reported by the probe | ||
| on <SCHEMEINLINE>F</SCHEMEINLINE>. | ||
| on<SPACE/><SCHEMEINLINE>F</SCHEMEINLINE>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good addition with the hard space.
| Then the required stream may be constructed with | ||
| <SCHEMEINLINE>merge</SCHEMEINLINE>, as follows: | ||
| <SNIPPET EVAL="no" LATEX="yes" POSTPADDING="no"> | ||
| <SNIPPET EVAL="no" LATEX="yes"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching this one!
| Sorry about the delay. |
Not sure how "thin spaces" disappeared. Is it because we moved to "array" instead of just [ ]? |
Ah, yes. The reason is in the emails. I want to let LaTeX take care of the spacing. Manually inserting them seems like an overkill to me. We would have to go through the whole book to get a uniform manual spacing. That would be a waste of time, I think. An exception: When LaTeX does an obviously poor job, as in the case of k_1 f(...) and k_2 f(...). |
No description provided.