# How to expand error messages truncated by Skeleton (<< >>)

I have a command that gives me an error message with lots of abbreviations like Power[<<2>>]. Specifically, I get

Sorry for the bad formatting, I don't know how to paste Mathematica code here properly. Here is a screenshot for better readability:

My question now is: How can I expand these <<2>> terms, so that I can see what exactly failed and possibly copy-paste the term to evaluate it individually?

If someone knows how <<2>> is called I would gladly add a tag for it.

The full code to reproduce this behavior is below. The first part are definitions:

(* Define the integral function. *)
θ[ϱ_, ρ0_] := 2 ArcTan[Exp[(ϱ - ρ0)]] + 2 ArcTan[Exp[(ϱ + ρ0)]]
mz[ϱ_, ρ0_] := Cos[θ[ϱ, ρ0]]
K[k_] := EllipticK[k^2/(-1 + k^2)]/Sqrt[1 - k^2]
k[p_, y_, z_] := Sqrt[4 y z/(p^2 + (y + z)^2)]
g1[x_, ϱ_] := 1/Pi Sqrt[1/(x ϱ)] (k[0, x, ϱ] K[k[0, x, ϱ]] -
k[1, x, ϱ] K[k[1, x, ϱ]])
g0[x_] := Evaluate[Limit[g1[x, ϱ], ϱ -> 0, Assumptions -> {x > 0}]]
g[x_, ϱ_] = Piecewise[{{g0[x], ϱ == 0}, {g1[x, ϱ], ϱ > 0}}]

f[ϱ_, ρ0_, δ_] := δ^2 Re[
NIntegrate[
x (1 - mz[x, ρ0]) g[x δ , ϱ δ] Boole[x - ϱ < 0], {x, 0, ρ0 + 15},
PrecisionGoal -> 7, Method -> {"GlobalAdaptive", "MaxErrorIncreases" -> 100000,
Method -> {"GaussKronrodRule", "Points" -> 3}}, MaxRecursion -> 20,
WorkingPrecision -> 30] +
NIntegrate[
x (1 - mz[x, ρ0]) g[x δ, ϱ δ] Boole[x - ϱ > 0], {x, 0, ρ0 + 15},
PrecisionGoal -> 7, Method -> {"GlobalAdaptive", "MaxErrorIncreases" -> 100000,
Method -> {"GaussKronrodRule", "Points" -> 3}}, MaxRecursion -> 20,
WorkingPrecision -> 30]] - 2 (1 - UnitStep[ϱ - ρ0])

I3[ρ0_, δ_, rmax_, precision_] := NIntegrate[mz[ϱ, ρ0] f[ϱ, ρ0, δ], {ϱ, 0, rmax}]


The error is triggered when I try to evaluate the following:

I3[10, 1/100, 10^7, 7]

• Try FullForm. Mar 9, 2016 at 16:18
• Yields Syntax::sntxf: "FullForm[" cannot be followed by "<<2>>]", if I apply FullForm to the copy-pasted error message. Was that what you meant? Mar 9, 2016 at 16:35
• Try FullForm before the equation or terms are evaluated. Mar 9, 2016 at 16:37
• The << ... >> form is called Skeleton. Unfortunately it is my understanding that the information once contained in the skeleton form is actually lost, so you will have to work with the expression that generates the error to get more information instead. It would really help if you could post the expression that generated the error, rather than the error itself. See this question and its answer for more information on how to format code to post on this site. Mar 9, 2016 at 17:09
• Unfortunately, even with FullForm in the original command, I still get the skeletons. See the full code in the edit of the original question. Mar 9, 2016 at 18:13

An answer to the original question of how to show the full message abbreviated by the skeletons can be found in an old StackOverflow question.

The gist of the answer there was the following:

I'm not sure if you can recover a long message that has already been generated. As $MessageList and Message[] only store the message names, not the arguments passed to them. To stop Short[] from being automatically applied to messages you can Unset[$MessagePrePrint]. It's default value is Automatic -- whatever that entails.

• That is an excellent find. I took the liberty of adding a summary of that old answer; it is a bit more informative to the casual reader, and it safeguards against something breaking in the future. (+1) Mar 9, 2016 at 20:01
• Felix, would you please mark this as the accepted answer, since technically this is closer to answering the original question than @MarcoB 's answer. Aug 8, 2016 at 17:42

The error you see is typically associated with the fact that NIntegrate will attempt to evaluate your expression symbolically to see if it can be simplified before substituting in numerical values.

When the NIntegrate in the definition of I3 attempts to do this, it will attempt to evaluate mz and f symbolically; mz will work, but f will not, because it needs numerical values to evaluate its own definition which is based on NIntegrate. This is a common problem that is discussed in this FAQ: User-defined functions, numerical approximation, and NumericQ, and in this support article How do I use ?NumericQ to affect order of evaluation?.

You should therefore prevent symbolic evaluation of the f function by using a NumericQ condition on its arguments:

Clear[f]
f[ϱ_?NumericQ, ρ0_, δ_] := (* your definition of f as it is *)


Notice that you have to clear any existing definition for f first!

When you do that, the error you observe will no longer appear.

Unfortunately, however, this is only a small part of the problems you will face, I'm afraid: the evaluation you require may be extremely time-consuming (at least it didn't complete in a few minutes on my system). That's a quite different problem that will require some analysis of your expression and problem, and it is outside of the scope of this question.

• Adding ?NumericQ to the argument solved the problem of getting rid of the error messages. In view of the original question, however, would there be a way of expanding the skeletons? Mar 9, 2016 at 19:12