Alternatives to the physics package
The physics package is useful
A lot of my LaTeX documents make heavy use of the physics package. Aside from it overloading several standard commands (e.g. sin, abs, etc.), it also makes a few abbreviations very convenient (e.g. order). It also makes typesetting vector calculus, ordinary/partial/variational derivatives, linear algebra (bra-ket notation and matrices), and other areas much less painful. I think it's safe to say it fills a gap in the market.
The physics package is unpopular
Despite the advantages I've listed from using the package, there are some short comings. It makes use of xparse which can give several spacing issues (these are usually edge cases but aren't too uncommon), and the syntax can be counter-intuitive. Because of this, whenever I (or others) post a problem that involves the package, a frequent theme is to give physics a wide berth:
Considering the quality of the implementation, the best way to fix this issue is by not using the physics package, Henri Menke.
My best advice is to keep at arm's length from physics, egreg.
(I am sure there are likely more unfavourable reviews of the package out there).
What alternatives are there?
I am curious to know what people think good alternatives are? Off the top of my head:
- Keep on using physics and hope the macros are improved (unlikely?).
- Try to re-write the few macros I use most often, but better (I doubt my implementation would be great).
- There is another equivalent package already which addresses these issues which I haven't found yet.
- Type it all out in full and abandon all hope of convenient math macros.
While the last option is a bit melodramatic, I think the overarching question of: "Is it preferable to use a supported package which is not ideal/buggy, or should I try and re-invent the wheel?" is one I encounter a fair bit when considering packages. My current ethos is to always use a package/module, and never re-invent the wheel. What would more proficient/experienced users recommend?
macros packages best-practices package-writing physics
add a comment |
The physics package is useful
A lot of my LaTeX documents make heavy use of the physics package. Aside from it overloading several standard commands (e.g. sin, abs, etc.), it also makes a few abbreviations very convenient (e.g. order). It also makes typesetting vector calculus, ordinary/partial/variational derivatives, linear algebra (bra-ket notation and matrices), and other areas much less painful. I think it's safe to say it fills a gap in the market.
The physics package is unpopular
Despite the advantages I've listed from using the package, there are some short comings. It makes use of xparse which can give several spacing issues (these are usually edge cases but aren't too uncommon), and the syntax can be counter-intuitive. Because of this, whenever I (or others) post a problem that involves the package, a frequent theme is to give physics a wide berth:
Considering the quality of the implementation, the best way to fix this issue is by not using the physics package, Henri Menke.
My best advice is to keep at arm's length from physics, egreg.
(I am sure there are likely more unfavourable reviews of the package out there).
What alternatives are there?
I am curious to know what people think good alternatives are? Off the top of my head:
- Keep on using physics and hope the macros are improved (unlikely?).
- Try to re-write the few macros I use most often, but better (I doubt my implementation would be great).
- There is another equivalent package already which addresses these issues which I haven't found yet.
- Type it all out in full and abandon all hope of convenient math macros.
While the last option is a bit melodramatic, I think the overarching question of: "Is it preferable to use a supported package which is not ideal/buggy, or should I try and re-invent the wheel?" is one I encounter a fair bit when considering packages. My current ethos is to always use a package/module, and never re-invent the wheel. What would more proficient/experienced users recommend?
macros packages best-practices package-writing physics
6
You have a very good point. I for myself have decided to write a few macros on my own, and not to use thephysicspackage. Yet I would love to see a package that really does what physics promises to do.
– marmot
Jan 23 at 17:12
3
I've never looked at the code or used it, but the documentation left me feeling this was more "a collection of stuff that seemed like a good idea when we wrote it" rather than a coherent solution to a well defined problem. When I have produced "physics-like" documents, I've just defined a few simple macros to save repetition, and never really felt the need for more than that.
– alephzero
Jan 23 at 17:26
1
For everybody interested in a (hopefully eventually) viable alternative tophysics: You are welcome to contribute to physics replacement effort. Also it was brought to my attention that thediffcoeffpackage might fill the gap partly.
– Skillmon
Jan 24 at 8:33
1
Additionally to thediffcoeffpackage, there is also thebraketpackage, which provides macros for Dirac bra-ket notation.
– Skillmon
Jan 24 at 18:05
add a comment |
The physics package is useful
A lot of my LaTeX documents make heavy use of the physics package. Aside from it overloading several standard commands (e.g. sin, abs, etc.), it also makes a few abbreviations very convenient (e.g. order). It also makes typesetting vector calculus, ordinary/partial/variational derivatives, linear algebra (bra-ket notation and matrices), and other areas much less painful. I think it's safe to say it fills a gap in the market.
The physics package is unpopular
Despite the advantages I've listed from using the package, there are some short comings. It makes use of xparse which can give several spacing issues (these are usually edge cases but aren't too uncommon), and the syntax can be counter-intuitive. Because of this, whenever I (or others) post a problem that involves the package, a frequent theme is to give physics a wide berth:
Considering the quality of the implementation, the best way to fix this issue is by not using the physics package, Henri Menke.
My best advice is to keep at arm's length from physics, egreg.
(I am sure there are likely more unfavourable reviews of the package out there).
What alternatives are there?
I am curious to know what people think good alternatives are? Off the top of my head:
- Keep on using physics and hope the macros are improved (unlikely?).
- Try to re-write the few macros I use most often, but better (I doubt my implementation would be great).
- There is another equivalent package already which addresses these issues which I haven't found yet.
- Type it all out in full and abandon all hope of convenient math macros.
While the last option is a bit melodramatic, I think the overarching question of: "Is it preferable to use a supported package which is not ideal/buggy, or should I try and re-invent the wheel?" is one I encounter a fair bit when considering packages. My current ethos is to always use a package/module, and never re-invent the wheel. What would more proficient/experienced users recommend?
macros packages best-practices package-writing physics
The physics package is useful
A lot of my LaTeX documents make heavy use of the physics package. Aside from it overloading several standard commands (e.g. sin, abs, etc.), it also makes a few abbreviations very convenient (e.g. order). It also makes typesetting vector calculus, ordinary/partial/variational derivatives, linear algebra (bra-ket notation and matrices), and other areas much less painful. I think it's safe to say it fills a gap in the market.
The physics package is unpopular
Despite the advantages I've listed from using the package, there are some short comings. It makes use of xparse which can give several spacing issues (these are usually edge cases but aren't too uncommon), and the syntax can be counter-intuitive. Because of this, whenever I (or others) post a problem that involves the package, a frequent theme is to give physics a wide berth:
Considering the quality of the implementation, the best way to fix this issue is by not using the physics package, Henri Menke.
My best advice is to keep at arm's length from physics, egreg.
(I am sure there are likely more unfavourable reviews of the package out there).
What alternatives are there?
I am curious to know what people think good alternatives are? Off the top of my head:
- Keep on using physics and hope the macros are improved (unlikely?).
- Try to re-write the few macros I use most often, but better (I doubt my implementation would be great).
- There is another equivalent package already which addresses these issues which I haven't found yet.
- Type it all out in full and abandon all hope of convenient math macros.
While the last option is a bit melodramatic, I think the overarching question of: "Is it preferable to use a supported package which is not ideal/buggy, or should I try and re-invent the wheel?" is one I encounter a fair bit when considering packages. My current ethos is to always use a package/module, and never re-invent the wheel. What would more proficient/experienced users recommend?
macros packages best-practices package-writing physics
macros packages best-practices package-writing physics
asked Jan 23 at 16:37
oliversmoliversm
442312
442312
6
You have a very good point. I for myself have decided to write a few macros on my own, and not to use thephysicspackage. Yet I would love to see a package that really does what physics promises to do.
– marmot
Jan 23 at 17:12
3
I've never looked at the code or used it, but the documentation left me feeling this was more "a collection of stuff that seemed like a good idea when we wrote it" rather than a coherent solution to a well defined problem. When I have produced "physics-like" documents, I've just defined a few simple macros to save repetition, and never really felt the need for more than that.
– alephzero
Jan 23 at 17:26
1
For everybody interested in a (hopefully eventually) viable alternative tophysics: You are welcome to contribute to physics replacement effort. Also it was brought to my attention that thediffcoeffpackage might fill the gap partly.
– Skillmon
Jan 24 at 8:33
1
Additionally to thediffcoeffpackage, there is also thebraketpackage, which provides macros for Dirac bra-ket notation.
– Skillmon
Jan 24 at 18:05
add a comment |
6
You have a very good point. I for myself have decided to write a few macros on my own, and not to use thephysicspackage. Yet I would love to see a package that really does what physics promises to do.
– marmot
Jan 23 at 17:12
3
I've never looked at the code or used it, but the documentation left me feeling this was more "a collection of stuff that seemed like a good idea when we wrote it" rather than a coherent solution to a well defined problem. When I have produced "physics-like" documents, I've just defined a few simple macros to save repetition, and never really felt the need for more than that.
– alephzero
Jan 23 at 17:26
1
For everybody interested in a (hopefully eventually) viable alternative tophysics: You are welcome to contribute to physics replacement effort. Also it was brought to my attention that thediffcoeffpackage might fill the gap partly.
– Skillmon
Jan 24 at 8:33
1
Additionally to thediffcoeffpackage, there is also thebraketpackage, which provides macros for Dirac bra-ket notation.
– Skillmon
Jan 24 at 18:05
6
6
You have a very good point. I for myself have decided to write a few macros on my own, and not to use the
physics package. Yet I would love to see a package that really does what physics promises to do.– marmot
Jan 23 at 17:12
You have a very good point. I for myself have decided to write a few macros on my own, and not to use the
physics package. Yet I would love to see a package that really does what physics promises to do.– marmot
Jan 23 at 17:12
3
3
I've never looked at the code or used it, but the documentation left me feeling this was more "a collection of stuff that seemed like a good idea when we wrote it" rather than a coherent solution to a well defined problem. When I have produced "physics-like" documents, I've just defined a few simple macros to save repetition, and never really felt the need for more than that.
– alephzero
Jan 23 at 17:26
I've never looked at the code or used it, but the documentation left me feeling this was more "a collection of stuff that seemed like a good idea when we wrote it" rather than a coherent solution to a well defined problem. When I have produced "physics-like" documents, I've just defined a few simple macros to save repetition, and never really felt the need for more than that.
– alephzero
Jan 23 at 17:26
1
1
For everybody interested in a (hopefully eventually) viable alternative to
physics: You are welcome to contribute to physics replacement effort. Also it was brought to my attention that the diffcoeff package might fill the gap partly.– Skillmon
Jan 24 at 8:33
For everybody interested in a (hopefully eventually) viable alternative to
physics: You are welcome to contribute to physics replacement effort. Also it was brought to my attention that the diffcoeff package might fill the gap partly.– Skillmon
Jan 24 at 8:33
1
1
Additionally to the
diffcoeff package, there is also the braket package, which provides macros for Dirac bra-ket notation.– Skillmon
Jan 24 at 18:05
Additionally to the
diffcoeff package, there is also the braket package, which provides macros for Dirac bra-ket notation.– Skillmon
Jan 24 at 18:05
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f471532%2falternatives-to-the-physics-package%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f471532%2falternatives-to-the-physics-package%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
6
You have a very good point. I for myself have decided to write a few macros on my own, and not to use the
physicspackage. Yet I would love to see a package that really does what physics promises to do.– marmot
Jan 23 at 17:12
3
I've never looked at the code or used it, but the documentation left me feeling this was more "a collection of stuff that seemed like a good idea when we wrote it" rather than a coherent solution to a well defined problem. When I have produced "physics-like" documents, I've just defined a few simple macros to save repetition, and never really felt the need for more than that.
– alephzero
Jan 23 at 17:26
1
For everybody interested in a (hopefully eventually) viable alternative to
physics: You are welcome to contribute to physics replacement effort. Also it was brought to my attention that thediffcoeffpackage might fill the gap partly.– Skillmon
Jan 24 at 8:33
1
Additionally to the
diffcoeffpackage, there is also thebraketpackage, which provides macros for Dirac bra-ket notation.– Skillmon
Jan 24 at 18:05