The machazot of the Ramchal

The Ram’hal zt”l wrote machazot ! This may surprise some charedim, but it’s a fact !

And these machazot have been preserved. Have a look on

לישרים תהלה
מעשה שמשון
מגדל־עז, או ֻתמת ישרים

That the Ramchal wrote theater plays will not astonish those who know the history of the Jews in Italy and Amsterdam. They loved the culture of the Renaissance and devoted themselves to latin letters without the slightest shame.

The Leyesharim tehila was performed in Amsterdam at the wedding of Yaakob Chaves, a student of Ramchal.

According to the mequbalim, like Rav Mordechai Chriqui shlit’a, these machazot are allegories that teach us the Kabbalah of Ariza”l.

A small note on academic publications dealing with Judaism : these publications have made comparatism a kind of religion.

Undoubtedly these poor little Jews in exile in the world of the university are obliged to play the card of multiculturalism to hope to survive as much as possible in faculties dominated by the iron hand of the left …

And these publications strongly insist that Ramchal took as a model the pieces of Giovanni Batista Guarini that he saw in the company of his professor of secular matters, Rav Isaac Cantarini.

In the same way, these unfortunates scoff at the fact that the Ramchal took a treatise on logic written by a Protestant theologian as a model of his Sefer hahigayone. But logic is universal ! The Ramchal used this book as a template. That’s all !

The pieces of Guarini are written in isometric verses. The musicality of the dialogues had to please this stylish ending that is Ramchal. On the other hand, their content, saturated with roman mythology and latin hedonism, must not have made a strong impression on the author of the Messilas yesharim.

The Ramchal took the fruit after removing the bark. He found in the mud sparks of light, extracted and raised them. Is not this a natural step for a Kabbalist ? I even think that he has been ingenious in taking particularly goyish models to have the pleasure of operating a profound and decisive tikun.

One can dream that the Ramchal theater can be reborn and studied with the attention it deserves by those who deserve it.

The mnemonic of the Ramchal

Having found the Sefer hadiqduq of the Ramchal, I began to study it with a sephardi scholar at the kollel Bobov. The kehila of Antwerp is well-known for his friendly atmosphere.

The tree structure of the Sefer hadiqduq is eye-catching and even ear-catching.

But we remarked some inconsistencies and some phrases without real significance, the kind of phrases that you can find in conversation but not in a book. The Rav Brieger writes in his introduction that he used two different manuscripts written by the talmidim of the Ramchal.

At the first sight, I was a little bit disappointed but I understood that this sefer gives a  living picture of the structured memory of the Ramchal.

Let’s have a trip in Amsterdam in the years 1730. We are in a classroom of the portuguese synagogue. The Ramchal teaches diqduq to his talmidim. He does not have a book or manuscript. He has everything in his mind’s eye and he dictates to his talmidim.

I think it is a proof that the Derech Tevunos is not a book about logic but about mnemonic or, more exactly, about ramist mnemonic, a mnemonic based on logic unlike the ciceronian mnemonic, also called method of loci, based on visualization of three dimensional images.

A bit of history : In 1966, Dame Frances Yates, researcher at the Warburg Institute publishes a book called The Art of Memory and the world discovers a forgotten science.

The Greeks and the Romans, as any traditional cultures, attached special significance to memory. Mnemosyne, the goddess of memory, was the mother of the nine muses, the goddesses of sciences and arts. Since the rise of modern science, memory seems to be just a tool and with the rise of computers, memory seems to be obsolete.

The traditional Art of Memory is based on the use of mental three dimensional images. The orator or the poet builds in his memory such images where he attaches the topics and the words of his texts. The Art of Memory was used first and foremost for composition. Poets like Petrarch and Dante Alighieri gave very precise information about how they used the Art in their works. The Ramchal knew those authors because he studied latin and italian authors with the Rav Isaac Chayyim Cantarini.

In the middle ages, the Art of Memory was used by theologians and when printing came, a lot of textbooks about the Art became available. The baroque aesthetics produced huge catalogs of images that are sometimes quite weird and therefore inadequate for bnei torah…

You can find here a very funny Memory Palace designed by Robert Fludd to teach music theory. Perhaps some user interface designers could find here some inspiration…

Came a reaction : Pierre de la Ramée, a devout protestant, was horrified by the use of images. He build a mnemonic based on logic by using the tree structure as fundamental pattern.

And then the Ramchal discovered the Ramist mnemonic, a natural mnemonic for a brain trained by the gemara. This has been proven by Charles Manekin in his seminal paper On Moses Hayyim Luzzatto’s Logic and on Ramist Influence in His Writings.

By the way, the tree structure was known by the Ramchal since his childhood. We can see a tree used for the classification of metaphors in his Leshon Limudim (on the page 84 of the pdf). A book about rhetoric and poetics he wrote at the age of 17 when he was in Padua.

The Derech Tevunos is therefore a book about mnemonic : how to organize memory by the logical analysis of the texts to be learned.

A framework to ease the analysis of the gemara

This framework is just a method to parse the text in a tabular form in order to ease understanding, memorization and communication.

This method is neutral : it does not imply a particular hashkafa.

The basic idea is explained by the Ramchal zt”l in the Derech tevunos.

The idea of a tabular structure comes from the theory of relational databases.

Here a text becoming viral in the Kollel Bobov and other hot places in Antwerp.

And here my commentary of Bava Kamma 2a.

Trees (3) : ltree extension of PostgreSQL

We created the mind map of the book “The pedagogy of the Ramchal” with WiseMapping. In the future, we will develop our own visual mind mapping tool bs”d.

We want now

  • to import this mind map in our database using the ltree extension of PostgreSQL, a implementation of trees with materialized paths, pre-calculated paths that describe ancestry of nodes
  • to encapsulate this ltree in RelGraph, our relational data model for graphs
  • to draw the tree with a R script

We export the mind map in text format and we remove the leading spaces in vi with :

:%le

Then we load raw data in a staging table because it is often a good idea to use the expressive power of SQL to parse and arrange raw data :

# we start psql with user postgres (needed by copy)
sudo -i -u postgres psql -d higayone

# we do a bulk copy
copy tree_staging from '/home/mchl/Desktop/Blog/map.txt';

The table tree_staging is like that :

input_line
------------------------------------------------------------------------------
1 The pedagogy of the Ramchal
1.1 The man
1.1.1 His life
1.1.1.1 Padua
1.1.1.1.1 Yeshayah Bassan
1.1.1.1.2 Isaac Cantarini
1.1.1.1.3 Aviad Sar Shalom Basilea
1.1.1.2 Amsterdam
1.1.1.2.1 Talmidim
1.1.1.2.1.1 Marranes
1.1.1.2.1.2 Modern science
1.1.1.3 Eretz Israel
...

Then we create extension ltree :

create extension if not exists ltree;

Then we create table and sequence for ltree :

drop table if exists ltree_node;
drop sequence if exists ltree_node_sequence;
create sequence ltree_node_sequence;

create table ltree_node (
 node_id integer primary key
    default nextval('ltree_node_sequence')
 ,node_name text
 ,node_path ltree
);

It is necessary to drop the table before the sequence, otherwise PostgreSQL will raise an error. Then we add a gist index on the column ltree  :

create index path_gist_idx on ltree_node using gist(node_path);

Then we populate the ltree with the data of the staging table :

insert into ltree_node(node_name, node_path) select
 substring(input_line, 
    char_length(substring(
        input_line from '[0-9.]*[ ]')) + 1) as node_name
 ,cast(substring(input_line from '[0-9.]*') as ltree) as node_path
from tree_staging;

The line

substring(input_line, 
    char_length(substring(
        input_line from '[0-9.]*[ ]')) + 1) as node_name

means that we take every character since the beginning of the line until the first white space. And the line

cast(substring(input_line from '[0-9.]*') as ltree) as node_path

means that we take every character since the first white space until the end of the line.

Let’s have now a look on a first application of ltree using the <@ operator. This query gives all the paths of the tree :

 select
 ln1.node_id
 ,array_to_string(
    array_agg(ln2.node_name order by ln2.node_path)
              ,'/') as full_path_name
from  
 ltree_node as ln1 
inner join 
 ltree_node as ln2 
on 
 ln1.node_path <@ ln2.node_path 
group by 
 ln1.node_id, ln1.node_path, ln1.node_name
order by 
 ln1.node_id, full_path_name;

The line

ln1.node_path <@ ln2.node_path

means that the left argument is a descendant of the right one. And array_agg is an aggregate function (working with group by) transforming his arguments into an array.

The output is like that :

node_id full_path_name
------- --------------
1       The pedagogy of the Ramchal
2       The pedagogy of the Ramchal/The man
3       The pedagogy of the Ramchal/The man/His life
4       The pedagogy of the Ramchal/The man/His life/Padua
5       The pedagogy of the Ramchal/The man/His life/Padua/Yeshayah Bassan
6       The pedagogy of the Ramchal/The man/His life/Padua/Isaac Cantarini
7       The pedagogy of the Ramchal/The man/His life/Padua/Aviad Sar Shalom Basilea
8       The pedagogy of the Ramchal/The man/His life/Amsterdam
9       The pedagogy of the Ramchal/The man/His life/Amsterdam/Talmidim
10      The pedagogy of the Ramchal/The man/His life/Amsterdam/Talmidim/Marranes
11      The pedagogy of the Ramchal/The man/His life/Amsterdam/Talmidim/Modern science
12      The pedagogy of the Ramchal/The man/His life/Eretz Israel
...

We populate now the tables of RelGraph, our relational model for graphs.

1. We create a new graph :

insert into graph(graph_name) values('Book');

2. We populate the table node :

insert into node(graph_id, node_name) select
 (select graph_id from graph where graph_name = 'Book')
 ,node_name
from
 ltree_node;

3. We populate the table edge :

insert into edge(from_node, to_node) select
 ln2.node_id as from_node
 ,ln1.node_id as to_node
from
 ltree_node ln1
 ,ltree_node ln2
where
 ln1.node_path = subpath(ln2.node_path
                         ,0
                         ,nlevel(ln2.node_path) - 1);

We see here two other functions of ltree :

  • subpath : subpath of tree starting at the beginning and starting at the penultimate component
  • nlevel : gives the number of components of the path

But we have to find solutions to make visible in RelGraph the insert / update / delete performed in the ltree. It will be the topic of a future post.

Having node and edge populated, we can run the following R script (which, in my private language, I call a graph slurper) to visualize the tree :

require(visNetwork)
require(RPostgreSQL) 

# establish connection 
driver ← dbDriver("PostgreSQL") 
connexion ← dbConnect(driver, dbname="higayone"
                      ,host="localhost", port=5432
                      ,user="mchl", password="secret")                              

# populates nodes and egdes
nodes ← dbGetQuery(connexion, "
 select 
   node_id as id
  ,node_name as label
 from node
 order by node_id;") 

edges ← dbGetQuery(connexion, "
 select 
   from_node as from
  ,to_node as to
 from edge
 order by from_node, to_node;") 

visNetwork(nodes, edges) %>%
  visNodes(font = '10px', shape = 'ellipse')

 

Here is a thumbnail (I am afraid I cannot do better with the free version of WordPress)  :

Book

If we want to generate a table of contents, we must think at two things :

  • node_path ‘1’ becoming the title of the book, it must be removed from the tree
  • for all other node_path, we simply remove the ‘1.’ at the beginning
select
 substring(node_path::text, 3, char_length(node_path::text))
 ,repeat('   ', nlevel(node_path)- 2) || node_name
from
 ltree_node
where node_path != '1'
order by node_path;

That gives :

1           The man
1.1            His life
1.1.1             Padua
1.1.1.1              Yeshayah Bassan
1.1.1.2              Isaac Cantarini
1.1.1.3              Aviad Sar Shalom Basilea
1.1.2             Amsterdam
1.1.2.1              Talmidim
1.1.2.1.1               Marranes
1.1.2.1.2               Modern science
1.1.3             Eretz Israel
...

RelGraph : a relational model for graphs

Terminology

{ graphs } = { trees } ∪ { networks }

A graph = { nodes } ∪ { edges }

Why a relational model for graphs ?

It is more natural to implement graph structures with a graph oriented database. But we have good reasons to use a relational database as explained here.

The Predicate Calculus is a very simple theory : it is the basic set theory that every child knows. Of course, with the relational model, we are obligated to follow the strict discipline of normal forms. But we see the benefits when we write queries because the Predicate Calculus is a very elegant theory : the queries are naturally deductible from the data model. It is like geometry : with a good system of axes, the equations can be greatly simplified.

How to represent a graph with relations

A graph is the union of two sets : the set of nodes and the set of edges. It is natural to represent a graph by two relations (two tables in SQL jargon).

node(id, info)
edge(from_node, to_node, name, info)

where from_node and to_node (the nodes connected in this order) are FKs to node_id.

The actual implementation can be done by a specialized library. Something like ltree for trees in PostgreSQL. The implementation is encapsulated in our model. The relation between PKs and FKs is hidden. It is of course not necessary that this implementation follows the relational model. The application developer sees usual relational tables.

Functions

To node and edge,  we would like to ask a lot of things :

  • Select/insert/update/delete nodes, edges and subgraphs
  • Enumerate nodes and edges
  • List all nodes pointing to a given node
  • List all nodes pointed by a given node
  • Do you find cycles ? or trees ?
  • Do  you find disconnected graphs or isolated nodes ?
  • If the graph is a network, build spanning trees

For a tree, we would like to ask :

  • Do a breadth-first or a depth-first search
  • Give lexicographic notation (1, 1.1, 1.1.1,…)
  • Delete a subtree starting at a given node
  • Give all the ancestors of descendants of a given node

Associations and groups

Having interactive visualizations in our agenda, we need two other relations : associations and groups.

Association : we would like to connect nodes with specific edges.

association(from_node, to_node, name, info)

Groups : we would like to group nodes having a common property. We don’t forget that a node can be belong to several groups : there is a relation many-to-many between the relations node and groups. We need a go-between relation populated with the PKs of both relations.

node(id, name, nfo)
node-grouping(node_id, grouping_id)
grouping(id, name, info)

where node_id is a FK to node(id) and grouping_id is a FK to grouping(id).

The logical model

We add a relation graph that keeps track of all the graphs created in the schema. In such a way, all graphs use the same basic relations that are created only once.

graph(id, name, info)

node(id, graph_id, name, info)

edge(edge_id, from_node, to_node, name, info)

association(from_node, to_node, name, info)

node_grouping(node_id, grouping_id)

group(grouping_id, name, info)

graph
With the relations node, edge, association and groups well populated, we can expect

  • to have access to data from a programming language in a very direct way
  • find a visualization library for graphs that will interpret our data structures in a very direct way

The physical model

create sequence graph_sequence;
create table graph (
 id integer not null
    default nextval('graph_sequence')
    primary key
 ,name text
 ,info text
);

create sequence node_sequence; 
create table node ( 
 id integer not null 
    default nextval('node_sequence') 
    primary key
 ,graph_id integer not null
    references graph(id) 
 ,name text
 ,info text
); 

create sequence edge_sequence;
create table edge (
 id integer not null
    default nextval('edge_sequence') 
 ,from_node integer not null 
    references node(id)
    on update cascade 
    on delete cascade
 ,to_node integer not null 
    references node(id)  
    on update cascade 
    on delete cascade
 ,primary key(from_node, to_node)
); 

create sequence association_sequence; 
create table association ( 
 id integer not null 
    default nextval('association_sequence') 
    primary key 
 ,from_node integer not null 
    references node(node_id) 
 ,to_node integer not null 
    references node(node_id) 
 ,name text
 ,info text 
); 

create sequence grouping_sequence; 
create table grouping ( 
 grouping_id integer not null 
    default nextval('grouping_sequence') 
    primary key 
 ,name text 
 ,info text
); 

create table node_grouping ( 
 node_id integer not null 
    references node(id) 
 ,grouping_id integer not null 
    references grouping(id) 
 ,primary key(node_id, grouping_id)
);

 

Trees (2) : visualization with R

 Rplot

This mind map represents the following hierarchy of topics we used in a previous post (this one is small and inactive but with the visNetwork graph visualization R package, it will possible to develop animated and interactive mind maps) :

Root
            Relational theory
                      First-order predicate logic
                                Syntax
                                Rules of inference
                                Deductive systems
                                Semantics
                      Three-valued logic  
                      Normal forms
                                Functional dependencies
                                Multivalued dependencies
                                1NF
                                2NF
                                3NF
                                BCNF
                                4NF
                                5NF
                                DKNF
           SQL
                      Types and domains
                      PKs & FKs
                      Relations
                      Operators
                            Restriction
                            Projection
                            Joins
                               Cross join
                               Inner join
                               Left outer join
                               Right outer join
                               Full outer join
                            Union
                            Intersection
                            Difference
                            Divide
                      Aggregations
                      Constraints
                      Views

 

We changed the data structure for the implementation of Adjacency List Model for trees with relational operators.

Instead of

tree(node_id, node_up_id, topic) 
    where node_up_id is a reference (FK) to node_id

we use a two-tables representation of  a tree :

nodes(node_id, topic)

edges(from_node, to_node) 
    where from_node and to_node are references (FKs) to nodes.node_id

It’s always better to use normalized data model. It takes often a bit of effort but the queries will be easier to design.

We implement in PostgreSQL this model :

create sequence node_sequence;

create table nodes (
 node_id integer not null 
    default nextval('node_sequence') 
    primary key
 ,topic varchar(128)
);

create table edges (
 from_node integer not null 
    references nodes(node_id)
    on update cascade
 ,to_node integer not null
    references nodes(node_id)
 check (from_node != to_node)
 ,primary key(from_node, to_node)
 );

The visualization of the mind_map with the visGraph R library is now straightforward.

1. We load the libraries and we make connection to the database :

require(RPostgreSQL)
require(visNetwork)

driver ← dbDriver("PostgreSQL") 
connexion ← dbConnect(driver,
 ,dbname="higayone"         
 ,host="localhost", port=5432
 ,user="mchl", password="secret")                 

2. We populate nodes and edges, the R data structure is a direct mapping of the relational structure (a R data frame is relational table) :

nodes ← dbGetQuery(connexion, "
 select
   node_id as id
  ,topic as label
 from nodes
 order by id_topic;")

edges ← dbGetQuery(connexion, "
 select
   from_node as from
  ,to_node as to
 from edges
 order by to_node, from_node;")

3. We call the graphic interface, the visNetwork data structure is direct mapping of the R data structure (visNetwork function waits nodes identified by id and label and edges identified by from and to) :

visNetwork(nodes, edges) %>%
 visNodes(font = '10px', shape = 'ellipse')