# Direct evaluation of fp expression

This code

\documentclass{article}
\usepackage[nomessages]{fp}
\begin{document}
\FPeval{result}{clip(cos(pi))}
$\cos(\pi)=$\result
\end{document}


would produce the following output: Is it possible to use the result of fp expressions directly without the necessity to have them pre-computed and stored in a permanent variable so that I could transform the code to the following form:

\documentclass{article}
\usepackage[nomessages]{fp}
\begin{document}
$\cos(\pi)=$<fp expression>
\end{document}


Not sure if this approach has any gotcha's.

\documentclass{article}
\usepackage[nomessages]{fp}
\newcommand\FPuse{\FPeval{\result}{#1}{\result}}
\begin{document}
$\cos(\pi)=\FPuse{clip(cos(pi))}$\

$\sin(\pi/3)=\FPuse{sin(pi/3)}$

$\sin(\pi/3)=\FPuse{round(sin(pi/3),3)}$
\end{document} In the comments below, jfbu and I discuss why I grouped {\result} at the end of the \FPuse definition. First, let's see what happens if I ungroup it:

\newcommand\FPuse{\FPeval{\result}{#1}\result}


The result on the first operation is What we see is that \result sets itself as {} - 1, using a binary minus sign. The conclusion is that \FPeval{}{} creates a \bgroup...\egroup quantity that, in math mode, causes the subsequent minus sign to act in a binary fashion. Thus, the only way to eliminate this problem (without changing the fp package), is to isolate the final \result in its own group, as I did in my original code.

While jfbu has probed a bit into the guts of fp, I am no expert to know if the fp code can be revised to use \begingroup...\endgroup instead (which is truly transparent in math mode) or not. I do know that fp has a few issues, for example, a stray space is introduced via \FPpow which has to be \unskiped after its use.

• the 18th decimal is not correctly rounded by fp, it should be a 7. But I don't recall what fp's doc (which iirc is very short) says about this. edit: I went a bit fast because there is first Pi then division by 3, then sine. Thus asking for correctly rounded final result is a bit harsh.
– user4686
Nov 15, 2016 at 13:35
• @jfbu "Quibbles and bits"? Nov 15, 2016 at 13:38
• nono ;-) just comparing: Maple is even worse it gives ...649 for evalf(sin(Pi/3.)); with Digits:=18;, one needs Digits:=19; to see correctly what is the 18th decimal...
– user4686
Nov 15, 2016 at 13:40
• @jfbu I am reminded of joke about a job interview with 3 applicants, in which the final question is, "what does 1+1 equal". The punchline of which is, the mathematician, with a full blackboard of proofs proclaims "2", the engineer, with a blazing calculator, proclaims "2.0000 +/- .0001", and the lawyer thinks hard for a minute, before asking, "what would you like it to equal?" Nov 15, 2016 at 13:45
• The main routine \FP@@upn in fp-upn.sty uses \bgroup and \egroup rather than \begingroup and \endgroup. But there are also many locations where the code does {...\global\def...} and this by itself is enough to trigger the issue. Ah.. non expandable code ... Perhaps you could add a word of explanation why you use {\result} ?
– user4686
Nov 16, 2016 at 15:14

Not with fp. It is possible with expl3, though.

\documentclass{article}
\usepackage{expl3}

\ExplSyntaxOn
% make an internal function available to the user
\cs_set_eq:NN \fpeval \fp_eval:n
\ExplSyntaxOff

\begin{document}

$\cos(\pi)=\fpeval{cos(pi)}$

$\sin(\pi/3)=\fpeval{sin(pi/3)}$

$\sin(\pi/3)=\fpeval{round(sin(pi/3),3)}$

\end{document} 