[GRASS-SVN] r67493 - grass-addons/grass7/vector/v.feature.algebra

svn_grass at osgeo.org svn_grass at osgeo.org
Tue Jan 5 19:00:33 PST 2016


Author: wenzeslaus
Date: 2016-01-05 19:00:33 -0800 (Tue, 05 Jan 2016)
New Revision: 67493

Added:
   grass-addons/grass7/vector/v.feature.algebra/v.feature.algebra.html
Removed:
   grass-addons/grass7/vector/v.feature.algebra/v.mapcalc.html
Log:
v.feature.algebra: fix rename of the manual file

Copied: grass-addons/grass7/vector/v.feature.algebra/v.feature.algebra.html (from rev 67492, grass-addons/grass7/vector/v.feature.algebra/v.mapcalc.html)
===================================================================
--- grass-addons/grass7/vector/v.feature.algebra/v.feature.algebra.html	                        (rev 0)
+++ grass-addons/grass7/vector/v.feature.algebra/v.feature.algebra.html	2016-01-06 03:00:33 UTC (rev 67493)
@@ -0,0 +1,268 @@
+<h2>DESCRIPTION</h2>
+
+<em>v.in.mapcalc</em> is a vector calculator program inspired by r.mapcalc.
+
+<h2>NOTES</h2>
+
+It's much more complicated to deal with vector maps than with raster
+maps. Particularly, there are several levels on which we might want to
+deal with a vector map. For this reason the design of v.mapcalc is
+that of a skeleton with plugins: A parser will interpret statements
+and call the appropriate functions it finds in dynamically loaded
+plugins.
+<p>
+The syntax should be able to deal with four different types:
+
+        - numbers
+        - points
+        - point lists
+        - maps
+<p>
+Numeric expressions should do what everybody would expect. There are
+some dozens of built in functions from the math library. Points and
+point lists are meant in the mathematical sense: A point is a set of
+two or three numbers, representing the coordinate. All points have
+three components, but the third, if missing has the value of
+0.0/0.0 (NaN). An expression will yield a 3D result if all arguments a
+3D. There is a set of basic built in operations like dot and cross
+product. Point lists are meant for polygons, lines, areas, etc. Points
+and point lists have no categories or attributes. And finally, of
+course, v.mapcalc deals with map expressions.
+<p>
+For numbers, the infix operators do the obvious. For other types, the
+parser will translate them to function calls with predefined
+names. Some samples are set and can be replaced by something useful.
+<p>
+The plugins are designed to be as simple as possible. There is one
+example which actually doesn't do anything but shows how it can be
+called. Such a plugin needs three global functions: One which can be
+called to find out the name the user must type to use the function,
+one which returns a string denoting the return type and the type and
+number of arguments, and finally the function itself.
+<p>
+There are two more types which are somewhat special: One is type
+`argument' which can be any of the basic types. The parser will accept
+anything to be the argument to a function call, but the mechanism to
+actually call that function will check if the types match the
+prototype. The second special type `any' is sort of a backdoor: If
+something new comes up, it can be treated as type any, and it will be
+responsibility of the plugin to verify that it's the correct type. One
+case where the any-type can be useful is for SQL statement-pieces or
+other constructs when dealing with attributes, which can be literally
+of "any" type.
+<p>
+There is one problem with this approach within v.mapcalc, which is
+calling a function with a variable list of arguments. This is a bit
+complicated, and before thinking of easy solutions, I need to
+recommend reading the code. Just before calling it, v.mapcalc has a
+pointer to that functions and a linked list of structures which hold
+the argument types and values. It would be nice to be able to
+construct such a call argument by argument, but there is no portable
+way to do so: First assembly would be needed, and second, the way a
+stack frame is built for a particular compiler/architecture can vary.
+The solution is to maintain a list of typedef'd prototypes and call
+them in a switch. This means, if someone needs a new function and
+writes a plugin, either he finds a typedef which matches this
+prototype, or he needs to add the typedef and a case in the switch.
+<p>
+It makes only limited sense to mix arguments of different types: three
+at the power of map-A doesn't seem to be useful. So, the basic
+strategy is accept expressions only of the same type, while mixing
+types is always possible within the arguments to a function call.
+<p>
+There is a file listing some example expressions. I hope that it is
+what one could expect. Adding a few plugins should allow for very
+complex expressions and operations.
+
+
+<h2>EXAMPLES</h2>
+
+This is an empty statement, which is legal
+<div class="code"><pre>
+         ;
+</pre></div>
+
+<p>
+Some built in constants:
+<div class="code"><pre>
+         12;
+         e;
+         pi;
+         pnt_o;
+         pnt_i;
+         pnt_j;
+         pnt_k;
+         rivers;
+</pre></div>
+
+<p>
+The last one isn't really a constant, as it depends on what if found
+at startup, but it behaves just the like.
+<div class="code"><pre>
+         a;
+</pre></div>
+
+<p>
+This gives an error. "a", which is (not yet) defined, is handled as a
+string. There is no operation associated, so this gives a parse error.
+<p>
+Next some simple assignments. Also here, the name of the variable is
+initially not more than a string, but after performing the assignment,
+they take the type of the expressionL:
+<div class="code"><pre>
+         num = 10.3;
+         pnt = (0,0);
+         map = rivers;
+         any = mkstring (hallo);
+</pre></div>
+
+<p>
+The last is only a backdoor for cases when exceptional things are
+needed. The function mkstring is a sample implementation of type
+ANY. For now, only one word could be passed, but when flex is being
+used a quoted string might contain just anything.
+<p>
+Next, I overwrite these variables. This is somewhat tricky. If you say
+"map = rivers", what should happen? In theory, we should actually
+duplicate this map, which could imply gigabytes on disk. This is not
+done, but if the map is changed, it must not change the former
+`value'. I hope it's doing now, what everybody would expect (including
+to free eventually the allocated memory).
+<div class="code"><pre>
+         num = 3.1;
+         pnt = (1,1);
+         map = cities;
+         any = mkstring (hello);
+</pre></div>
+
+<p>
+The pure numeric operations aren't new, beside that I'm trying to
+catch illegal operations:
+<div class="code"><pre>
+         sqrt(e);
+         num = cos (pi/4);
+         num = -num + 3 * num - sqrt (num^2);
+         3.3 + 4.4;
+         2.2 - 1.1;
+         5 * 7;
+         21 / 0;
+         21 / 2;
+         -21 / 7;
+         -6.6 ^ 1.2;
+         6.6 ^ 1.2;
+         12.5 % 3.6;
+         2 * (3.1 + 0.9);
+</pre></div>
+
+<p>
+Next are points. Note that 2D and 3D are dealt with identically; in
+case of 2D, the z-value is 0.0/0.0 (NaN, "Not a Number"). This should
+be pretty portable. Generally, if at least one point is 2D, the result
+of a point operation will be 2D even if 3D points are involved too,
+ignoring the third dimension. I've defined some infix operations a bit
+arbitrarily. Of course, this could be changed. The double () in case
+of a single function argument are surely ugly, but not avoidable.
+<div class="code"><pre>
+         origin2d = (0,0);
+         p1 = (1,1);
+         p2 = p1;
+         p2 = v_copy (p1);
+         v_add ((1,0), (0,1));
+         (1,0) + (0,1);
+         v_sub ((1,1), (0,1));
+         (1,1) - (0,1);
+         v_abs ((-2, -1));
+         v_neg ((2, 1));
+         -(2,1);
+         v_mul ((2,4), 3.3);
+         (2,4) * 3.3;
+         3.3 * (2,4);
+         v_div ((6.6, 13.2), 3.3);
+         (6.6, 13.2) / 3.3;
+         v_unit ((12, 8));
+         v_cross ((1,2), (4,5));
+         v_cross ((1,2,3), (4,5,6));
+         (1,2,3) ^ (4,5,6);
+         v_val ((3,3));
+         v_dot ((1,2), (3,4));
+         (1,2) % (3,4);
+         v_dot ((1,2,3), (4,5,6));
+         (1,2,3) % (4,5,6);
+         v_area ((1,2,3), (4,5,6));
+         v_eq ((1,2), (1, 2));
+         v_eq ((1,2), (1.0001, 2.0001));
+         epsilon = (1e-3, 1e-3);
+         v_eq_epsilon ((1,2), (1.0001, 2.0001), epsilon);
+         v_isortho ((0,1), (1,0));
+         v_ispara ((0, 1), (0, -1));
+         v_isacute ((0, 1), (0, 0.5));
+         3 * (pnt + (2,2));
+</pre></div>
+
+<p>
+This is planned, but doesn't work yet:
+<div class="code"><pre>
+         line = ((1,1), (2,1));
+         triangle = (line, (1.5, 2));
+</pre></div>
+
+<p>
+And finally the map operations, which also aren't new, beside some
+internal details (freeing memory, not duplicating, etc.). I think that
+there is no map-operation which makes sense if it is not assigned to a
+variable. So all map expressions need to follow a variable and an
+equal sign. The very first expression, hence, will give an error:
+<div class="code"><pre>
+         rivers + cities;
+         map = rivers;
+         map;
+         map = rivers + cities;
+         map = testmap (rivers);
+         map = test2map (rivers, cities);
+         map = dltest (rivers, cities);
+</pre></div>
+
+
+<h2>TODO</h2>
+
+- The lexical scanner. At this point, there is a very simple and
+  limited scanner. My plan was to provide 4 methods of input:
+  + from the command line
+  + from stdin, interactively, using GNU readline and history
+  + from stdin by IO redirection like in "script | v.mapcalc"
+  + from a file, like in "v.mapcalc -i statementfile"
+  Of course, this should be done with Flex, with the input selection
+  as needed for all methods, as well as support for Bison to indicate
+  the position of a parse error.
+- There should be several built in commands allowing to:
+  + include a file with statements
+  + document the meaning of a variable or function
+  + attaching documentation to a variable or function
+  + saving certain things in a readable script like documentation or
+    constant values.
+  + a command to terminate the program (right now, only with Ctrl-D)
+- There is not yet any support for loops and conditionals. These do
+  not seem to be of much use with maps, but can prove powerful on
+  points and point lists.
+- There are certain operations which need to be performed always, like
+  opening a map. For now, they need to be done in the plugin, but
+  should definitively move to v.mapcalc.
+- Point lists are not working yet, though much of the basic
+  infrastructure is already done.
+- There seems to be a bug in memory management which can cause the
+  program to crash. Probably there are many more than that.
+
+
+<h2>SEE ALSO</h2>
+
+<em>
+  <a href="r.mapcalc.html">r.mapcalc</a>
+</em>
+
+
+<h2>AUTHOR</h2>
+
+Christoph Simon <ciccio at kiosknet com.br>
+
+<p>
+<i>Last changed: $Date$</i>

Deleted: grass-addons/grass7/vector/v.feature.algebra/v.mapcalc.html
===================================================================
--- grass-addons/grass7/vector/v.feature.algebra/v.mapcalc.html	2016-01-06 02:53:36 UTC (rev 67492)
+++ grass-addons/grass7/vector/v.feature.algebra/v.mapcalc.html	2016-01-06 03:00:33 UTC (rev 67493)
@@ -1,268 +0,0 @@
-<h2>DESCRIPTION</h2>
-
-<em>v.in.mapcalc</em> is a vector calculator program inspired by r.mapcalc.
-
-<h2>NOTES</h2>
-
-It's much more complicated to deal with vector maps than with raster
-maps. Particularly, there are several levels on which we might want to
-deal with a vector map. For this reason the design of v.mapcalc is
-that of a skeleton with plugins: A parser will interpret statements
-and call the appropriate functions it finds in dynamically loaded
-plugins.
-<p>
-The syntax should be able to deal with four different types:
-
-        - numbers
-        - points
-        - point lists
-        - maps
-<p>
-Numeric expressions should do what everybody would expect. There are
-some dozens of built in functions from the math library. Points and
-point lists are meant in the mathematical sense: A point is a set of
-two or three numbers, representing the coordinate. All points have
-three components, but the third, if missing has the value of
-0.0/0.0 (NaN). An expression will yield a 3D result if all arguments a
-3D. There is a set of basic built in operations like dot and cross
-product. Point lists are meant for polygons, lines, areas, etc. Points
-and point lists have no categories or attributes. And finally, of
-course, v.mapcalc deals with map expressions.
-<p>
-For numbers, the infix operators do the obvious. For other types, the
-parser will translate them to function calls with predefined
-names. Some samples are set and can be replaced by something useful.
-<p>
-The plugins are designed to be as simple as possible. There is one
-example which actually doesn't do anything but shows how it can be
-called. Such a plugin needs three global functions: One which can be
-called to find out the name the user must type to use the function,
-one which returns a string denoting the return type and the type and
-number of arguments, and finally the function itself.
-<p>
-There are two more types which are somewhat special: One is type
-`argument' which can be any of the basic types. The parser will accept
-anything to be the argument to a function call, but the mechanism to
-actually call that function will check if the types match the
-prototype. The second special type `any' is sort of a backdoor: If
-something new comes up, it can be treated as type any, and it will be
-responsibility of the plugin to verify that it's the correct type. One
-case where the any-type can be useful is for SQL statement-pieces or
-other constructs when dealing with attributes, which can be literally
-of "any" type.
-<p>
-There is one problem with this approach within v.mapcalc, which is
-calling a function with a variable list of arguments. This is a bit
-complicated, and before thinking of easy solutions, I need to
-recommend reading the code. Just before calling it, v.mapcalc has a
-pointer to that functions and a linked list of structures which hold
-the argument types and values. It would be nice to be able to
-construct such a call argument by argument, but there is no portable
-way to do so: First assembly would be needed, and second, the way a
-stack frame is built for a particular compiler/architecture can vary.
-The solution is to maintain a list of typedef'd prototypes and call
-them in a switch. This means, if someone needs a new function and
-writes a plugin, either he finds a typedef which matches this
-prototype, or he needs to add the typedef and a case in the switch.
-<p>
-It makes only limited sense to mix arguments of different types: three
-at the power of map-A doesn't seem to be useful. So, the basic
-strategy is accept expressions only of the same type, while mixing
-types is always possible within the arguments to a function call.
-<p>
-There is a file listing some example expressions. I hope that it is
-what one could expect. Adding a few plugins should allow for very
-complex expressions and operations.
-
-
-<h2>EXAMPLES</h2>
-
-This is an empty statement, which is legal
-<div class="code"><pre>
-         ;
-</pre></div>
-
-<p>
-Some built in constants:
-<div class="code"><pre>
-         12;
-         e;
-         pi;
-         pnt_o;
-         pnt_i;
-         pnt_j;
-         pnt_k;
-         rivers;
-</pre></div>
-
-<p>
-The last one isn't really a constant, as it depends on what if found
-at startup, but it behaves just the like.
-<div class="code"><pre>
-         a;
-</pre></div>
-
-<p>
-This gives an error. "a", which is (not yet) defined, is handled as a
-string. There is no operation associated, so this gives a parse error.
-<p>
-Next some simple assignments. Also here, the name of the variable is
-initially not more than a string, but after performing the assignment,
-they take the type of the expressionL:
-<div class="code"><pre>
-         num = 10.3;
-         pnt = (0,0);
-         map = rivers;
-         any = mkstring (hallo);
-</pre></div>
-
-<p>
-The last is only a backdoor for cases when exceptional things are
-needed. The function mkstring is a sample implementation of type
-ANY. For now, only one word could be passed, but when flex is being
-used a quoted string might contain just anything.
-<p>
-Next, I overwrite these variables. This is somewhat tricky. If you say
-"map = rivers", what should happen? In theory, we should actually
-duplicate this map, which could imply gigabytes on disk. This is not
-done, but if the map is changed, it must not change the former
-`value'. I hope it's doing now, what everybody would expect (including
-to free eventually the allocated memory).
-<div class="code"><pre>
-         num = 3.1;
-         pnt = (1,1);
-         map = cities;
-         any = mkstring (hello);
-</pre></div>
-
-<p>
-The pure numeric operations aren't new, beside that I'm trying to
-catch illegal operations:
-<div class="code"><pre>
-         sqrt(e);
-         num = cos (pi/4);
-         num = -num + 3 * num - sqrt (num^2);
-         3.3 + 4.4;
-         2.2 - 1.1;
-         5 * 7;
-         21 / 0;
-         21 / 2;
-         -21 / 7;
-         -6.6 ^ 1.2;
-         6.6 ^ 1.2;
-         12.5 % 3.6;
-         2 * (3.1 + 0.9);
-</pre></div>
-
-<p>
-Next are points. Note that 2D and 3D are dealt with identically; in
-case of 2D, the z-value is 0.0/0.0 (NaN, "Not a Number"). This should
-be pretty portable. Generally, if at least one point is 2D, the result
-of a point operation will be 2D even if 3D points are involved too,
-ignoring the third dimension. I've defined some infix operations a bit
-arbitrarily. Of course, this could be changed. The double () in case
-of a single function argument are surely ugly, but not avoidable.
-<div class="code"><pre>
-         origin2d = (0,0);
-         p1 = (1,1);
-         p2 = p1;
-         p2 = v_copy (p1);
-         v_add ((1,0), (0,1));
-         (1,0) + (0,1);
-         v_sub ((1,1), (0,1));
-         (1,1) - (0,1);
-         v_abs ((-2, -1));
-         v_neg ((2, 1));
-         -(2,1);
-         v_mul ((2,4), 3.3);
-         (2,4) * 3.3;
-         3.3 * (2,4);
-         v_div ((6.6, 13.2), 3.3);
-         (6.6, 13.2) / 3.3;
-         v_unit ((12, 8));
-         v_cross ((1,2), (4,5));
-         v_cross ((1,2,3), (4,5,6));
-         (1,2,3) ^ (4,5,6);
-         v_val ((3,3));
-         v_dot ((1,2), (3,4));
-         (1,2) % (3,4);
-         v_dot ((1,2,3), (4,5,6));
-         (1,2,3) % (4,5,6);
-         v_area ((1,2,3), (4,5,6));
-         v_eq ((1,2), (1, 2));
-         v_eq ((1,2), (1.0001, 2.0001));
-         epsilon = (1e-3, 1e-3);
-         v_eq_epsilon ((1,2), (1.0001, 2.0001), epsilon);
-         v_isortho ((0,1), (1,0));
-         v_ispara ((0, 1), (0, -1));
-         v_isacute ((0, 1), (0, 0.5));
-         3 * (pnt + (2,2));
-</pre></div>
-
-<p>
-This is planned, but doesn't work yet:
-<div class="code"><pre>
-         line = ((1,1), (2,1));
-         triangle = (line, (1.5, 2));
-</pre></div>
-
-<p>
-And finally the map operations, which also aren't new, beside some
-internal details (freeing memory, not duplicating, etc.). I think that
-there is no map-operation which makes sense if it is not assigned to a
-variable. So all map expressions need to follow a variable and an
-equal sign. The very first expression, hence, will give an error:
-<div class="code"><pre>
-         rivers + cities;
-         map = rivers;
-         map;
-         map = rivers + cities;
-         map = testmap (rivers);
-         map = test2map (rivers, cities);
-         map = dltest (rivers, cities);
-</pre></div>
-
-
-<h2>TODO</h2>
-
-- The lexical scanner. At this point, there is a very simple and
-  limited scanner. My plan was to provide 4 methods of input:
-  + from the command line
-  + from stdin, interactively, using GNU readline and history
-  + from stdin by IO redirection like in "script | v.mapcalc"
-  + from a file, like in "v.mapcalc -i statementfile"
-  Of course, this should be done with Flex, with the input selection
-  as needed for all methods, as well as support for Bison to indicate
-  the position of a parse error.
-- There should be several built in commands allowing to:
-  + include a file with statements
-  + document the meaning of a variable or function
-  + attaching documentation to a variable or function
-  + saving certain things in a readable script like documentation or
-    constant values.
-  + a command to terminate the program (right now, only with Ctrl-D)
-- There is not yet any support for loops and conditionals. These do
-  not seem to be of much use with maps, but can prove powerful on
-  points and point lists.
-- There are certain operations which need to be performed always, like
-  opening a map. For now, they need to be done in the plugin, but
-  should definitively move to v.mapcalc.
-- Point lists are not working yet, though much of the basic
-  infrastructure is already done.
-- There seems to be a bug in memory management which can cause the
-  program to crash. Probably there are many more than that.
-
-
-<h2>SEE ALSO</h2>
-
-<em>
-  <a href="r.mapcalc.html">r.mapcalc</a>
-</em>
-
-
-<h2>AUTHOR</h2>
-
-Christoph Simon <ciccio at kiosknet com.br>
-
-<p>
-<i>Last changed: $Date$</i>



More information about the grass-commit mailing list