Naming the result of a source block Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?Can I use elisp code make a table and insert a variable into cell?Indentation of source block resultFontify result of source block in org-modeHow to have org-babel treat the first line of a table result as a header?Org-mode: pipe source block output as stdin to next source blockHow to append header arguments to result code src block?How to insert a result of an org-mode source block as part of the document's syntax?Org-mode: Get src block result inside block definition for clocktableget contents of source blockCatching warnings from sh source blockHow to generate the result file for dot source block and include it with another path in org-mode?

How can I make names more distinctive without making them longer?

How come Sam didn't become Lord of Horn Hill?

How to deal with a team lead who never gives me credit?

Book where humans were engineered with genes from animal species to survive hostile planets

English words in a non-english sci-fi novel

What would be the ideal power source for a cybernetic eye?

Can I cast Passwall to drop an enemy into a 20-foot pit?

Generate an RGB colour grid

String `!23` is replaced with `docker` in command line

Check which numbers satisfy the condition [A*B*C = A! + B! + C!]

Can a USB port passively 'listen only'?

What exactly is a "Meth" in Altered Carbon?

Denied boarding although I have proper visa and documentation. To whom should I make a complaint?

Output the ŋarâþ crîþ alphabet song without using (m)any letters

Sci-Fi book where patients in a coma ward all live in a subconscious world linked together

2001: A Space Odyssey's use of the song "Daisy Bell" (Bicycle Built for Two); life imitates art or vice-versa?

How to bypass password on Windows XP account?

Should I use a zero-interest credit card for a large one-time purchase?

How to find out what spells would be useless to a blind NPC spellcaster?

List of Python versions

Short Story with Cinderella as a Voo-doo Witch

Can a non-EU citizen traveling with me come with me through the EU passport line?

Why did the IBM 650 use bi-quinary?

Resolving to minmaj7



Naming the result of a source block



Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)
Announcing the arrival of Valued Associate #679: Cesar Manara
Unicorn Meta Zoo #1: Why another podcast?Can I use elisp code make a table and insert a variable into cell?Indentation of source block resultFontify result of source block in org-modeHow to have org-babel treat the first line of a table result as a header?Org-mode: pipe source block output as stdin to next source blockHow to append header arguments to result code src block?How to insert a result of an org-mode source block as part of the document's syntax?Org-mode: Get src block result inside block definition for clocktableget contents of source blockCatching warnings from sh source blockHow to generate the result file for dot source block and include it with another path in org-mode?










1















The following question has been asked (in slightly different form) in a comment of another answer:



Is it possible to name the results of a source block with #+NAME: foobar (or equivalently but old-style: #+TBLNAME: foobar) rather than #+RESULTS: foobar?



Example:



#+NAME: foo
#+BEGIN_SRC emacs-lisp :var alpha=2 :results value
(let* ((tol 0.1)
(alpha_1 (- 90 alpha)))
`(("angle" "symbol" "value" "max" "min") hline
("toe" "\alpha" ,alpha ,(+ alpha tol) ,(- alpha tol))
("c" "\alpha_1" ,alpha_1 ,(+ alpha_1 tol) ,(- alpha_1 tol))
))
#+END_SRC

#+RESULTS: foo
| angle | symbol | value | max | min |
|-------+----------+-------+------+------|
| toe | alpha | 1 | 1.1 | 0.9 |
| c | alpha_1 | 89 | 89.1 | 88.9 |









share|improve this question


























    1















    The following question has been asked (in slightly different form) in a comment of another answer:



    Is it possible to name the results of a source block with #+NAME: foobar (or equivalently but old-style: #+TBLNAME: foobar) rather than #+RESULTS: foobar?



    Example:



    #+NAME: foo
    #+BEGIN_SRC emacs-lisp :var alpha=2 :results value
    (let* ((tol 0.1)
    (alpha_1 (- 90 alpha)))
    `(("angle" "symbol" "value" "max" "min") hline
    ("toe" "\alpha" ,alpha ,(+ alpha tol) ,(- alpha tol))
    ("c" "\alpha_1" ,alpha_1 ,(+ alpha_1 tol) ,(- alpha_1 tol))
    ))
    #+END_SRC

    #+RESULTS: foo
    | angle | symbol | value | max | min |
    |-------+----------+-------+------+------|
    | toe | alpha | 1 | 1.1 | 0.9 |
    | c | alpha_1 | 89 | 89.1 | 88.9 |









    share|improve this question
























      1












      1








      1


      1






      The following question has been asked (in slightly different form) in a comment of another answer:



      Is it possible to name the results of a source block with #+NAME: foobar (or equivalently but old-style: #+TBLNAME: foobar) rather than #+RESULTS: foobar?



      Example:



      #+NAME: foo
      #+BEGIN_SRC emacs-lisp :var alpha=2 :results value
      (let* ((tol 0.1)
      (alpha_1 (- 90 alpha)))
      `(("angle" "symbol" "value" "max" "min") hline
      ("toe" "\alpha" ,alpha ,(+ alpha tol) ,(- alpha tol))
      ("c" "\alpha_1" ,alpha_1 ,(+ alpha_1 tol) ,(- alpha_1 tol))
      ))
      #+END_SRC

      #+RESULTS: foo
      | angle | symbol | value | max | min |
      |-------+----------+-------+------+------|
      | toe | alpha | 1 | 1.1 | 0.9 |
      | c | alpha_1 | 89 | 89.1 | 88.9 |









      share|improve this question














      The following question has been asked (in slightly different form) in a comment of another answer:



      Is it possible to name the results of a source block with #+NAME: foobar (or equivalently but old-style: #+TBLNAME: foobar) rather than #+RESULTS: foobar?



      Example:



      #+NAME: foo
      #+BEGIN_SRC emacs-lisp :var alpha=2 :results value
      (let* ((tol 0.1)
      (alpha_1 (- 90 alpha)))
      `(("angle" "symbol" "value" "max" "min") hline
      ("toe" "\alpha" ,alpha ,(+ alpha tol) ,(- alpha tol))
      ("c" "\alpha_1" ,alpha_1 ,(+ alpha_1 tol) ,(- alpha_1 tol))
      ))
      #+END_SRC

      #+RESULTS: foo
      | angle | symbol | value | max | min |
      |-------+----------+-------+------+------|
      | toe | alpha | 1 | 1.1 | 0.9 |
      | c | alpha_1 | 89 | 89.1 | 88.9 |






      org-babel org-table






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 4 hours ago









      TobiasTobias

      15.2k11035




      15.2k11035




















          1 Answer
          1






          active

          oldest

          votes


















          2














          One can add the following lines below unnamed source blocks (with bar replaced by the intended table name):



          #+NAME: bar
          #+RESULTS:
          ||


          The line with #+name: bar is preserved after the evaluation of the source block and || is replaced with the resulting table.



          Note, that the name bar really names the table and not the source block.
          That has the following consequences (probably among others I am not aware of at the moment):



          1. If you refer to the table name in the header arguments of another source block, say buh, then the bar source block is not reevaluated when buh is evaluated. The table is not updated but taken as argument for buh as it is.

            That is usually more an disadvantage than an advantage.

            One can call org-babel-execute-buffer to get correctly updated results.


          2. If the source block returns a string containing the formatted org-table rather than table data referring to the source block name in header variables gets you the string and not the table data. That is most often unwanted.

            In that case it is a big advantage that you can alternatively refer to the resulting table by its name.


          If the source block is named, e.g., foo replace #+RESULTS: with #+RESULTS: foo.



          Example:



          #+NAME: foo
          #+BEGIN_SRC emacs-lisp :var alpha=2 :results value
          (let* ((tol 0.1)
          (alpha_1 (- 90 alpha)))
          `(("angle" "symbol" "value" "max" "min") hline
          ("toe" "\alpha" ,alpha ,(+ alpha tol) ,(- alpha tol))
          ("c" "\alpha_1" ,alpha_1 ,(+ alpha_1 tol) ,(- alpha_1 tol))
          ))
          #+END_SRC

          #+TBLNAME: bar
          #+RESULTS: foo
          | angle | symbol | value | max | min |
          |-------+----------+-------+------+------|
          | toe | alpha | 1 | 1.1 | 0.9 |
          | c | alpha_1 | 89 | 89.1 | 88.9 |

          #+CALL: foo(alpha=bar[2,3])

          #+NAME: buh
          #+RESULTS:
          | angle | symbol | value | max | min |
          |-------+----------+-------+--------------------+-------------------|
          | toe | alpha | 1.1 | 1.2000000000000002 | 1.0 |
          | c | alpha_1 | 88.9 | 89.0 | 88.80000000000001 |


          The example demonstrates the update problem. The header variable alpha had the value 1 at the first evaluation of foo. Afterwards the value was changed to 2 but the source block foo was not evaluated again.

          The evaluation of the #+CALL statement does use the table value 1.1 at cell 2,3 directly without reevaluation of foo.






          share|improve this answer

























          • Quite informative, indeed. But there seems to be no way to not have the line #+RESULTS: in the results. One interesting question is, how is the system handling a let* form and turning it into a table? Is this something to do with :results value? But then if I do #+begin_src emacs-lisp :var table=bar (message "%S" table) #+end_src I get (("toe" "\alpha" 2 2.1 1.9) ("c" "$\alpha_1$" 88 88.1 87.9)) i.e., it's left out the title and horizontal line, i.e.,i.e., not completely reversible? Interesting stuff, nonetheless.

            – 147pm
            19 mins ago












          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "583"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2femacs.stackexchange.com%2fquestions%2f48972%2fnaming-the-result-of-a-source-block%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          2














          One can add the following lines below unnamed source blocks (with bar replaced by the intended table name):



          #+NAME: bar
          #+RESULTS:
          ||


          The line with #+name: bar is preserved after the evaluation of the source block and || is replaced with the resulting table.



          Note, that the name bar really names the table and not the source block.
          That has the following consequences (probably among others I am not aware of at the moment):



          1. If you refer to the table name in the header arguments of another source block, say buh, then the bar source block is not reevaluated when buh is evaluated. The table is not updated but taken as argument for buh as it is.

            That is usually more an disadvantage than an advantage.

            One can call org-babel-execute-buffer to get correctly updated results.


          2. If the source block returns a string containing the formatted org-table rather than table data referring to the source block name in header variables gets you the string and not the table data. That is most often unwanted.

            In that case it is a big advantage that you can alternatively refer to the resulting table by its name.


          If the source block is named, e.g., foo replace #+RESULTS: with #+RESULTS: foo.



          Example:



          #+NAME: foo
          #+BEGIN_SRC emacs-lisp :var alpha=2 :results value
          (let* ((tol 0.1)
          (alpha_1 (- 90 alpha)))
          `(("angle" "symbol" "value" "max" "min") hline
          ("toe" "\alpha" ,alpha ,(+ alpha tol) ,(- alpha tol))
          ("c" "\alpha_1" ,alpha_1 ,(+ alpha_1 tol) ,(- alpha_1 tol))
          ))
          #+END_SRC

          #+TBLNAME: bar
          #+RESULTS: foo
          | angle | symbol | value | max | min |
          |-------+----------+-------+------+------|
          | toe | alpha | 1 | 1.1 | 0.9 |
          | c | alpha_1 | 89 | 89.1 | 88.9 |

          #+CALL: foo(alpha=bar[2,3])

          #+NAME: buh
          #+RESULTS:
          | angle | symbol | value | max | min |
          |-------+----------+-------+--------------------+-------------------|
          | toe | alpha | 1.1 | 1.2000000000000002 | 1.0 |
          | c | alpha_1 | 88.9 | 89.0 | 88.80000000000001 |


          The example demonstrates the update problem. The header variable alpha had the value 1 at the first evaluation of foo. Afterwards the value was changed to 2 but the source block foo was not evaluated again.

          The evaluation of the #+CALL statement does use the table value 1.1 at cell 2,3 directly without reevaluation of foo.






          share|improve this answer

























          • Quite informative, indeed. But there seems to be no way to not have the line #+RESULTS: in the results. One interesting question is, how is the system handling a let* form and turning it into a table? Is this something to do with :results value? But then if I do #+begin_src emacs-lisp :var table=bar (message "%S" table) #+end_src I get (("toe" "\alpha" 2 2.1 1.9) ("c" "$\alpha_1$" 88 88.1 87.9)) i.e., it's left out the title and horizontal line, i.e.,i.e., not completely reversible? Interesting stuff, nonetheless.

            – 147pm
            19 mins ago
















          2














          One can add the following lines below unnamed source blocks (with bar replaced by the intended table name):



          #+NAME: bar
          #+RESULTS:
          ||


          The line with #+name: bar is preserved after the evaluation of the source block and || is replaced with the resulting table.



          Note, that the name bar really names the table and not the source block.
          That has the following consequences (probably among others I am not aware of at the moment):



          1. If you refer to the table name in the header arguments of another source block, say buh, then the bar source block is not reevaluated when buh is evaluated. The table is not updated but taken as argument for buh as it is.

            That is usually more an disadvantage than an advantage.

            One can call org-babel-execute-buffer to get correctly updated results.


          2. If the source block returns a string containing the formatted org-table rather than table data referring to the source block name in header variables gets you the string and not the table data. That is most often unwanted.

            In that case it is a big advantage that you can alternatively refer to the resulting table by its name.


          If the source block is named, e.g., foo replace #+RESULTS: with #+RESULTS: foo.



          Example:



          #+NAME: foo
          #+BEGIN_SRC emacs-lisp :var alpha=2 :results value
          (let* ((tol 0.1)
          (alpha_1 (- 90 alpha)))
          `(("angle" "symbol" "value" "max" "min") hline
          ("toe" "\alpha" ,alpha ,(+ alpha tol) ,(- alpha tol))
          ("c" "\alpha_1" ,alpha_1 ,(+ alpha_1 tol) ,(- alpha_1 tol))
          ))
          #+END_SRC

          #+TBLNAME: bar
          #+RESULTS: foo
          | angle | symbol | value | max | min |
          |-------+----------+-------+------+------|
          | toe | alpha | 1 | 1.1 | 0.9 |
          | c | alpha_1 | 89 | 89.1 | 88.9 |

          #+CALL: foo(alpha=bar[2,3])

          #+NAME: buh
          #+RESULTS:
          | angle | symbol | value | max | min |
          |-------+----------+-------+--------------------+-------------------|
          | toe | alpha | 1.1 | 1.2000000000000002 | 1.0 |
          | c | alpha_1 | 88.9 | 89.0 | 88.80000000000001 |


          The example demonstrates the update problem. The header variable alpha had the value 1 at the first evaluation of foo. Afterwards the value was changed to 2 but the source block foo was not evaluated again.

          The evaluation of the #+CALL statement does use the table value 1.1 at cell 2,3 directly without reevaluation of foo.






          share|improve this answer

























          • Quite informative, indeed. But there seems to be no way to not have the line #+RESULTS: in the results. One interesting question is, how is the system handling a let* form and turning it into a table? Is this something to do with :results value? But then if I do #+begin_src emacs-lisp :var table=bar (message "%S" table) #+end_src I get (("toe" "\alpha" 2 2.1 1.9) ("c" "$\alpha_1$" 88 88.1 87.9)) i.e., it's left out the title and horizontal line, i.e.,i.e., not completely reversible? Interesting stuff, nonetheless.

            – 147pm
            19 mins ago














          2












          2








          2







          One can add the following lines below unnamed source blocks (with bar replaced by the intended table name):



          #+NAME: bar
          #+RESULTS:
          ||


          The line with #+name: bar is preserved after the evaluation of the source block and || is replaced with the resulting table.



          Note, that the name bar really names the table and not the source block.
          That has the following consequences (probably among others I am not aware of at the moment):



          1. If you refer to the table name in the header arguments of another source block, say buh, then the bar source block is not reevaluated when buh is evaluated. The table is not updated but taken as argument for buh as it is.

            That is usually more an disadvantage than an advantage.

            One can call org-babel-execute-buffer to get correctly updated results.


          2. If the source block returns a string containing the formatted org-table rather than table data referring to the source block name in header variables gets you the string and not the table data. That is most often unwanted.

            In that case it is a big advantage that you can alternatively refer to the resulting table by its name.


          If the source block is named, e.g., foo replace #+RESULTS: with #+RESULTS: foo.



          Example:



          #+NAME: foo
          #+BEGIN_SRC emacs-lisp :var alpha=2 :results value
          (let* ((tol 0.1)
          (alpha_1 (- 90 alpha)))
          `(("angle" "symbol" "value" "max" "min") hline
          ("toe" "\alpha" ,alpha ,(+ alpha tol) ,(- alpha tol))
          ("c" "\alpha_1" ,alpha_1 ,(+ alpha_1 tol) ,(- alpha_1 tol))
          ))
          #+END_SRC

          #+TBLNAME: bar
          #+RESULTS: foo
          | angle | symbol | value | max | min |
          |-------+----------+-------+------+------|
          | toe | alpha | 1 | 1.1 | 0.9 |
          | c | alpha_1 | 89 | 89.1 | 88.9 |

          #+CALL: foo(alpha=bar[2,3])

          #+NAME: buh
          #+RESULTS:
          | angle | symbol | value | max | min |
          |-------+----------+-------+--------------------+-------------------|
          | toe | alpha | 1.1 | 1.2000000000000002 | 1.0 |
          | c | alpha_1 | 88.9 | 89.0 | 88.80000000000001 |


          The example demonstrates the update problem. The header variable alpha had the value 1 at the first evaluation of foo. Afterwards the value was changed to 2 but the source block foo was not evaluated again.

          The evaluation of the #+CALL statement does use the table value 1.1 at cell 2,3 directly without reevaluation of foo.






          share|improve this answer















          One can add the following lines below unnamed source blocks (with bar replaced by the intended table name):



          #+NAME: bar
          #+RESULTS:
          ||


          The line with #+name: bar is preserved after the evaluation of the source block and || is replaced with the resulting table.



          Note, that the name bar really names the table and not the source block.
          That has the following consequences (probably among others I am not aware of at the moment):



          1. If you refer to the table name in the header arguments of another source block, say buh, then the bar source block is not reevaluated when buh is evaluated. The table is not updated but taken as argument for buh as it is.

            That is usually more an disadvantage than an advantage.

            One can call org-babel-execute-buffer to get correctly updated results.


          2. If the source block returns a string containing the formatted org-table rather than table data referring to the source block name in header variables gets you the string and not the table data. That is most often unwanted.

            In that case it is a big advantage that you can alternatively refer to the resulting table by its name.


          If the source block is named, e.g., foo replace #+RESULTS: with #+RESULTS: foo.



          Example:



          #+NAME: foo
          #+BEGIN_SRC emacs-lisp :var alpha=2 :results value
          (let* ((tol 0.1)
          (alpha_1 (- 90 alpha)))
          `(("angle" "symbol" "value" "max" "min") hline
          ("toe" "\alpha" ,alpha ,(+ alpha tol) ,(- alpha tol))
          ("c" "\alpha_1" ,alpha_1 ,(+ alpha_1 tol) ,(- alpha_1 tol))
          ))
          #+END_SRC

          #+TBLNAME: bar
          #+RESULTS: foo
          | angle | symbol | value | max | min |
          |-------+----------+-------+------+------|
          | toe | alpha | 1 | 1.1 | 0.9 |
          | c | alpha_1 | 89 | 89.1 | 88.9 |

          #+CALL: foo(alpha=bar[2,3])

          #+NAME: buh
          #+RESULTS:
          | angle | symbol | value | max | min |
          |-------+----------+-------+--------------------+-------------------|
          | toe | alpha | 1.1 | 1.2000000000000002 | 1.0 |
          | c | alpha_1 | 88.9 | 89.0 | 88.80000000000001 |


          The example demonstrates the update problem. The header variable alpha had the value 1 at the first evaluation of foo. Afterwards the value was changed to 2 but the source block foo was not evaluated again.

          The evaluation of the #+CALL statement does use the table value 1.1 at cell 2,3 directly without reevaluation of foo.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 4 hours ago

























          answered 4 hours ago









          TobiasTobias

          15.2k11035




          15.2k11035












          • Quite informative, indeed. But there seems to be no way to not have the line #+RESULTS: in the results. One interesting question is, how is the system handling a let* form and turning it into a table? Is this something to do with :results value? But then if I do #+begin_src emacs-lisp :var table=bar (message "%S" table) #+end_src I get (("toe" "\alpha" 2 2.1 1.9) ("c" "$\alpha_1$" 88 88.1 87.9)) i.e., it's left out the title and horizontal line, i.e.,i.e., not completely reversible? Interesting stuff, nonetheless.

            – 147pm
            19 mins ago


















          • Quite informative, indeed. But there seems to be no way to not have the line #+RESULTS: in the results. One interesting question is, how is the system handling a let* form and turning it into a table? Is this something to do with :results value? But then if I do #+begin_src emacs-lisp :var table=bar (message "%S" table) #+end_src I get (("toe" "\alpha" 2 2.1 1.9) ("c" "$\alpha_1$" 88 88.1 87.9)) i.e., it's left out the title and horizontal line, i.e.,i.e., not completely reversible? Interesting stuff, nonetheless.

            – 147pm
            19 mins ago

















          Quite informative, indeed. But there seems to be no way to not have the line #+RESULTS: in the results. One interesting question is, how is the system handling a let* form and turning it into a table? Is this something to do with :results value? But then if I do #+begin_src emacs-lisp :var table=bar (message "%S" table) #+end_src I get (("toe" "\alpha" 2 2.1 1.9) ("c" "$\alpha_1$" 88 88.1 87.9)) i.e., it's left out the title and horizontal line, i.e.,i.e., not completely reversible? Interesting stuff, nonetheless.

          – 147pm
          19 mins ago






          Quite informative, indeed. But there seems to be no way to not have the line #+RESULTS: in the results. One interesting question is, how is the system handling a let* form and turning it into a table? Is this something to do with :results value? But then if I do #+begin_src emacs-lisp :var table=bar (message "%S" table) #+end_src I get (("toe" "\alpha" 2 2.1 1.9) ("c" "$\alpha_1$" 88 88.1 87.9)) i.e., it's left out the title and horizontal line, i.e.,i.e., not completely reversible? Interesting stuff, nonetheless.

          – 147pm
          19 mins ago


















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Emacs 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.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2femacs.stackexchange.com%2fquestions%2f48972%2fnaming-the-result-of-a-source-block%23new-answer', 'question_page');

          );

          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







          Popular posts from this blog

          名間水力發電廠 目录 沿革 設施 鄰近設施 註釋 外部連結 导航菜单23°50′10″N 120°42′41″E / 23.83611°N 120.71139°E / 23.83611; 120.7113923°50′10″N 120°42′41″E / 23.83611°N 120.71139°E / 23.83611; 120.71139計畫概要原始内容臺灣第一座BOT 模式開發的水力發電廠-名間水力電廠名間水力發電廠 水利署首件BOT案原始内容《小檔案》名間電廠 首座BOT水力發電廠原始内容名間電廠BOT - 經濟部水利署中區水資源局

          Prove that NP is closed under karp reduction?Space(n) not closed under Karp reductions - what about NTime(n)?Class P is closed under rotation?Prove or disprove that $NL$ is closed under polynomial many-one reductions$mathbfNC_2$ is closed under log-space reductionOn Karp reductionwhen can I know if a class (complexity) is closed under reduction (cook/karp)Check if class $PSPACE$ is closed under polyonomially space reductionIs NPSPACE also closed under polynomial-time reduction and under log-space reduction?Prove PSPACE is closed under complement?Prove PSPACE is closed under union?

          Is my guitar’s action too high? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)Strings too stiff on a recently purchased acoustic guitar | Cort AD880CEIs the action of my guitar really high?Μy little finger is too weak to play guitarWith guitar, how long should I give my fingers to strengthen / callous?When playing a fret the guitar sounds mutedPlaying (Barre) chords up the guitar neckI think my guitar strings are wound too tight and I can't play barre chordsF barre chord on an SG guitarHow to find to the right strings of a barre chord by feel?High action on higher fret on my steel acoustic guitar