Kiedy coś obliczam, czasami wyniki pośrednie stają się zbyt duże dla systemu pgf. Można skorzystać z biblioteki fpu. Przeczytałem o tym w TikZ & PGF instrukcji (patrz strona 627), tutaj i tutaj , ale nadal pojawia się ten błąd:

Paragraph ended before `\pgfflt@readlowlevelfloat` was complete. 

Co jest nie tak?

Oto mój kod:

\documentclass{scrartcl} \usepackage{tikz} \usetikzlibrary{fpu} \begin{document} %data values: \def\RTable{{100,100.391,100.781,101.172,101.562,101.953,102.343,102.733,103.123,103.513,103.903,104.292,104.682,105.071,105.46,105.849,106.238,106.627,107.016,107.405,107.794,108.182,108.57,108.959,109.347,109.735,110.123,110.51,110.898,111.286,111.673,112.06,112.447,112.835,113.221,113.608,113.995,114.382,114.768,115.155,115.541,115.927,116.313,116.699,117.085,117.47,117.856,118.241,118.627,119.012,119.397,119.782,120.167,120.552,120.936,121.321,121.705,122.09,122.474,122.858,123.242,123.626,124.009,124.393,124.777,125.16,125.543,125.926,126.309,126.692,127.075,127.458,127.84,128.223,128.605,128.987,129.37,129.752,130.133,130.515,130.897}} %prints the result to the console: \pgfkeys{/pgf/fpu} \foreach \i in {0, ..., 80} { \pgfmathparse{abs(\RTable[\i] - 100 - 3.0897 / 8 * \i)}\i, \pgfmathresult\\ } \pgfkeys{/pgf/fpu=false} \end{document} 

Aktualizacja :

Używam makra z tutaj (dzięki kot Schrödingera ). Zobacz moje MWE:

\documentclass{scrartcl} \usepackage{tikz} \usetikzlibrary{fpu} \newcommand\pgfmathparseFPU[1]{ \begingroup \pgfkeys{ /pgf/fpu, /pgf/fpu/output format = fixed } \pgfmathparse{#1} \pgfmathsmuggle \pgfmathresult \endgroup} \begin{document} %data values: \def\UABmValues{{14.9, 15.8, 17.7, 18.3, 19, 20, 21.1, 22.2, 24.3, 26.9, 30.1}} %prints the result to the console: \foreach[count = \i from 0] \k in {30, 35, ..., 80} { \pgfmathparseFPU{-25500 / (\UABmValues[\i] / 1000 - 255 / 52) - 5200 - 3.0897 / 8 * \k}\i, \pgfmathresult\\ } \end{document} 

i nadal otrzymuję

Paragraph ended before `\pgfflt@readlowlevelfloat` was complete. 

błąd. Co mam nie tak?

Z góry dziękuję za pomoc i wysiłek!

Komentarze

  • I ' Nie jestem pewien, czy można to naprawić, ponieważ pgfmath nieustannie konwertuje tekst, rejestry dimen i rejestry fpu (dlatego uważam go za tańczącego niedźwiedzia).
  • Witam wszystkich! Czy żaden z profesjonalistów nie ma propozycji rozwiązania?
  • Pamiętaj, że \pgfkeys{pgf/fpu=false} nie zrobi tego, co mówi na puszce, chyba że zostało to niedawno naprawione.
  • Myślę, że powinieneś zadać nowe pytanie na ten temat, ponieważ masz już dobrą odpowiedź. \foreach[count = \i from 0] \k in {30, 35, ..., 80} { \pgfmathsetmacro{\myval}{\UABmValues[\i]} \pgfmathparseFPU{-25500/(\myval/1000-255/52)-5200-3.0897/8*\k}\i, \pgfmathresult\\ } działa. Obecnie fpu nie obsługuje kilku rzeczy, w tym manipulacji liczbami całkowitymi i tego rodzaju wyodrębniania list. Musisz więc wyodrębnić wpis bez fpu.
  • @ Su-47 Myślę, że odpowiedź Alaina Matthesa jest dobra. Należy pamiętać, że żaden z systemów nie może tak naprawdę konkurować z systemem algebry komputerowej. Radykalnie nowa wersja TeX-a wymagałaby naprawdę zniesienia wewnętrznych ograniczeń, ale AFAIK, nigdy nie planuje się konfigurowania nowego TeX-a. Należy również pamiętać, że IMHO lepiej poczekać z użyciem expl3, aż znajdzie się w stanie, w którym możesz być pewien, że to, co napisałeś, będzie nadal działać za rok od teraz. Ponieważ wydaje się, że używasz MatLab, zawsze możesz wygenerować dane za pomocą tego narzędzia, a następnie wykreślić je za pomocą pgfplots lub datavisualization.

Odpowiedź

Brzmi jak praca dla FPU LaTeX3:

\documentclass{article} \usepackage{expl3} \ExplSyntaxOn \cs_new_eq:NN \fpeval \fp_eval:n \cs_new_eq:NN \clistitem \clist_item:Nn \cs_new_eq:NN \foreachint \int_step_inline:nnnn \ExplSyntaxOff \begin{document} %data values: \def\RTable{100,100.391,100.781,101.172,101.562,101.953,102.343,102.733,103.123,103.513,103.903,104.292,104.682,105.071,105.46,105.849,106.238,106.627,107.016,107.405,107.794,108.182,108.57,108.959,109.347,109.735,110.123,110.51,110.898,111.286,111.673,112.06,112.447,112.835,113.221,113.608,113.995,114.382,114.768,115.155,115.541,115.927,116.313,116.699,117.085,117.47,117.856,118.241,118.627,119.012,119.397,119.782,120.167,120.552,120.936,121.321,121.705,122.09,122.474,122.858,123.242,123.626,124.009,124.393,124.777,125.16,125.543,125.926,126.309,126.692,127.075,127.458,127.84,128.223,128.605,128.987,129.37,129.752,130.133,130.515,130.897} %prints the result to the console: \foreachint{1}{1}{81}{% #1, \fpeval{abs(\clistitem\RTable{#1} - 100 - 3.0897 / 8 * (#1 - 1))}\\ } \end{document} 

(Konwencja w expl3 ma indeksować od 1, ponieważ jest to zgodne z najczęstszym przypadkiem użycia: składem. Dlatego indeksowałem listę od jednego, ale poprawiłem indeksowanie od zera dla samego równania.)

Komentarze

  • Witaj @Joseph Wright! Dziękuję za odpowiedź. Przetestowałem. 1. Oczywiście, że działa, ale zmienna indeksu powinna zaczynać się od zera (dla mój specjalny cel). 2. Wyniki Twojej odpowiedzi są różne. Prawidłowe wyniki powinny wyglądać jak parabola skierowana w dół, patrz tutaj . Wynik Twojej odpowiedzi wygląda jak otwarta parabola skierowana w górę. Może coś robię źle. 3. W każdym razie nie mogę ' nie używać twojego odpowiedź na moje pytanie (patrz link powyżej). Co powiesz?
  • @ Su-47 Nie ' nie wiem, co masz na myśli o ' linku powyżej '
  • Prawdopodobnie link w punkcie 2 ( tex.stackexchange.com/questions/348739/ … ).
  • Witaj @Joseph Wright i @Torbj ø rn T.! Przepraszam za długą nieobecność. Dziękuję za twoje komentarze. Torbj ø rn T. ma rację Miałem na myśli ten link . Teraz wynik jest prawidłowy. Ale jak powiedziałem w moim ostatnim komentarzu, nie mogę ' użyć powyższej odpowiedzi, aby rozwiązać moje inne pytanie (patrz link powyżej). Jeśli dobrze rozumiem, obecnie nie ma sposobu, aby używać tablic i fpu razem w TikZ? Czy jest inne rozwiązanie, może inna struktura danych w postaci tablic?

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *