5

As per the MWE below, I am using the glossaries package to handle the automation of values being inserted into text.

  • This is useful when trends and discussions/conclusions don't change but values are a pain to replace upon updating
  • This also is highly customizable to preform comparisons (max search) and simple math.
  • values exported from analysis programs can easily be scripted into the observed \newglossaryentry{} entries and imported making for easy dynamic updates

As can be observed below, the creation of the glossary entries require a description, which is a bit of a waste of memory because what this example (being minimal) can't show, is that for thousands of entries, glossaries returns memory size limit problems.

Is there a more direct way to import externally saved values into my document, other than glossaries.

Note: at this time, Lua scripted options are not solution I could maintain but if it is the only option, I would welcome this as a starting point for my foray into LuaTex.

\documentclass{article}

\usepackage[nogroupskip,toc,acronym,indexonlyfirst]{glossaries} % must come after href   
\usepackage{scrwfile}%http://www.dickimaw-books.com/cgi-bin/faq.cgi?action=view&categorylabel=glossaries#glsnewwriteexceeded

\newglossary[datag]{data}{datat}{datan}{Data}

\makeindex % activate index-making
\makeglossaries


\newglossaryentry{d.ControlRatio_Pooled_Classification_Control-Control}{ type={data},  name={1}, description={1} }
\newglossaryentry{d.ControlRatio_Pooled_Classification_Stimulant-Condition1}{ type={data},  name={0.86}, description={0.86} }
\newglossaryentry{d.ControlRatio_Pooled_Classification_Stimulant-Condition2}{ type={data},  name={0.83}, description={0.83} }

\begin{document}
    Testing glossary for values \gls{d.ControlRatio_Pooled_Classification_Control-Control}, \gls{d.ControlRatio_Pooled_Classification_Stimulant-Condition2}, \gls{d.ControlRatio_Pooled_Classification_Stimulant-Condition2}
    No need to run a builder of makeindex because I have no intention of creating a summary list.
\end{document}
doncherry
  • 54,637
EngBIRD
  • 3,985
  • Isn't datatool (never used it so far) designed for this? By the way, the glossaries and datatool package were both written by Nicola Talbot –  Jun 04 '15 at 23:09
  • @ChristianHupfer Thanks, I have never stumbled across this package before. I will investigate datatool right away! – EngBIRD Jun 04 '15 at 23:26

1 Answers1

4

I think using glossaries is overkill here. It's a heavy-weight package because it's designed for such a wide-range of purposes (regular terms, abbreviations, symbols, plurals, user-defined additional information, etc). The datatool package is also heavy-weight, and again I think using that would be excessive for your requirements. If you're only interested in storing and looking up values by reference, then here's a simpler alternative that uses etoolbox:

\documentclass{article}

\usepackage{etoolbox}

\newcommand*{\newentry}[2]{%
  \ifcsdef{@entry@#1}%
  {\GenericError{}{Entry `#1' already defined}{}{}}%
  {\csdef{@entry@#1}{#2}}%
}

\newcommand*{\entry}[1]{%
  \ifcsdef{@entry@#1}%
  {\csuse{@entry@#1}}%
  {\GenericError{}{Entry `#1' not defined}{}{}}%
}

\newentry{d.ControlRatio_Pooled_Classification_Control-Control}{1}
\newentry{d.ControlRatio_Pooled_Classification_Stimulant-Condition1}{0.86}
\newentry{d.ControlRatio_Pooled_Classification_Stimulant-Condition2}{0.83}

\begin{document}

Testing values
\entry{d.ControlRatio_Pooled_Classification_Control-Control},
\entry{d.ControlRatio_Pooled_Classification_Stimulant-Condition1},
\entry{d.ControlRatio_Pooled_Classification_Stimulant-Condition2}.

\end{document}

The \newentry command defines a control sequence used to store the relevant value. The \entry command accesses the stored information. The etoolbox command \ifcsdef checks if the control sequence has already been defined. \GenericError is part of the LaTeX kernel that prints an error message.

If you want to further cut down the resources your document requires, you can skip etoolbox and just use LaTeX kernel commands:

\documentclass{article}

\makeatletter

\newcommand*{\newentry}[2]{%
  \@ifundefined{@entry@#1}%
  {\@namedef{@entry@#1}{#2}}%
  {\GenericError{}{Entry `#1' already defined}{}{}}%
}

\newcommand*{\entry}[1]{%
  \@ifundefined{@entry@#1}%
  {\GenericError{}{Entry `#1' not defined}{}{}}%
  {\@nameuse{@entry@#1}}%
}

\makeatother 

\newentry{d.ControlRatio_Pooled_Classification_Control-Control}{1}
\newentry{d.ControlRatio_Pooled_Classification_Stimulant-Condition1}{0.86}
\newentry{d.ControlRatio_Pooled_Classification_Stimulant-Condition2}{0.83}

\begin{document}

Testing values
\entry{d.ControlRatio_Pooled_Classification_Control-Control},
\entry{d.ControlRatio_Pooled_Classification_Stimulant-Condition1},
\entry{d.ControlRatio_Pooled_Classification_Stimulant-Condition2}.

\end{document}
Nicola Talbot
  • 41,153
  • Beautiful! Before I spend a lot of time changing over my extensive document dependency that follows the structure above, I would be I am curious to know if you are aware of any memory restrictions in (or other pros and cons) in implementing this elegant solution with either the base kernel commands vs etoolbox? My primary concern is running out of memory. I never posted a question about this, or was able to solve it from the other posted question, but my MWE had a bit of maneuvering in the background to avoid out of memory errors when my raw data imports were tens of thousands of entries. – EngBIRD Jun 25 '15 at 04:20
  • Outside of the memory concern, the pros/cons I guess I meant is, if I have already had to use the etoolbox package, it is still taking up a greater amount of overhead to use your first solution? – EngBIRD Jun 25 '15 at 04:23
  • @EngBIRD If you're already loading the etoolbox package, then I don't think there's a significant difference in using the first method over the second. \csuse does marginally more than \@nameuse as it uses the conditional \ifcsname which \@nameuse doesn't, but I don't think there's much in that. I think it might be worth seeing if you can cut down on non-essential packages or use a light-weight class. Also, if you haven't already, have a look at Component's of (La)TeX's Memory Usage. – Nicola Talbot Jun 25 '15 at 10:44
  • For completeness, I should mention that the memory error I was trying to avoid was similar to that described: http://tex.stackexchange.com/questions/35393/tex-capacity-exceeded-with-glossary-package but this solution failed to work. However the comment that links to documentation: "Drawbacks With Defining Entries in the Document Environment" provides details that likely is the root of my problem of memory with glossaries. Would you be able to tell me if \newentry{}{} is subject to the same preamble sensitivity? Thanks. – EngBIRD Jun 26 '15 at 05:20
  • @EngBIRD No, those issues shouldn't affect \newentry. Those drawbacks arise to compensate for documents where there's a glossary (or list of acronyms, etc) in the front matter. Since you said you're not interested in that, I don't see a problem with using \newentry within the document environment. You'll get an error if you attempt to use an entry before it's been defined, but then you just need to move \newentry to just before the first instance where it's used. I don't know how much it will help to undefine an entry when you no longer need it. – Nicola Talbot Jun 26 '15 at 16:55