2c:null 2d:["$","title",null,{"children":"Recursive mapping of 4-valued FORMs with vmaps | Peter Hofmann | Observable"}] 32:T492,md`I understand by an *interpretation* of a FORM or logical formula the replacement of its variables with logical values that are interpretable (have actual meaning) in the respective calculus. If all of the variables are interpreted, you are able to calculate the FORM to get a result under that specific interpretation. We can describe the set of all possible interpretations of a FORM (that make up a complete value table) as the cartesian product between all sets of the possible interpretations for each of its variables. ` /* Formally: ${tex` \text{Let } f \text{ be a FORM with a set of variables: } S = \{ a_1, …, a_n \} \\ \text{Then } \mathfrak{I} \text{ is the interpretation:} \\ \begin{aligned} \quad \mathfrak{I}(a_x,v) &:= a_x \rightarrow v \quad \text{, where } v \in V = \{0,1,2,3\} \\ \quad \mathfrak{I}(S) &:= \{ \mathfrak{I}(a_1,0), …, \mathfrak{I}(a_1,3) \} \times … \times \{ \mathfrak{I}(a_n,0), …, \mathfrak{I}(a_n,3) \} \end{aligned} \\ \text{such that } f(\mathfrak{I}(S)) = \{f(a_1 \rightarrow 0,…,a_n \rightarrow 0),…,f(a_1 \rightarrow 3,…,a_n \rightarrow 3)\} = R \subseteq V \text{ is the set of all possible results.} `} */33:Tb08,mdfn`

### Questions The sum of all possible interpretations of a 4-valued FORM is ${tex`4^n`}, where ${tex`n`} is the number of variables involved. Even with only 3 variables, there are 64 different interpretations, so value tables can become very crowded and it is hard to wrap your head around what is going on in a FORM. [SelFis](https://www.carl-auer.de/magazin/systemzeit/how-does-system-function-operate) can give powerful insights into macroscopic features of its behavior while the FORM operates iteratively on its own results, but they are not very helpful when it comes to low-level properties. When I study a FORM, there are some questions I frequently ask: - Under what conditions does it result in *m*? - What effects do undetermined/imaginary interpretations have? - What symmetries can I find in the value formation? - Are there other interesting value patterns? - Are there variables that are superfluous since they don't contribute to a change in results? - … In my German notebook [“Ansätze zur Interpretation diverser einfacher FORMen”](https://observablehq.com/@formsandlines/ansatze-zur-interpretation-diverser-einfacher-formen) from 2018[^3], I have tried to answer some of these questions in order to gain a fuller understanding of simple binary FORMs, but with three or more variables such a detailed analysis becomes much more complicated. In June 2019 I have added the feature of *value filters* to my [FORM tricorder](https://formwelten-institut.com/blog/form-tricorder), which makes it easier to dive deeper into what outcomes are possible for specific FORMs and what patterns they exhibit. Although this feature is very handy if you want to quickly check specific results or what outcomes specific interpretation patterns yield, the value table is still far from ideal as a device for pattern recognition. Visualizations can be powerful tools that help us to process data and find patterns much more efficiently than linear representations. What if we could have a compact, concise visualization of all interpretation results of a FORM that could be considered as something like the “fingerprint” or a “map” of its value structure (aka what I call [*formDNA*](https://observablehq.com/@formsandlines/the-dna-of-4-valued-forms))? With such a tool, we could recognize patterns more efficiently and this might help to answer some of the questions I stated above. Since John Venn, there have been various approaches to this task for boolean logic, but I have found that they are not scaleable to 4-valued logic in a “natural” or structurally pleasing way. There are, however, approaches that are similar to my own solution. If you are interested in my observations on this matter, take a look at the [Side note](#p_sidenote) of this article. `34:T5d6,{ const square = 10; const rhomb = Math.round(Math.sqrt(2 * square**2)); return mdfn`I call my implementation of this approach the **vmap** (which is short for “variable/value map”). Each variable of a FORM is represented as a diamond-shaped group that consists of four smaller such groups representing its interpretation states in four directions:[^4] - ← : \`\`0\`\` *(unmarked)* - → : \`\`1\`\` *(marked)* - ↓ : \`\`2\`\` *(undetermined)* - ↑ : \`\`3\`\` *(imaginary)* Following each direction, this process is repeated recursively down to the smallest diamonds (the ones that are actually drawn), which represent the interpretation results. Since letters or numbers are not very efficient for pattern recognition, I adopted the color coding convention Ralf Peyn used in [uFORM iFORM](https://uformiform.info): > ${Array.from([ {vnum:'0',vstr:'n',c:'#000000'},{vnum:'1',vstr:'m',c:'#4757ff'}, {vnum:'2',vstr:'u',c:'#ff0044'},{vnum:'3',vstr:'i',c:'#00ff5f'} ],(d,i) => `\`\`${d.vnum}\`\`*/${d.vstr}*: ${(i < 3 ? ', ' : '')}`)} Here you can see a schematic diagram of the structure of a *vmap* for 3 variables:

${await FileAttachment("201024_vmap-structure_2_groups@1.svg").image()}

Fig. 1: Recursive structure of a vmap

`}35:T721,md`

### Perspectives There is one important thing to consider with *vmaps*: the order of variables represent a focal hierarchy. The largest diamond will represent all interpretations for variable 1, the next smaller one for variable 2 and so on. This means that our visualization above is only one **perspective** and each permutation of the ordering sequence represents a different perspective on the FORM. The diagram below shows how you can think of perspectives as different paths to the same value structure and how two perspectives on the same FORM can appear very similar (or even identical), even though they identify values in entirely different locations:

${await FileAttachment("201024_vmap-structure_perspectives@1.svg").image()}

Fig. 2: Relation between the two vmap perspectives on (a)b

With ${tex`n`} variables there are ${tex`n!`} permutations of their ordering sequence. For transparency on which permutation is represented, I recommend to always attach the variable order as a sequence in the form v1 > v2 > v3 underneath the *vmap*. If no such annotation is given, the *default ordering* of variables must be assumed, which is alphabetical, or to be precise: ordered by [UTF-16](https://en.wikipedia.org/wiki/UTF-16) code values – which also matches the default ordering convention for *formDNA*. However, there is value in observing other perspectives on a *vmap*. For example, we can immediately tell if some variables are commutative in a FORM, if we compare the perspectives for each of their ordering permutations and see if they all look the same. This might not always be apparent in the FORM itself, as you can see in this example:`36:T546,mdfn`

### Subpatterns You may have noticed in the *vmap* above that it looks quite similar to the one for *ab* that we have seen before. This is no surprise, since the relation *abc* plays an important part in its FORM. It is often the case that some value patterns in a *vmap* look identical to patterns seen before in other *vmaps*. I call such embedded patterns *subpatterns*; they are an important feature of *vmaps* since they show how seemingly different FORMs are related to each other and how FORMs can be *composed* from other FORMs. In Figure 3 you can see how subpatterns can integrate other subpatterns, which can (since *vmaps* are compositional) become subpatterns of even bigger *vmaps* (and so on…):

${await FileAttachment("201024_vmap-structure_2_subpatterns@1.svg").image()}

Fig. 3: Integration of subpatterns in vmaps

(Sub-)patterns which are conceiled/fragmented in one *perspective* might be visually apparent in another, since the variables involved in that pattern may now be in close succession to each other and at the lowest end of the visual hierarchy, which means that they appear as coherent subpatterns of the *vmap*. Observe the subpatterns involved in the *vmap* for the FORM of *Rule4v30*:[^5]`37:Tcfd,p_sidenote = mdfn`

## Side note: Exploring other approaches Of course I am not the first one to come up with an approach to graphically represent value structures. Since George Boole invented the first algebraic logical calculus using class relations there have been numerous attempts at visualizing all possible intersections/combinations/subclasses between any number of variables/classes. An early and certainly the most well known of these attempts is the [Venn diagram](https://en.wikipedia.org/wiki/Venn_diagram), introduced in 1880 by John Venn. It is not only capable of representing the universe of class relations and states of affairs but can also be used as a reasoning device to read off conclusions that are not easily observed in symbolic notations. Unfortunately (among other weaknesses), it had the great deficit of being of practical use only for up to 4 classes. I also couldn't find a natural adaptation for the representation of undetermined and imaginary relations between FORMs. Later attempts (among which one may also count Wittgenstein's truth tables) tried to address this issue by using a tabular method. The [Marquand diagram](https://en.wikipedia.org/wiki/Allan_Marquand) and its successors have their merits when it comes to visualizing 4+ variables and finding minimal forms for logic optimization, but they are not very suitable for a polyvalent calculus, since they become very crowded and it is hard to relate values to their specific interpretations at a glance. They also don't seem to fit naturally with a 4-valued structure, making them less [iconic](https://en.wikipedia.org/wiki/Iconicity). In *uFORM iFORM*, Ralf Peyn demonstrated term reconstruction of binary rules for cellular automata using the [Karnaugh-Veitch diagram](https://en.wikipedia.org/wiki/Karnaugh_map),[^8] but I could not find a way to expand this method for the reconstruction of undetermined terms and even if I did, it does not seem to me like a natural solution for this problem. There is also the [“logical spectrum”](https://archive.org/details/proceedingsamer27sciegoog/page/n169/mode/2up) by Alexander Macfarlane from 1885, which is certainly the closest to my own approach (although I wasn't aware of it when I first came up with the *vmap*), but of course it is only one-dimensional as it is a binary system. There isn't much information about it on the web, but it is mentioned (among similar diagrammatic methods) in Martin Gardner's “Logic Machines and Diagrams” from 1982 (page 44f). A similar and one of the more recent and unique approaches is the [Randolph diagram](https://en.wikipedia.org/wiki/Randolph_diagram) by John F. Randolph from 1965. It is an extension of the original design by Warren McCulloch (which is similar and may be inspired by the “box-X” notation by C.S. Peirce)[^9] to work with an arbitrary amount of variables, for which he recursively divides the areas similar to what I did in my *vmap* diagrams. I encourage you to check it out, it is a nice pattern language for binary truth tables that can even be used to prove/disprove arguments visually. It seems great for education since it has the benefit of visualizing logical and even set-theoretical operations in a compact, iconic form. `38:T6b2,viewof footnotes = footlist([ {ref: '1', text: `Ludwig Wittgenstein: Tractatus Logico-Philosophicus, §4.31`}, {ref: '2', text: `These value tables can be generated computationally using the web application [FORM tricorder](https://formform.formsandlines.eu/tricorder/) that I have developed.`}, {ref: '3', text: `An update is coming soon, I am not satisfied anymore (Oct. 7, 2020) with some of my old interpretation attempts.`}, {ref: '4', text: `The reasons why I chose this specific ordering are (a) it is the convention already used by Ralf Peyn for his MindFORMs and (b) it makes sense to separate n/m and u/i in a horizontal and a vertical axis, since this is similar to how we map out the complex number plane where the imaginary number plays a role not unlike the imaginary value in our FORM calculus.`}, {ref: '5', text: `See Ralf Peyn: uFORM iFORM *(engl. edition, 2019)*, p. 140 for reference on *Rule4v30*.`}, {ref: '6', text: `These conventions include \`\`L\`\` \`\`E\`\` \`\`R\`\` (which is a sequence commonly used in SelFis) and my extensions \`\`-\`\` \`\`L\`\` \`\`R\`\` \`\`+\`\` and \`\`-\`\` \`\`L\`\` \`\`E\`\` \`\`R\`\` \`\`+\`\`.`}, {ref: '7', text: `See Ralf Peyn: uFORM iFORM *(engl. edition, 2019)*, p. 103 for reference on *Slit*.`}, {ref: '8', text: `See Ralf Peyn: uFORM iFORM *(engl. edition, 2019)*, p. 139.`}, {ref: '9', text: `For more about Peirce's box-X notation, its relationship with the Venn diagram and its symmetries can be found in the spanish paper [Simetría y Lógica](http://www.unav.es/gep/Articulos/SimetriaYLogica.pdf) by M. García, J. F. Gómez and A. Oostra.`} ], {separator: false, title: false})39:[{"id":"8b1f49d96d8678c45060c7d18ed2db8a0472b2c90ce0371da272f3821ecbad0e451eb1cffc362f6dd7013531a54bed611057995a1ddf42dcc3f18e18de8842c2","href":"https://static.observableusercontent.com/files/8b1f49d96d8678c45060c7d18ed2db8a0472b2c90ce0371da272f3821ecbad0e451eb1cffc362f6dd7013531a54bed611057995a1ddf42dcc3f18e18de8842c2","name":"201024_vmap-structure_2_subpatterns@1.svg","type":"image/svg+xml","lastModified":1603572647824.244,"size":32559},{"id":"9d322eec8c4cde5182ceb90a6ea84c56d822b2e553308076cabf380319ff9d42cb2d6778a6e3e5e480a3c54d2e685709630ca48c1bf419aaff886edb3cafe78f","href":"https://static.observableusercontent.com/files/9d322eec8c4cde5182ceb90a6ea84c56d822b2e553308076cabf380319ff9d42cb2d6778a6e3e5e480a3c54d2e685709630ca48c1bf419aaff886edb3cafe78f","name":"201024_vmap-structure_2_groups@1.svg","type":"image/svg+xml","lastModified":1603572657355.65,"size":12270},{"id":"934f3fa4698c93d803815a58bcc28f213c3211c5c3e97effdd09bb623f12d5023936a8c99f668641518a6b2661c4e125fed6db447f5422f75a8885054181ba42","href":"https://static.observableusercontent.com/files/934f3fa4698c93d803815a58bcc28f213c3211c5c3e97effdd09bb623f12d5023936a8c99f668641518a6b2661c4e125fed6db447f5422f75a8885054181ba42","name":"201024_vmap-structure_perspectives@1.svg","type":"image/svg+xml","lastModified":1603574004328.343,"size":71971}] 30:{"id":"18764c0b60f1a630","slug":"recursive-mapping-of-4-valued-forms-with-vmaps","title":"Recursive mapping of 4-valued FORMs with vmaps","thumbnail":"3c3b858b322d110a672b18393b1f302b1eeee0681c5883e3dcd4b17c822ac000","access_level":"public","create_time":"$D2019-09-27T09:50:00.939Z","update_time":"$D2020-11-01T11:44:28.196Z","view_time":null,"first_public_time":"$D2020-11-01T11:45:00.346Z","fork":false,"stars":3,"starred":false,"owner":{"type":"team","id":"e581d618919cd266","login":"formsandlines","name":"Peter Hofmann","avatar_url":"https://avatars-next.observableusercontent.com/da037e21011ef7f0553d73420763f4a2071c0bd9191552279dd8ebc154fc28b8","tier":"starter_2024"},"version":2806,"publish_version":2806,"role":null,"authored":false,"authors":[{"type":"individual","id":"b20948974f4dc365","login":"formsandlines","name":"Peter Hofmann","avatar_url":"https://avatars-next.observableusercontent.com/da037e21011ef7f0553d73420763f4a2071c0bd9191552279dd8ebc154fc28b8","tier":null}],"members":[{"type":"individual","id":"b20948974f4dc365","login":"formsandlines","name":"Peter Hofmann","avatar_url":"https://avatars-next.observableusercontent.com/da037e21011ef7f0553d73420763f4a2071c0bd9191552279dd8ebc154fc28b8","tier":null,"role":"editor"}],"comments":[],"custom_thumbnail":false,"trashed":false,"subscribed":null,"forks":1,"collection":{"id":"8fed57265de89c53","slug":"research","title":"Research","owner":{"id":"e581d618919cd266","login":"formsandlines","name":"Peter Hofmann"}},"type":"notebook","body":{"title":"Recursive mapping of 4-valued FORMs with vmaps","cells":[{"id":0,"value":"md`# Recursive mapping of 4-valued FORMs with *vmaps*`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1827,"value":"metadata({autor:\"Peter Hofmann\", created:\"27.09.2019\", fstPublish:\"01.11.2020\", thisPublish:\"01.11.2020\"})","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":8,"value":"md`This new visualization method is an attempt to show value distribution of FORMs and facilitate pattern recognition in the polyvalent logic of [uFORM iFORM](https://uformiform.info).`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":15,"value":"mdfn`---\n\n## Introduction\n\n### Value tables\n\nIn 1921, Ludwig Wittgenstein introduced the *truth table* in his Tractatus Logico-Philosophicus as a tool to examine the conditions for validity of a given proposition.[^1] Of course, these tables also work for other notions of logical validity, not just true and false.\n\nIn the case of *FORM logic* (the logic of cognition that Ralf Peyn introduced in [uFORM iFORM](https://uformiform.info) in 2017) where our validation criteria are whether the state of a FORM is *marked, unmarked, undetermined or imaginary,* I just call them **value tables**. Here is an example for \\`\\`((a)b)\\`\\`:[^2]\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":42,"value":"html`${valueTableWizard('((a)b)')}`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":821,"value":"$32","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":25,"value":"$33","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1042,"value":"md`

\n\n## The *vmap*\n\nI propose a recursive approach (inspired by the [Sierpinski carpet](https://en.wikipedia.org/wiki/Sierpinski_carpet)) to generate a map of all interpretation results for arbitrary variable numbers. This has some structural benefits like compositionality and makes it easy to find meaningful patterns and to navigate to specific interpretations quickly. It also fits quite well with 4-valued structures, since we can make use of geometrical symmetries in squares.\n\nThe basic idea is to group results together by recursively fixing one interpreted value of each variable in place while alternating the values of the next variable. This is, of course, exactly how numerical place-value systems work (e.g.: 00, 01, 10, 11, …). Conveniently, *formDNA* (on which I base my visualization method) already uses this recursive/nested ordering convention (see my [introductory notebook](https://observablehq.com/@formsandlines/the-dna-of-4-valued-forms) for details).`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":31,"value":"$34","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1360,"value":"md`Let me show you a vmap for just one variable *a*:`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1353,"value":"html`${formform.dna.vmap('a')}`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1384,"value":"md`Here you can clearly see how the directions (interpretation of the variable) and colors (interpretation results) match as there is no transformation in the FORM. If we mark *a*, values *n/m* and *u/i* are swapped, as expected:`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1463,"value":"html`${formform.dna.vmap('(a)')}`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1472,"value":"md`By adding another variable, the vmap expands by a factor of 4, since for every value of *a* we now also need an interpretion for *b*:`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1469,"value":"html`${formform.dna.vmap('ab')}`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":2281,"value":"md`To look up a specific value, we can just navigate the vmap using the four directions for each of the four interpretation values. For example, if we want the result for ${tex`(a \\rightarrow 2, b \\rightarrow 0)`}, we would just look at the bottom diamond group for *a* and within this group look at the left small red diamond to obtain the result 2.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1379,"value":"$35","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":2372,"value":"{\n const id = DOM.uid();\n const formula = '(({a,b}{b,a}{c,b}{b,c}{c,a}{a,c}{a,a}{b,b}{c,c}{c,b,a})(abc))';\n yield md`

`;\n \n formform.graph.createGraph('gsbhooks', formula, { parentId: id.id }); \n}","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":2199,"value":"html`${formform.dna.vmapPerspectives('((L)ER)((E)L)((R)L)')}` // Rule4v30","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1537,"value":"mdfn`For ease of reference, I call the *perspective* that has the default or conventional[^6] variable order of a FORM the *primary perspective*. In the primary perspective of this *vmap*, we see a familiar pattern for the variables *E* and *R* if *L* is unmarked. This is yet another instance of the pattern for *ab* that we have already seen.\n\nBut another interesting pattern can be observed in all four perspectives where either *E* or *R* is the first variable. It looks just like the *vmap* for \\`\\`((a)b)((b)a)\\`\\` (which is known as *“either-or”* or the FORM of *“Slit”* in uFORM iFORM)[^7]:`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":2384,"value":"{\n const id = DOM.uid();\n const formula = '((a)b)((b)a)';\n yield md`

`;\n \n formform.graph.createGraph('gsbhooks', formula, { parentId: id.id }); \n}","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":2205,"value":"html`${formform.dna.vmapPerspectives('((a)b)((b)a)')}`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1540,"value":"md`What we have observed from *vmaps* in this example is easily verified by looking at the structure of the FORM: \\`\\`((L)ER)((E)L)((R)L)\\`\\`. But such patterns are not always apparent in a formula, especially if it is not simplified yet or if we are dealing with complex undetermined FORMs.\n\nIn the *vmap* for \\`\\`((a)b)((b)a)\\`\\` we can also see that both perspectives a > b and b > a look the same, which means that *a* and *b* are commutative in this FORM. As you may have noticed, this is also true for three pairs of perspectives on the *vmap* of *Rule4v30* that we have seen above.\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":2542,"value":"md`

\n\nI hope you can see now that *vmaps* make value structures of FORMs much more visible and iconic than value tables. It turns out they are especially useful for algebraic simplification, since we can, for example, analyze *vmaps* from parts of a FORM and replace these parts with equivalent FORMs because we know that their patterns are congruent.\n\nAnother interesting application is FORM (de)composition, but I will explain the details of this process in another notebook. This introduction only scratches the surface on the topic of *vmaps* and I still find more interesting properties as I am writing that I would like to discuss in future articles. Further applications are listed in the following section.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":903,"value":"md`

\n\n### Possible applications for *vmaps*\n\n- Analyzing and understanding compositional patterns in FORMs, which leads to a better/fuller understanding on how certain FORMs work and relate to each other\n- *vmaps* reveal symmetries and self-similar scaling patterns in FORMs and indicate complexity and randomness similar to cellular automata\n- FORM composition and decomposition using patterns may aid in model design\n- Pattern-based manipulation, reconstruction or deconstruction (e.g. by specific values or subpatterns) of a FORM can help to find interesting properties in combination with SelFi-analysis\n- Pattern matching can help with algebraic simplification of FORMs (although it is not clear yet if/how a canonical normal form can be extracted or if there is even such a thing for 4-valued FORMs\n- *vmaps* can act as a QR-code-like signature for *formDNA*, which could be especially useful on printed media where huge FORMs or formDNA strings cannot easily be copied\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1642,"value":"md`

\n\n### Implementation and usage\n\nI have integrated functions for generating *vmaps* and *vmap perspectives* into [formform](https://github.com/formsandlines/formform). The easiest way to use them is with my [FORM tricorder](https://formform.formsandlines.eu/tricorder/).\n\nYou can also *require* or *import* \\`\\`\\`formform\\`\\`\\` in your own coding projects or Observable notebooks and use my functions to generate HTML code for *vmaps*. Take a look at https://observablehq.com/@formsandlines/formform-vmap-generator for some explanations and explorations of these functions.`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":898,"value":"$37","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1934,"value":"md`---\n\n### Footnotes`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1904,"value":"$38","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":38,"value":"md`---\n### Appendix`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":2531,"value":"html`\n${typoCSS}\n${formCSS}\n${valueTableCSS}\n${footnoteCSS}\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1890,"value":"LANG = 'en'","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1937,"value":"import {valueTableWizard, valueTableCSS} with { LANG as setLang } from '99b8f5ac562cf4e6@629'","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":34,"value":"import {formTric, formCSS} with { LANG as setLang } from '793523caac58b657@504'","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1895,"value":"import {metadata, typoCSS} with { LANG as setLang } from 'b537017f986f4d7c@307'","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1829,"value":"import {mdfn, footlist, footnoteCSS} with { footnotes as footnotes, LANG as setLang } from '4a01c6bf448dded8@1125'","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":1899,"value":"formform = require('formform@0.9.2')","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"}],"files":"$W39","stdlib":"1","titling":"auto"}} 31:"$30:body"