Using FP package to compute sum breaks: FP error: UPN stack is empty!
up vote
6
down vote
favorite
I am trying to sum up entries in a table and thought using the fp
package was the way to go. The MWE below,
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-8,000.00}
yields:
as expected. However, splitting the -8,000 into two steps breaks things:
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}% <--- Why this break things?
which should yield the same result instead produces the error:
FP error: UPN stack is empty!.
FP@errmessage #1->errmessage {FP error: #1!}
l.25 AddToTotal{-1,000.00}
% <--- Why this break things?
Should I be using a different package for this? I only need 2 digits of precision, so perhaps there are better options.
Code:
documentclass{article}
usepackage{xstring}
usepackage{siunitx}
usepackage{fp}
newcommand*{Total}{0.00}% Initial Value
newcommand*{AddToTotal}[1]{%
StrDel{#1}{,}[NewAmount]%
FPevalTempTotal{Total+NewAmount}%
xdefTotal{TempTotal}%
%% --------
par
After adding $NewAmount$, total is num[round-mode=places,round-precision=2]{Total}.%
}%
begin{document}
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}% <--- Why this break things?
end{document}
fp
add a comment |
up vote
6
down vote
favorite
I am trying to sum up entries in a table and thought using the fp
package was the way to go. The MWE below,
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-8,000.00}
yields:
as expected. However, splitting the -8,000 into two steps breaks things:
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}% <--- Why this break things?
which should yield the same result instead produces the error:
FP error: UPN stack is empty!.
FP@errmessage #1->errmessage {FP error: #1!}
l.25 AddToTotal{-1,000.00}
% <--- Why this break things?
Should I be using a different package for this? I only need 2 digits of precision, so perhaps there are better options.
Code:
documentclass{article}
usepackage{xstring}
usepackage{siunitx}
usepackage{fp}
newcommand*{Total}{0.00}% Initial Value
newcommand*{AddToTotal}[1]{%
StrDel{#1}{,}[NewAmount]%
FPevalTempTotal{Total+NewAmount}%
xdefTotal{TempTotal}%
%% --------
par
After adding $NewAmount$, total is num[round-mode=places,round-precision=2]{Total}.%
}%
begin{document}
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}% <--- Why this break things?
end{document}
fp
...I'd suggest usingxfp
rather thanfp
.
– Werner
Nov 18 at 3:48
@Werner: Is that better? Do I need to change the macros?
– Peter Grill
Nov 18 at 3:53
1
It's just more convenient to use since it can be used in expansion, likexdefTotal{fpeval{<fp>}}
; it also works well with dimension calculations.
– Werner
Nov 18 at 3:58
@Werner: Thanks. Looks like that does not have this specfic issue thatfp
has.
– Peter Grill
Nov 18 at 4:13
add a comment |
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I am trying to sum up entries in a table and thought using the fp
package was the way to go. The MWE below,
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-8,000.00}
yields:
as expected. However, splitting the -8,000 into two steps breaks things:
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}% <--- Why this break things?
which should yield the same result instead produces the error:
FP error: UPN stack is empty!.
FP@errmessage #1->errmessage {FP error: #1!}
l.25 AddToTotal{-1,000.00}
% <--- Why this break things?
Should I be using a different package for this? I only need 2 digits of precision, so perhaps there are better options.
Code:
documentclass{article}
usepackage{xstring}
usepackage{siunitx}
usepackage{fp}
newcommand*{Total}{0.00}% Initial Value
newcommand*{AddToTotal}[1]{%
StrDel{#1}{,}[NewAmount]%
FPevalTempTotal{Total+NewAmount}%
xdefTotal{TempTotal}%
%% --------
par
After adding $NewAmount$, total is num[round-mode=places,round-precision=2]{Total}.%
}%
begin{document}
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}% <--- Why this break things?
end{document}
fp
I am trying to sum up entries in a table and thought using the fp
package was the way to go. The MWE below,
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-8,000.00}
yields:
as expected. However, splitting the -8,000 into two steps breaks things:
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}% <--- Why this break things?
which should yield the same result instead produces the error:
FP error: UPN stack is empty!.
FP@errmessage #1->errmessage {FP error: #1!}
l.25 AddToTotal{-1,000.00}
% <--- Why this break things?
Should I be using a different package for this? I only need 2 digits of precision, so perhaps there are better options.
Code:
documentclass{article}
usepackage{xstring}
usepackage{siunitx}
usepackage{fp}
newcommand*{Total}{0.00}% Initial Value
newcommand*{AddToTotal}[1]{%
StrDel{#1}{,}[NewAmount]%
FPevalTempTotal{Total+NewAmount}%
xdefTotal{TempTotal}%
%% --------
par
After adding $NewAmount$, total is num[round-mode=places,round-precision=2]{Total}.%
}%
begin{document}
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}% <--- Why this break things?
end{document}
fp
fp
edited Nov 18 at 2:59
asked Nov 17 at 23:55
Peter Grill
163k24432742
163k24432742
...I'd suggest usingxfp
rather thanfp
.
– Werner
Nov 18 at 3:48
@Werner: Is that better? Do I need to change the macros?
– Peter Grill
Nov 18 at 3:53
1
It's just more convenient to use since it can be used in expansion, likexdefTotal{fpeval{<fp>}}
; it also works well with dimension calculations.
– Werner
Nov 18 at 3:58
@Werner: Thanks. Looks like that does not have this specfic issue thatfp
has.
– Peter Grill
Nov 18 at 4:13
add a comment |
...I'd suggest usingxfp
rather thanfp
.
– Werner
Nov 18 at 3:48
@Werner: Is that better? Do I need to change the macros?
– Peter Grill
Nov 18 at 3:53
1
It's just more convenient to use since it can be used in expansion, likexdefTotal{fpeval{<fp>}}
; it also works well with dimension calculations.
– Werner
Nov 18 at 3:58
@Werner: Thanks. Looks like that does not have this specfic issue thatfp
has.
– Peter Grill
Nov 18 at 4:13
...I'd suggest using
xfp
rather than fp
.– Werner
Nov 18 at 3:48
...I'd suggest using
xfp
rather than fp
.– Werner
Nov 18 at 3:48
@Werner: Is that better? Do I need to change the macros?
– Peter Grill
Nov 18 at 3:53
@Werner: Is that better? Do I need to change the macros?
– Peter Grill
Nov 18 at 3:53
1
1
It's just more convenient to use since it can be used in expansion, like
xdefTotal{fpeval{<fp>}}
; it also works well with dimension calculations.– Werner
Nov 18 at 3:58
It's just more convenient to use since it can be used in expansion, like
xdefTotal{fpeval{<fp>}}
; it also works well with dimension calculations.– Werner
Nov 18 at 3:58
@Werner: Thanks. Looks like that does not have this specfic issue that
fp
has.– Peter Grill
Nov 18 at 4:13
@Werner: Thanks. Looks like that does not have this specfic issue that
fp
has.– Peter Grill
Nov 18 at 4:13
add a comment |
2 Answers
2
active
oldest
votes
up vote
5
down vote
accepted
The problem can be easily fixed by adding extra parentheses in your AddToTotal
command:
FPevalTempTotal{(Total)+NewAmount}% <-- extra parentheses around Total
Without the parentheses, a negative Total
is expanded as is, giving something like -6000+-1000
where the first expression is interpreted as a subtraction rather than a negative number. fp
then produces an empty stack error because the second operand for that subtraction is missing on the internal stack.
To fix that you have to give it a hint that the negative number is a single atom by putting a pair of parentheses around it. You now correctly get:
That alternative version also seems to work:
FPevalTempTotal{0+Total+NewAmount}
Not sure why the parsing works differently at the start of the expression than in the middle.
add a comment |
up vote
1
down vote
Why not using expl3
directly? You load it anyway, because of siunitx
.
documentclass{article}
usepackage{siunitx} % also loads xparse and expl3
sisetup{
round-mode=places,
round-precision=2,
group-separator={,},
group-four-digits,
}
ExplSyntaxOn
fp_new:N g_grill_total_fp % initialized to 0
tl_new:N l__grill_total_temp_tl
NewDocumentCommand{AddToTotal}{m}
{
tl_set:Nn l__grill_total_temp_tl { #1 }
tl_remove_all:Nn l__grill_total_temp_tl { , }
fp_gadd:Nn g_grill_total_fp { l__grill_total_temp_tl }
After~adding~num{tl_use:N l__grill_total_temp_tl},~
total~is~num{fp_use:N g_grill_total_fp}.
par
}
ExplSyntaxOff
begin{document}
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}
end{document}
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
The problem can be easily fixed by adding extra parentheses in your AddToTotal
command:
FPevalTempTotal{(Total)+NewAmount}% <-- extra parentheses around Total
Without the parentheses, a negative Total
is expanded as is, giving something like -6000+-1000
where the first expression is interpreted as a subtraction rather than a negative number. fp
then produces an empty stack error because the second operand for that subtraction is missing on the internal stack.
To fix that you have to give it a hint that the negative number is a single atom by putting a pair of parentheses around it. You now correctly get:
That alternative version also seems to work:
FPevalTempTotal{0+Total+NewAmount}
Not sure why the parsing works differently at the start of the expression than in the middle.
add a comment |
up vote
5
down vote
accepted
The problem can be easily fixed by adding extra parentheses in your AddToTotal
command:
FPevalTempTotal{(Total)+NewAmount}% <-- extra parentheses around Total
Without the parentheses, a negative Total
is expanded as is, giving something like -6000+-1000
where the first expression is interpreted as a subtraction rather than a negative number. fp
then produces an empty stack error because the second operand for that subtraction is missing on the internal stack.
To fix that you have to give it a hint that the negative number is a single atom by putting a pair of parentheses around it. You now correctly get:
That alternative version also seems to work:
FPevalTempTotal{0+Total+NewAmount}
Not sure why the parsing works differently at the start of the expression than in the middle.
add a comment |
up vote
5
down vote
accepted
up vote
5
down vote
accepted
The problem can be easily fixed by adding extra parentheses in your AddToTotal
command:
FPevalTempTotal{(Total)+NewAmount}% <-- extra parentheses around Total
Without the parentheses, a negative Total
is expanded as is, giving something like -6000+-1000
where the first expression is interpreted as a subtraction rather than a negative number. fp
then produces an empty stack error because the second operand for that subtraction is missing on the internal stack.
To fix that you have to give it a hint that the negative number is a single atom by putting a pair of parentheses around it. You now correctly get:
That alternative version also seems to work:
FPevalTempTotal{0+Total+NewAmount}
Not sure why the parsing works differently at the start of the expression than in the middle.
The problem can be easily fixed by adding extra parentheses in your AddToTotal
command:
FPevalTempTotal{(Total)+NewAmount}% <-- extra parentheses around Total
Without the parentheses, a negative Total
is expanded as is, giving something like -6000+-1000
where the first expression is interpreted as a subtraction rather than a negative number. fp
then produces an empty stack error because the second operand for that subtraction is missing on the internal stack.
To fix that you have to give it a hint that the negative number is a single atom by putting a pair of parentheses around it. You now correctly get:
That alternative version also seems to work:
FPevalTempTotal{0+Total+NewAmount}
Not sure why the parsing works differently at the start of the expression than in the middle.
edited Nov 18 at 3:54
answered Nov 18 at 3:42
siracusa
4,49011127
4,49011127
add a comment |
add a comment |
up vote
1
down vote
Why not using expl3
directly? You load it anyway, because of siunitx
.
documentclass{article}
usepackage{siunitx} % also loads xparse and expl3
sisetup{
round-mode=places,
round-precision=2,
group-separator={,},
group-four-digits,
}
ExplSyntaxOn
fp_new:N g_grill_total_fp % initialized to 0
tl_new:N l__grill_total_temp_tl
NewDocumentCommand{AddToTotal}{m}
{
tl_set:Nn l__grill_total_temp_tl { #1 }
tl_remove_all:Nn l__grill_total_temp_tl { , }
fp_gadd:Nn g_grill_total_fp { l__grill_total_temp_tl }
After~adding~num{tl_use:N l__grill_total_temp_tl},~
total~is~num{fp_use:N g_grill_total_fp}.
par
}
ExplSyntaxOff
begin{document}
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}
end{document}
add a comment |
up vote
1
down vote
Why not using expl3
directly? You load it anyway, because of siunitx
.
documentclass{article}
usepackage{siunitx} % also loads xparse and expl3
sisetup{
round-mode=places,
round-precision=2,
group-separator={,},
group-four-digits,
}
ExplSyntaxOn
fp_new:N g_grill_total_fp % initialized to 0
tl_new:N l__grill_total_temp_tl
NewDocumentCommand{AddToTotal}{m}
{
tl_set:Nn l__grill_total_temp_tl { #1 }
tl_remove_all:Nn l__grill_total_temp_tl { , }
fp_gadd:Nn g_grill_total_fp { l__grill_total_temp_tl }
After~adding~num{tl_use:N l__grill_total_temp_tl},~
total~is~num{fp_use:N g_grill_total_fp}.
par
}
ExplSyntaxOff
begin{document}
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}
end{document}
add a comment |
up vote
1
down vote
up vote
1
down vote
Why not using expl3
directly? You load it anyway, because of siunitx
.
documentclass{article}
usepackage{siunitx} % also loads xparse and expl3
sisetup{
round-mode=places,
round-precision=2,
group-separator={,},
group-four-digits,
}
ExplSyntaxOn
fp_new:N g_grill_total_fp % initialized to 0
tl_new:N l__grill_total_temp_tl
NewDocumentCommand{AddToTotal}{m}
{
tl_set:Nn l__grill_total_temp_tl { #1 }
tl_remove_all:Nn l__grill_total_temp_tl { , }
fp_gadd:Nn g_grill_total_fp { l__grill_total_temp_tl }
After~adding~num{tl_use:N l__grill_total_temp_tl},~
total~is~num{fp_use:N g_grill_total_fp}.
par
}
ExplSyntaxOff
begin{document}
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}
end{document}
Why not using expl3
directly? You load it anyway, because of siunitx
.
documentclass{article}
usepackage{siunitx} % also loads xparse and expl3
sisetup{
round-mode=places,
round-precision=2,
group-separator={,},
group-four-digits,
}
ExplSyntaxOn
fp_new:N g_grill_total_fp % initialized to 0
tl_new:N l__grill_total_temp_tl
NewDocumentCommand{AddToTotal}{m}
{
tl_set:Nn l__grill_total_temp_tl { #1 }
tl_remove_all:Nn l__grill_total_temp_tl { , }
fp_gadd:Nn g_grill_total_fp { l__grill_total_temp_tl }
After~adding~num{tl_use:N l__grill_total_temp_tl},~
total~is~num{fp_use:N g_grill_total_fp}.
par
}
ExplSyntaxOff
begin{document}
AddToTotal{18,000.00}
AddToTotal{-17,000.00}
AddToTotal{-7,000.00}
AddToTotal{-1,000.00}
end{document}
answered Nov 18 at 11:10
egreg
701k8618703144
701k8618703144
add a comment |
add a comment |
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f460522%2fusing-fp-package-to-compute-sum-breaks-fp-error-upn-stack-is-empty%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
...I'd suggest using
xfp
rather thanfp
.– Werner
Nov 18 at 3:48
@Werner: Is that better? Do I need to change the macros?
– Peter Grill
Nov 18 at 3:53
1
It's just more convenient to use since it can be used in expansion, like
xdefTotal{fpeval{<fp>}}
; it also works well with dimension calculations.– Werner
Nov 18 at 3:58
@Werner: Thanks. Looks like that does not have this specfic issue that
fp
has.– Peter Grill
Nov 18 at 4:13