y_nelson 2.3.0 → 2.3.2

data/Object_model_of_YNelson_and_YPetri.lyx

@@ -153,8 +153,15 @@ YPetri
 \end_layout
 
 \begin_layout Standard
-Whereas for the beginners, there is tutorial available to YPetri / YNelson,
- and the classes are more or less fully documented, the internal workings
+For the beginners, there is tutorial available for 
+\family typewriter
+YPetri
+\family default
+ / 
+\family typewriter
+YNelson
+\family default
+, and the classes are more or less fully documented, the internal workings
  and the design intent might not be immediately obvious.
  The purpose of is document is to make the reader faster achieve their understan
 ding.
@@ -705,17 +712,45 @@ Transition
 \family typewriter
 YPetri::Transition
 \family default
- class represents functional transitions of a (functinal) Petri net.
- It includes 
+ class represents Petri net transitions.
+ They are 
+\begin_inset Quotes eld
+\end_inset
+
+functional
+\begin_inset Quotes erd
+\end_inset
+
+ in the sense that they may have mathematical functions attached to them,
+ that govern their firing according to the current marking of the Petri
+ net places.
+ (Term 
+\begin_inset Quotes eld
+\end_inset
+
+functional
+\begin_inset Quotes erd
+\end_inset
+
+ has also been used in other meanings in conjunction with Petri nets.) 
+\family typewriter
+YPetri::Transition
+\family default
+ class utilizes 
 \family typewriter
 NameMagic
 \family default
- and is normally used as a parametrized subclass (PS) depending on 
+ mixin.
+ 
+\family typewriter
+YPetri::Transition
+\family default
+ class is normally used as a parametrized subclass (PS) depending on 
 \family typewriter
 YPetri::World
 \family default
 .
- The main attribute of a 
+ The most prominent attribute of a 
 \family typewriter
 Transition
 \family default
@@ -806,7 +841,7 @@ NameMagic
 YPetri::World
 \family default
 .
- It is basically a specialized collection of of 
+ It is basically a specialized collection of 
 \family typewriter
 Place
 \family default
@@ -1525,10 +1560,6 @@ run( upto: ...
 
 \family typewriter
 #dup
-\family default
-, alias 
-\family typewriter
-#at
 \family default
  – duplicate of the receiver simulation, with the possibility to change
  time and/or other simulation settings.
@@ -2412,8 +2443,8 @@ Core
 \family typewriter
 Simulation
 \family default
- for the purpose of facilitating the use of different machines to run the
- simulation.
+ for the purpose of facilitating future use of different machines to run
+ the simulation.
  At the moment, plain Ruby is used to compute the simulation steps.
  
 \family typewriter
@@ -3101,7 +3132,7 @@ DataSet
 \family default
  
 \emph on
-double parametrized
+doubly parametrized
 \emph default
  by the instance.
  Therefore, also instance methods include:
@@ -3116,7 +3147,11 @@ double parametrized
 \family typewriter
 Features.Record
 \family default
- PS double parametrized by the receiver.
+ PS parametrized by the 
+\family typewriter
+Features
+\family default
+ instance.
 \end_layout
 
 \begin_layout Itemize
@@ -3128,7 +3163,11 @@ Features.Record
 \family typewriter
 Features.DataSet
 \family default
- double parametrized by the receiver.
+ PS parametrized by the 
+\family typewriter
+Features
+\family default
+ instance.
 \end_layout
 
 \begin_layout Standard

data/lib/y_nelson/place.rb

@@ -1,5 +1,5 @@
 # YNelson::Place is analogical to a spreadsheet cell. It is based on
-# YPetri::Place and offers simlar interace.
+# YPetri::Place, which is made into a ZZ object using Yzz mixin.
 # 
 class YNelson::Place < YPetri::Place
   include YNelson::Yzz
@@ -18,13 +18,29 @@ class YNelson::Place < YPetri::Place
     
   end
 
-  # Subclass of YTed::Zz::Side.
+  # FIXME: Because Yzz::SidePair actually parametrizes ::Yzz::PoswardSide
+  # and ::Yzz::NegwardSide, the following two class definitions will probably
+  # be ignored. I'm too tired to look into this now, this is for later
+  # user comfort development of YNelson.
+  #
+  # Subclass of Yzz::PoswardSide.
   # 
-  class Side < Side
+  class PoswardSide < Yzz::PoswardSide
     # "Budding": creation of new cells from the cell sides.
     # 
     def bud( value: L!, f: nil )
-      # FIXME
+      # FIXME -- budding from posward side
+    end
+    alias :>> :bud
+  end
+
+  # Subclass of Yzz::NegwardSide.
+  # 
+  class NegwardSide < Yzz::NegwardSide
+    # "Budding": creation of new cells from the cell sides.
+    # 
+    def bud( value: L!, f: nil )
+      # FIXME -- budding from negward side
     end
     alias :>> :bud
   end

data/lib/y_nelson/version.rb

@@ -1,4 +1,4 @@
 module YNelson
   DEBUG = false
-  VERSION = "2.3.0"
+  VERSION = "2.3.2"
 end

data/lib/y_nelson.rb

@@ -17,37 +17,34 @@ require_relative 'y_nelson/dimension_point'
 require_relative 'y_nelson/agent'
 require_relative 'y_nelson/dsl'
 
-# YNelson is an implementation of a cross between Ted Nelson's Zz structure, and
-# the functional Petri net (FPN). The resulting data structure, which combines
-# the qualities of FPNs with those of relational databases, I refer to as Nelson
-# net throughout this text.
+# YNelson is an implementation of a cross between Ted Nelson's Zz structure,
+# and a specific type of universal Petri net (PN), to whose creation I put
+# particularly large amount of design considerations. The resulting data
+# structure, combining the qualities of the said PN with those of a relational
+# database, I refer to as Nelson net.
 # 
-# A Nelson net, from a certain point of view, is as a genralization of a
-# spreadsheet software. In his explanations of Zz structures, Ted Nelson makes
-# wide use of metaphors well known from spreadsheets: cells, ranks, rows,
-# columns, cursors, selections... Nelson net, as implemented here, adds
-# "formulas" to the mix: Spreadsheet "formulas" are simply represented by FPN
-# transitions.
+# A Nelson net can be viewed as a genralization of a spreadsheet. Ted Nelson
+# does note similarities between zz structures and spreadsheets and makes wide
+# use of spreadsheet metaphors in his terminology: cells, rows, columns, ranks,
+# cursors, selections... Nelson net arises by adding spreadsheet "formulas" to
+# the mixture, which are nothing else than PN transitions.
 # 
-# Nelson net disposes of the arbitrary constraints on FPNs, and also extends the
-# plain orthogonal structure of spreadsheet "cells", as can be seen in the
-# existing spreadsheet implementations:
-# 
-# 1. Both places and transitions of the FPN take part in zz structure.
-# 2. Formula-based transitions are upgraded to standalone FPN transitions.
+# From spreadsheet software implementations, we are used to various constraints
+# regarding the available PN transitions. In Nelson nets, these constraints are
+# removed by the Nelson nets being based on the said formally defined universal
+# PN. Also, the plain globally orthogonal structure of rows/columns/sheets
+# typical for spreadsheet implementations is generalized to the locally
+# orthogonal zz structure with unlimited number of dimensions. The generalization
+# is as follows:
+#
+# 1. Both places and transitions of the PN are zz objects.
+# 2. The way the spreadsheet is based on PNs is properly formalized.
 # 
-# The implications of the differences of a zz structure from ordinary
-# hyperorthogonal structures have been, to a degree, explained by Ted Nelson
-# himself. There is a growing body of literature on zz structure applications,
-# including the applications in bioinformatics.
-#
-# As for functional Petri nets, their power in computing is well recognized (eg.
-# Funnel, Odersky 2000). FPNs are sometimes just called functional nets, because
-# Petri originally described his nets as timeless and functionless. However, in
-# special-purpose applications, such as biochemical applications, to which I
-# incline, it is appropriate to honor Petri, who designed his nets specifically
-# with chemical modeling in mind. In biochemistry, it is common to call
-# functional nets Petri nets (Miyano, 200?).
+# Luckily, Ted Nelson and his crowd already put energy into explaining the ins
+# and outs of zz structures. There is a growing body of literature on this,
+# including zz structure applications in bioinformatics. And I add to this my
+# explanation of the extended PN type that I designed and implemented in YPetri
+# gem (gem install YPetri), which is a dependency of YNelson.
 # 
 module YNelson
   # Singleton class of YNelson is a partial descendant of YPetri::World. It
@@ -100,3 +97,126 @@ module YNelson
 end
 
 puts "YNelson: Nelson net domain model and simulator. ⓒ 2013 Boris Stitnicky"
+
+
+# ===========================================================================
+# !!! TODO !!!
+# 
+# Refactoring plans
+# 
+# When 'y_petri' is required, class Module will gain the capacity to respond
+# to y_petri DSL commands (#Place, #Transition etc.).
+# 
+# This will allow syntax such as:
+#
+# # syntax 1
+# 
+# module Foo
+#   P1 = Place()
+#   P2 = Place()
+#   P3 = Place()
+# end
+#
+# module Bar
+#   T1 = Transition s: { P1: -1, P2: 1 }
+# end
+#
+# module Baz
+#   T2 = Transition s: { P2: -1, P3: 1 }
+# end
+#
+# In this syntax, there are two questions:
+# 1. Which world will the defined nodes belong to?
+# 2. Which net(s) will they be automatically included in?
+#
+# The goal here is to be able to construct things like:
+#
+# class Foobar
+#   include Foo
+#   include Bar
+# end
+#
+# object = Foobar.new # Object with state defined by a net consisting
+#                     # of Foo and Bar modules
+#                     
+# object.net          # YPetri net
+# object.state        # state of the object's net
+# 
+# A different possibility would be to use the block syntax:
+#
+# # syntax 2
+# 
+# quux = net do
+#   include "Foo"
+#   Place "A", marking: 42
+# end
+#
+# (Since net do A = Place( m: 42 ) end does not work -- constant gets
+# defined in the callers scope.)
+# 
+# The question is, which world will the nodes defined by syntax 1 go to?
+# I think that the world should be defined either:
+#
+# 1. explicitly
+# 
+# module Foo
+#   self.y_petri_world = Bar
+# end
+#
+# 2. implicitly
+#
+# module Foo
+#   A = Place() # will automatically connect Foo with the default world
+# end
+# 
+# module Foo::Bar
+#   A = Place() # will search nesting and connect Foo::Bar with the world of Foo
+# end
+# 
+# As for +YPetri::Net+ block constructor, the block should be module-evalled in
+# the nascent instance (whose class descends from Module), but +include+ in it
+# should be peppered so as to admit also Place and Transition arguments and to
+# make the first include decide implicitly the world of this net.
+#
+# X = net do
+#   include Foo::A
+#   include Foo::Bar
+# end
+#
+# Other than that, the world would have to be either defined explicitly
+#
+# X = foo_world.net do
+#   # ...
+# end
+#
+# or implicitly by Module#net, taking the module's world as the net's
+# world, as in module definition.
+#
+# So Module#net would go somehow like:
+#
+# class Module
+#   def net &block
+#     x = Net.new
+#     x.y_petri_world = y_petri_world # of the receiver
+#     x.module_exec &block
+#     return x
+#   end
+# end
+#
+# Object.y_petri_world is automatically created. World is not a module class.
+#
+# #net called outside a module should create a Net belonging to the
+# Object.y_petri_world.
+#
+# ===========================================================================
+
+
+# ===========================================================================
+# !!! TODO !!!
+# 
+# Refactoring plans: Modules themselves should be ZZ objects, but not
+# before yzz is refactored so as to allow to give the zz properties to
+# already existing objects.
+#
+# It is a question whether all the objects should be zz objects, and the
+# probable answer is actually yes.

data/test/issues.rb

@@ -0,0 +1,68 @@
+# encoding: utf-8
+
+require 'sy'; require 'y_nelson' and include YNelson
+
+# =============================================================================
+# FOUND ISSUES
+
+# With
+M = Place m!: 1
+
+# This works as expected:
+G = Transition domain: M, s: { M: 1 }, rate: proc { |m| m * 0.1 }
+# This works too:
+G = Transition domain: M, s: { M: 1 }, rate: -> m { m * 0.1 }
+
+# This doesn't work:
+G = TS M: 0, M: 1 # domain of the transition shown as empty, should be [ M ]
+
+# This
+G = TS domain: M, s: { M: 1 }, rate: -> m { m * 0.1 }
+# gives confusing error message: Supplied codomain member s does not specify a valid place!
+# The user is seemingly ignorant of correct #TS syntax and tries #Transition syntax on it
+# with arguments :domain, :s. TS syntax takes ordered arguments to denote domain, while
+# named arguments denote codomain and its stoichiometry. TS takes care of the :domain argument,
+# but does not expect a codomain given in :s alias :stoichiometry named argument, and attempts
+# to convert symbol :s into a place. This error is confusing
+
+# This
+G = TS domain: M, M: 1, rate: proc do |m| m * 0.1 end
+# does not work, but the cause seems to be related to Ruby syntax itself.
+# This already works (replacing do / end by { / })
+G = TS domain: M, M: 1, rate: proc { |m| m * 0.1 }
+
+# This still works as expected
+G = TS M, M: 1, rate: proc { |m| m * 0.1 }
+
+# And this works, too
+G = TS M, M: 1 do |m| m * 0.1 end
+
+# This simple Boolean place definition causes problems, because the construction of a new
+# simulation, when constructing a marking vecto, in #zero class method uses multplication by
+# zero to get zero marking. In the future, the simulation has to admit that not all the places
+# markings must support mathematical oprations.
+Ck_license = Place m!: false
+
+# Issue: NaN and surely also positive and negative float infinity will be a problem.
+
+# Issue: constructor such as this one
+T = TS A: 0, B: -1
+# considers A to be a part of the codomain, when the user actually means domain.
+# For now, the users will have to avoid constructs with zero stoichiometry coefficient.
+# In the future, this should be corrected.
+
+# Issue: A bit unrelated, but annoying
+@w = YPetri::World.new
+@net = @w.Net.send :new
+@net << @w.Place.send( :new, ɴ: :A )
+@net << @w.Place.send( :new, ɴ: :B )
+# TS transitions A2B, A_plus
+@net << @w.Transition.send( :new, ɴ: :A2B, s: { A: -1, B: 1 }, rate: 0.01 )
+@net << @w.Transition.send( :new, ɴ: :A_plus, s: { A: 1 }, rate: 0.001 )
+
+# Now this is a common mistake that the people will make. They will write:
+@net.State.Feature.Marking( [ :A, :B ] )
+# instead of:
+@net.State.Features.Marking( [ :A, :B ] )
+# The problem is that the error message of the first form is not sufficiently informative:
+# No instance [:A, :B] in #<Class:0xb87c366c>

data/test/y_nelson_test.rb

@@ -25,7 +25,7 @@ describe YNelson do
   describe "new transition form correct zz connections with places" do
     it "should work as expected" do
       assert_equal [], @p.neighbors
-      assert_equal [], @p.connectivity # 'connectivity' now exclusively a zz keyword
+      assert_equal [], @p.connections # 'connectivity' now exclusively a zz keyword
       t = @m.Transition codomain: @p, assignment: -> { 0.1 }
       assert_equal [ @p ], t.neighbors
       dim = @m.Dimension( t, :codomain, 0 )

data/y_nelson.gemspec

@@ -8,8 +8,8 @@ Gem::Specification.new do |spec|
   spec.version       = YNelson::VERSION
   spec.authors       = ["boris"]
   spec.email         = ["\"boris@iis.sinica.edu.tw\""]
-  spec.summary       = %q{A fusion of functional Petri net with a zz structure.}
-  spec.description   = %q{Formalization and generalization of a spreadsheet.}
+  spec.summary       = %q{A fusion of functional Petri net with a zz structure that formalizes and generalizes spreadsheet.}
+  spec.description   = %q{Zz structures are an interesting way of representing relations invented by Ted Nelson. I captured the basic zz structure formalism in a gem Yzz. In this gem, YNelson, I combine zz structures with universal Petri nets (provided by another gem of mine, YPetri) to obtain a hybrid data structure that formalizes and generelizes spreadsheet. Because let us note that most practical spreadsheet implementation allow to model a Petri net with the cell functions – if the cell functions are regarded as transitions and cells and places, then a spreadsheet is a kind of a Petri net. At the same time, spreadsheet files are orthogonal structures with at least 3 dimensions: x (horizontal), y (vertical) and z (the dimension of sheets stacked upon each other). In addition, there is the "dimension" of files, the "dimension" of precedents and dependents (seen in formula auditing). If zz structures are used to represent relations as dimensions, this can be generalized, and the globally orthogonal nature of spreadsheets is generalized to the locally orthogonal nature of zz structures. The sum of this makes for a nice generalization of a spreadsheet, which YNelson attempts to be. In addition, YNelson attempts to provide convenience at least at the level similar to the actual existing spreadsheet software by providing certain commands that allow creation of more than one Petri net place or transition at the same time. This aspect of YNelson is still under development. See the user guide and the documentation for the details. YNelson documentation is available online, but due to formatting issues, you may prefer to generate the documentation on your own by running rdoc in the gem directory.}
   spec.homepage      = ""
   spec.license       = "GPLv3"
 
@@ -23,4 +23,6 @@ Gem::Specification.new do |spec|
 
   spec.add_development_dependency "bundler", "~> 1.6"
   spec.add_development_dependency "rake"
+  
+  spec.required_ruby_version = '>= 2.0'
 end

metadata

@@ -1,79 +1,100 @@
 --- !ruby/object:Gem::Specification
 name: y_nelson
 version: !ruby/object:Gem::Version
-  version: 2.3.0
+  version: 2.3.2
 platform: ruby
 authors:
 - boris
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2014-04-23 00:00:00.000000000 Z
+date: 2014-12-02 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: yzz
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - '>='
+    - - ">="
       - !ruby/object:Gem::Version
         version: '0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - '>='
+    - - ">="
       - !ruby/object:Gem::Version
         version: '0'
 - !ruby/object:Gem::Dependency
   name: y_petri
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - '>='
+    - - ">="
       - !ruby/object:Gem::Version
         version: '0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - '>='
+    - - ">="
       - !ruby/object:Gem::Version
         version: '0'
 - !ruby/object:Gem::Dependency
   name: bundler
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - ~>
+    - - "~>"
       - !ruby/object:Gem::Version
         version: '1.6'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - ~>
+    - - "~>"
       - !ruby/object:Gem::Version
         version: '1.6'
 - !ruby/object:Gem::Dependency
   name: rake
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - '>='
+    - - ">="
       - !ruby/object:Gem::Version
         version: '0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - '>='
+    - - ">="
       - !ruby/object:Gem::Version
         version: '0'
-description: Formalization and generalization of a spreadsheet.
+description: 'Zz structures are an interesting way of representing relations invented
+  by Ted Nelson. I captured the basic zz structure formalism in a gem Yzz. In this
+  gem, YNelson, I combine zz structures with universal Petri nets (provided by another
+  gem of mine, YPetri) to obtain a hybrid data structure that formalizes and generelizes
+  spreadsheet. Because let us note that most practical spreadsheet implementation
+  allow to model a Petri net with the cell functions – if the cell functions are regarded
+  as transitions and cells and places, then a spreadsheet is a kind of a Petri net.
+  At the same time, spreadsheet files are orthogonal structures with at least 3 dimensions:
+  x (horizontal), y (vertical) and z (the dimension of sheets stacked upon each other).
+  In addition, there is the "dimension" of files, the "dimension" of precedents and
+  dependents (seen in formula auditing). If zz structures are used to represent relations
+  as dimensions, this can be generalized, and the globally orthogonal nature of spreadsheets
+  is generalized to the locally orthogonal nature of zz structures. The sum of this
+  makes for a nice generalization of a spreadsheet, which YNelson attempts to be.
+  In addition, YNelson attempts to provide convenience at least at the level similar
+  to the actual existing spreadsheet software by providing certain commands that allow
+  creation of more than one Petri net place or transition at the same time. This aspect
+  of YNelson is still under development. See the user guide and the documentation
+  for the details. YNelson documentation is available online, but due to formatting
+  issues, you may prefer to generate the documentation on your own by running rdoc
+  in the gem directory.'
 email:
 - '"boris@iis.sinica.edu.tw"'
 executables: []
 extensions: []
 extra_rdoc_files: []
 files:
-- .gitignore
+- ".gitignore"
+- ACKNOWLEDGMENT.txt
 - Gemfile
 - Introduction_to_Ruby_for_YNelson_Users.lyx
 - Introduction_to_Ruby_for_YNelson_Users.pdf
@@ -95,6 +116,7 @@ files:
 - lib/y_nelson/version.rb
 - lib/y_nelson/yzz.rb
 - lib/y_nelson/zz_point.rb
+- test/issues.rb
 - test/mongoid_example.rb
 - test/y_nelson_test.rb
 - y_nelson.gemspec
@@ -108,20 +130,22 @@ require_paths:
 - lib
 required_ruby_version: !ruby/object:Gem::Requirement
   requirements:
-  - - '>='
+  - - ">="
     - !ruby/object:Gem::Version
-      version: '0'
+      version: '2.0'
 required_rubygems_version: !ruby/object:Gem::Requirement
   requirements:
-  - - '>='
+  - - ">="
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.0.14
+rubygems_version: 2.2.2
 signing_key: 
 specification_version: 4
-summary: A fusion of functional Petri net with a zz structure.
+summary: A fusion of functional Petri net with a zz structure that formalizes and
+  generalizes spreadsheet.
 test_files:
+- test/issues.rb
 - test/mongoid_example.rb
 - test/y_nelson_test.rb