Patent Application
20080082984
Further aspects of the present invention will be more readily appreciated upon review of the detailed description of the preferred embodiments included below when taken in conjunction with the accompanying drawings, of which:
The node denotes (or defines) a self-contained unit of computation. For example, the node 102 defines an addition operator (sometimes referred to herein as an addition node). In that regard, a first value (e.g., 3) may be supplied to the first input 110 of the node 102. A second value (e.g., 2) may be supplied to the second input 112 of the node 102. The node 102 may add the values (e.g., 3 and 2) supplied thereto, to determine a value (e.g., 5) which may be supplied (or presented) by the output 114 of the node 102.
An edge connected to an input of a node may define a source of values to be supplied to such input. For example, the first edge 104 defines a node, e.g., node 116, as a source of values for the first input 110 of the node 102. The second edge 106 defines a node, e.g., node 118, as a source of values for the second input 112 of the node 102.
An edge connected to an output of a node may define where values computed by a node are supplied and/or used. For example, the edge 108 connected to the output 114 of the node 102 defines a node, e.g., node 120, that receives (or takes) and/or uses the values supplied by the node 102. In some embodiments, an edge may include an arrow that indicates a direction of “data flow”.
A node may be an addition node, e.g., node 102, or any other type of node. Thus, a node (1) may have any number and/or type of inputs and/or outputs and (2) may define any number and/or type of functions. In some embodiments, a dataflow diagram may include any number of nodes and/or any number of edges.
In some embodiments, a user may utilize a graphical user interface to define one or more portions of a dataflow diagram and/or a dataflow network. As further described hereinafter, in some embodiments, a node may be defined to allow the node to accept a vector of values on one or more inputs of the node.
The node 142 has been defined in advance to allow the node 142 to receive a vector, e.g., vector 156, at the first input 150 (sometimes referred to herein as an overloaded input connection) of the node 142. The vector 156 may include a plurality of first values (e.g., 2, 4, 5). The second input 152 of the node 142 may receive a second value (e.g., 2). The node 142 may add the second value (e.g., 2) to each value in the vector 156 to determine a vector of results, e.g., vector 158, which may be supplied by the output 154 of the node 142. For example, the node 142 may add the second value (e.g., 2) to the first value (e.g., 2) in the vector 156 to determine a first value (e.g., 4) in the vector of results 158. The node 142 may add the second value (e.g., 2) to the second value (e.g., 4) in the vector 156 to determine a second value (e.g., 6) in the vector of results 158. The node 142 may add the second value (e.g., 2) to the third value (e.g., 5) in the vector 156 to determine a third value (e.g., 7) in the vector of results 158.
As further described hereinafter, in some embodiments, a node may be a property retrieval node to retrieve a property of an object.
In some embodiments, the node 202 may be a property retrieval node. For example, the node 202 may be a “name” property retrieval node that retrieves the “name” property of an object. In that regard, a reference to an object, e.g., object 1, may be supplied to the input 210 of the node 202. In accordance with some embodiments, the object may be an internal object and/or an external object. The node 202 may determine the “name” property (e.g., “apple”) of the object, e.g., object 1, and the “name” property may be supplied by the output 214 of the node 202.
As further described hereinafter, in some embodiments, a property retrieval node may be defined to allow the node to accept a vector of object references on one or more inputs of the node.
The node 222 has been defined in advance to allow the node 222 to receive a vector, e.g., vector 236, at the first input 230. The vector 236 may include a plurality of object references (e.g., object1, object2, object3). The node 222 may determine the “name” property of each object reference in the vector 236 to provide a vector of results (e.g., vector 238) which may be supplied by the output 234 of the node 222. For example, the node 222 may retrieve the “name” property (e.g., “apple”) of the first object reference (e.g., object1) in the vector 236 to determine the first “name” in the vector of results 238. The node 222 may retrieve the “name” property (e.g., “banana”) of the second reference (e.g., object2) in the vector 236 to determine the second “name” in the vector of results 238. The node 222 may retrieve the “name” property (e.g., “pear”) of the third reference (e.g., object3) in the vector 236 to determine the third “name” in the vector of results 238.
Notably, no current dataflow application provides nodes that accept lists of non-numeric values. It is not the case that such nodes could not be defined, but the semantics of current dataflow languages make such definitions less useful.
As further described hereinafter, in some embodiments, a node may be a property defining node.
The node 242 is a property defining node. For example, the node 242 may be a “color” property defining node, sometimes referred to herein as a set color node that defines the “color” property of an object. In that regard, a reference to an object (e.g., object 1) may be supplied to the first input 250 of the node 242. In accordance with some embodiments, the object may be an internal object and/or an external object. A reference to a color property (e.g., white) may be supplied to the second input 252 of the node 242. The node 242 may define the “color” property of the object (e.g., object 1) supplied to the first input 250 of the node 242, to the reference color (e.g., white) supplied to the second input 252 of the node 242.
As further defined hereinafter, in some embodiments, a property defining node may be defined to allow the node to accept a vector of object references on one or more inputs of the node.
The node 262 has been defined in advance to allow the node 262 to receive a vector, e.g., vector 276, at the first input 270. The vector 276 may include a plurality of object references (e.g., object1, object2, object3). The node 262 may define the color property of each object reference in the vector 276 to the reference color supplied to second input 272 of the node 262. For example, the node 262 may define the “color” property of the first object reference (e.g., object1) in the vector 276 supplied to first input 270 of the node 262, to the reference color (e.g., white) supplied to the second input 272 of the node 262. The node 262 may define the “color” property of the second object reference (e.g., object2) in the vector 276 supplied to first input 270 of the node 262, to the reference color (e.g., white) supplied to the second input 272 of the node 262. The node 262 may define the “color” property of the third object reference (e.g., object3) in the vector 276 supplied to first input 270 of the node 262, to the reference color (e.g., white) supplied to the second input 272 of the node 262.
Notably, if a programmer desires loop-like behavior, current dataflow applications require that the programmer define multiple dataflow networks, for example as shown in
An array or vector (e.g., vector 336) may be supplied to an input 320 of the first node 302. The vector 336 may include a plurality of object references (e.g., object1, object2, object3). The first node 302 may determine the size of the vector 336, and the size of the vector 336 may be supplied to a first input 330 of the second node 304. The vector (e.g., vector 336) may also be supplied to a second input 332 of the second node 304, and a third input 334 of second node 304 may receive a reference to a color property (e.g., white). The second node 304 may invoke a second or sub dataflow network (e.g., color func), further described hereinafter for
Referring to
The vector (e.g., vector 336) may be supplied to a first input 362 of the first node 342, a second input 360 of which may receive an index (e.g., n). The first node 342 may determine the indexed element (e.g., the nth element) of the array 336. The indexed element of the array 336 may be supplied to a first input 370 of the second node 344, a second input 372 of which may receive the color property (e.g., white). The second node 344 may define the color property of the indexed element of the array received on the first input 370 of the node 344 to the reference color supplied to the second input 372 of the node 344.
In accordance with some embodiments, a dataflow diagram may include a node that defines (or generates) an iteration context. In some embodiments, a node that defines an iteration context may control (directly and/or indirectly) the number of times that a node within the iteration context is invoked.
The node 402 may have one or more inputs (e.g., two inputs 404, 406) and/or one or more outputs (e.g., two outputs 408, 410). A first edge 414 may connect the first input 404 to an output of a node, e.g., node 424, which may be a source of data for the first input 404. A second edge 416 may connect the second input 406 to an output of a node, e.g., node 426, which may be a source of data for the second input 406. A third edge 418 may connect the first output 408 to an input of a node, e.g., node 428, which may receive data supplied by the first output 408. A fourth edge 420 may connect the second output 410 to an input of a node, e.g., node 430, which may receive data supplied by the second output 410. The node 428 and the node 430 are each within the iteration context defined by the node 402.
A node that defines an iteration context is sometimes denoted herein by a symbol 440.
In accordance with some embodiments, and as further described hereinafter, a node that defines an iteration context may be used in determining whether to execute (or invoke) node(s) that are disposed within the iteration context defined by such node, and/or how many times to execute (or invoke) node(s) that are disposed within the iteration context defined by such node.
Thus, in some embodiments, the node 402 may be used in determining whether to execute (or invoke) node(s), e.g., nodes 428, 430, that are disposed within the iteration context defined by the node 402, and/or how many times to execute (or invoke) nodes, e.g., nodes 428, 430, that are disposed within the iteration context defined by the node 402.
In accordance with some embodiments, a node that defines an iteration context, e.g., node 402, (1) may have any number and/or type of inputs and/or outputs and (2) may define any number and/or type of functions. Thus, a node that defines an iteration context may be defined to (1) receive any amount and/or type of data and/or (2) supply any amount and/or type of data.
In accordance with some embodiments, one type of node that defines an iteration context is referred to herein as a fan out node.
In this embodiment, the node 502 has one input 504 and three outputs 506, 508, 510. A first edge 514 may connect the input 504 to an output of a node (not shown), which may be a source of data for the input 504. A second edge 516 may connect the first output 506 to an input of a node (not shown), which may receive data supplied by the first output 506. A third edge 518 may connect the second output 508 to an input of a node (not shown), which may receive data supplied by the second output 508. A fourth edge 520 may connect the third output 510 to an input of a node (not shown), which may receive data supplied by the third output 510.
In accordance with some embodiments, the fan out node 502 receives an array (or list or vector), e.g., array 524, at the first input 504. The array 524 may include a plurality of elements. The plurality of elements may include any number and/or type of elements. In some embodiments, the elements may be object references (e.g., object1, object2, object3).
In accordance with some embodiments, the fan out node 502 supplies the elements, one at a time, from the first output 506 of the node 502. In accordance with some embodiments, node 502 may output the elements (i.e., present the elements to the output of node 502) one at a time. For example, the first output 506 may initially supply the first element (e.g., object1) of the array 524. Thereafter, the first output 506 may supply the second element (e.g., object2) of the array 524. Thereafter, the first output 506 may supply the third element (e.g., object3) of the array 524.
Thus, for example, if the array has three elements (e.g., object1, object 2, object 3), then nodes in the iteration context defined by node 502 will be executed three times. Specifically, the node 502 outputs the first element (e.g., object1) and the node(s) in the iteration context defined by node 502 are executed a first time. Thereafter, node 502 outputs a second element (e.g., object2) and the node(s) in the iteration context defined by node 502 are executed a second time. Thereafter, node 502 outputs a third element (e.g., object3) and the node(s) in the iteration context defined by node 502 are executed a third time.
Thus, node(s) within an iteration context defined by another node may be executed (or invoked) one time for each element output by such other node. For example, if the node that defines the iteration context has zero elements to output (i.e., no elements to output), then node(s) in the iteration context defined by such node may be executed zero times (i.e., not executed). If the node that defines the iteration context has one element to output, then the node(s) in the iteration context defined by such may be executed one time. If the node that defines the iteration context has a plurality of elements to output, then node(s) in the iteration context defined by such node may be executed a plurality of times, once per element to be output by the node that defines the iteration context.
In accordance with some embodiments, the second output 508 and the third output 510 may each supply a Boolean value. Specifically, if the first output 506 supplies the first element of the array 524, the second output 508 supplies a Boolean value having a “true” state. Otherwise, the second output 508 supplies a Boolean value having a “false” state. If the first output 506 supplies the last element of the array 524, the third output 510 supplies a Boolean value having a “true” state. Otherwise, the third output 510 supplies a Boolean value having a “false” state. In some embodiments, the fan out node 502 may not include the second output 508 and/or the third output 510.
In some embodiments, an iteration context is defined to propagate to all nodes connected to an output of the node that defines (or produces) the iteration context. In some embodiments, the iteration context also propagates to all nodes connected to the outputs of those nodes and so forth. In some embodiments, the propagation halts when there are no more nodes in the chain or the context is retracted by a node.
In accordance with some embodiments, an “iteration context” is a property of a node's definition. Other properties may include, but are not limited to, its name, the number and types of its input nodes, the number and types of its output nodes, the number and types of programmer editable fields, and the code that actually computes the node's output value.
The iteration context maintains an integer state that defines what step in the iteration is currently active. Unlike a for-loop that immediately repeats the execution of subordinate statements, a dataflow node in the present invention evaluates one iteration at a time then exits. Whether the iteration continues or not, the system will determine which nodes to evaluate next.
In accordance with some embodiments, nodes that do not define an iteration context act as conventional nodes in a dataflow network. As further described herein, when conventional nodes are invoked by the system, they may, for example, take the values presented to their input connections, perform their calculation, and present the results to their output connections.
However, in accordance with some embodiments, a node that defines an iteration context will use the state of the iteration to inform the system how to modify its behavior.
The method 700 is not limited to the order shown in the flow chart. Rather, embodiments of the method 700 may be performed in any order that is practicable. For that matter, unless stated otherwise, any method disclosed herein may be performed in any order that is practicable. Moreover, unless stated otherwise, the method 700 may be performed in any manner. In that regard, in some embodiments, one or more portions of one or more methods disclosed herein may be performed by a processing system. As further described hereinafter, in some embodiments, a processing system may comprise hardware, software (including microcode), firmware, or any combination thereof. In some embodiments, one or more portions of one or more methods disclosed herein may be performed by a processing system such as the processing system in
In some embodiments, the determination as to whether to invoke the node(s) within an iteration context may not be based solely, and/or even in part, on whether the node that defines the iteration context has data to present.
In some embodiments, the determination as to whether to invoke the node(s) within an iteration context may or may not be based on whether the node that defines the iteration context has data to present. In that regard, in some embodiments, an iteration context defining node, e.g., node 402 (
In accordance with some embodiments, a fan out node may be employed in situation (s) where an unknown number of objects may need to be manipulated. In accordance with some embodiments, one situation where an unknown number of objects may need to be manipulated may occur when a dataflow language is deployed in conjunction with a separate system of objects. In accordance with some embodiments, in some separate systems, objects can be created and destroyed arbitrarily and can change configuration dynamically, so a dataflow network that operates on such a system must be able to handle that dynamism.
In accordance with some embodiments, a dataflow network may be used in association with a simulation. In accordance with some embodiments, a simulation may be one type of situation where an unknown number of objects may need to be manipulated. In accordance with some embodiments, during execution of a simulation, objects can be created and destroyed arbitrarily and can change configuration dynamically, so a dataflow network that operates on such a system must be able to handle that dynamism.
In accordance with some embodiments, the simulation may represent an assembly line that moves boxes through a painting machine. The conveyor belt may be used to the move box objects through a region. The object detector in the simulation may represent a place where paint is applied to the boxes. The object maker may represent a source of boxes from some previous stage of the assembly process, such as a person putting the boxes on the line. The object remover may represent the destination of the boxes and may delete the boxes from the simulation. In the real world, the boxes might continue to a subsequent step in a process.
As stated above, in accordance with some embodiments, a dataflow network may be used in association with a simulation. In that regard, in some embodiments, a dataflow network may be useful for, but is not limited to, programming the behavior of one or more aspects of a simulation and/or to perform operations on one or more objects in a simulation.
Because the boxes are dynamically created, the system may be designed to refer to the boxes indirectly. Furthermore, in accordance with some embodiments, a behavior may need to affect multiple boxes at the same time and may not always be able to refer to any given box. Such operation would be difficult to implement using prior dataflow systems, because of the limits of their semantics.
Referring to
As stated above, in some embodiments, a user may utilize a graphical user interface to define one or more portions of a dataflow diagram and/or a dataflow network. In that regard, in some embodiments, one or more nodes may include one or more graphical editing tools to assist the user in that respect. For example, the first node 902 may include a button 903. The user may mouse-click and/or otherwise select the button 903 to initiate a drop down menu and/or dialogue box to help the user specify a reference to a region, e.g., “Box Region 1”.
The object reference value from node 902 is supplied to an input of the second node 904. The second node 904 is an intersect node that performs an operation to retrieve object references that identify objects in the simulation that intersect the volume of the object detector. In accordance with some embodiments, the second node 904 takes a single object (of detector type which is also called a “trigger”) as input and returns a list of object references as its result.
Since the conveyor belt 812 (
It should be noted that the number of object references returned by the second node 904 depends on the current situation within the simulation. For example, there may be one box that intersects the detector's volume, there may be many boxes that intersect the detector's volume, or there may be no boxes that intersect the detector's volume. Dataflow languages that require fixed sized data types are unable to handle this type of situation.
The array of object references is supplied to an input of the third node 906. The third node 906 may be a fan out node that defines an iteration context. In some embodiments, the fan out node 906 may be the same as and/or similar to the fan out node 502 (
The object references from the fan out node 906 are supplied, one at a time, to an input of a fourth node 908. The fourth node 908 is a set color node that defines the “color” property of an object. In accordance with some embodiments, the node 908 takes an object reference and a color value as its parameters and sets or changes the object's color property in accordance with the color value. In some embodiments, for example, the set color node receives a color value (e.g., a color value corresponding to white) from node 910, and sets the object's color property equal to the received color value, e.g., the color value corresponding to white.
Thus, in some embodiments, a fan out node may make it possible to use a node that takes an object parameter of single object type (not a list type) and use it as though it is a node that takes an object parameter of list type. For example, in accordance with some embodiments, a fan out node may make it possible to use a node such as, for example, node 242 (
Other dataflow networks may also be employed. In some embodiments, one or more of the dataflow networks disclosed herein may be employed with fewer than all features disclosed herein for such dataflow network and/or with one or more features in addition to those disclosed herein for such network. For that matter, in some embodiments, one or more of one or more types of nodes disclosed herein may be employed with fewer than all features disclosed herein for such node and/or with one or more features in addition to those disclosed herein for such node. Furthermore in some embodiments, dataflow network may be employed without a simulation.
It should be noted that, given a reference to an object, there are many possible operations that a user may want to perform on it and/or many possible functions that a user may want to apply to it. Although the dataflow diagram 900 defines a dataflow network that may be used to change the color of box objects in the region defined by the object detector 814 (
In accordance with some embodiments, a dataflow node can be defined to retract an iteration context. In accordance with some embodiments, and as further described hereinafter, the iteration context retracted by such node is the iteration context defined by, or applied to, nodes connected or coupled to the input of the node that retracts the iteration context. In accordance with some embodiments, any nodes that are connected to the output of a node that retracts an iteration context may use a prior iteration context.
The node 1102 may have one or more inputs, e.g., input 1104, and/or one or more outputs, e.g., output 1108. A first edge 1114 may connect the first input 1104 to an output of a node, e.g., node 1124, which may be a source of data for the first input 1104. A second edge 1118 may connect the first output 1108 to an input of a node, e.g., node 1128, which may receive data supplied by the first output 1108.
In accordance with some embodiments, a node, e.g., node 1124, connected to the first input 1104 of node 1102 may be in and/or may define an iteration context and the node 1102 may retract that iteration context. In accordance with some embodiments, a node, e.g., node 1128, connected to the first output 1108 of node 1102 may be in an iteration context defined previous to the iteration context revoked by the node 1102, if any, or in no iteration context.
A node that retracts an iteration context is sometimes denoted herein by a symbol 1140.
In accordance with some embodiments, a node that retracts an iteration context, e.g., node 1102, (1) may have any number and/or type of inputs and/or outputs and (2) may define any number and/or type of functions. Thus, a node that retracts an iteration context may be defined to (1) receive any amount and/or type of data and/or (2) supply any amount and/or type of data.
In accordance with some embodiments, one example of a node that retracts an iteration context is sometimes referred to hereinafter as a “fan-in” node. In accordance with some embodiments, and as further described hereinafter, a fan-in node may take single values presented by a prior iteration context (such as a fan-out) and collects them into a list. The collected list may then be produced as the output of the node. In accordance with some embodiments, employing a fan-in node in a position where there is no iteration context is allowed but may or may not be useful.
In this embodiment, the node 1202 has one input 1204 and one output 1206. A first edge 1214 may connect the input 1204 to an output of a node (not shown), which may be a source of data for the input 1204. A second edge 1216 may connect the first output 1206 to an input of a node (not shown), which may receive data supplied by the first output 1206.
In accordance with some embodiments, the fan in node 1202 receives a number of elements and combines the elements into an array, e.g., array 1224, which may be supplied from the first output 1206 of the node 1202. The number of elements may include any number and/or type of elements. In some embodiments, the elements may be object references (e.g., object1, object2, object3). In some embodiments, the elements may comprise elements from a fan out operation and/or evaluation.
In accordance with some embodiments, a node revoking an iteration context may be treated as being within the iteration context being revoked. In that regard, if the node that defines the iteration context outputs elements one at a time, the node revoking the iteration context may be executed (or invoked) one time for each element output by the node that defines the iteration context. For example, if the node that defines the iteration context has zero elements to output (i.e., no elements to output), then the node revoking the iteration context may be executed zero times (i.e., not executed). If the node that defines the iteration context has one element to output, then the node revoking the iteration context may be executed one time. If the node that defines the iteration context has a plurality of elements to output, then the node revoking the iteration context may be executed a plurality of times, once for element to be output by the node that defines the iteration context.
In accordance with some embodiments, if a node retracts an iteration context, the iteration context for successive (or following) nodes reverts to the prior iteration context, i.e., the iteration context defined previous to the iteration context of the node that defined the retracted iteration context. If there was no prior iteration context, then the successive nodes act as nodes having no iteration context. A new iteration context defined by a node replaces the current iteration context for following nodes. Thus, a given node has only one iteration context. When an iteration context is replaced by a new iteration context, the new iteration context is considered to be “nested” within the previous iteration context.
In accordance with some embodiments, a fan out node may be used in association with a simulation.
Referring to
As stated above, since the conveyor belt 812 (
The array of object references is supplied to an input of the third node 1306, which may be a fan out node that defines an iteration context. In accordance with some embodiments, the fan out node 1406 presents the object references, one at a time, to its output.
The object references from the fan out node 1306 are supplied, one at a time, to an input of a fourth node 1308. The fourth node 1308 is a get slot node that is used to provide a “name” property associated with an object reference. In that regard, fourth node 1308 may determine the “name” property (e.g., “red box 1”) of the object reference supplied to the input of the fourth node 1308, and the “name” property may be supplied by the output of the node 1308. Node 1308 may function like node 202 (
As stated above, in some embodiments, a user may utilize a graphical user interface to define one or more portions of a dataflow diagram and/or a dataflow network. In that regard, the fourth node 1308 may include a button 1309. The user may mouse-click and/or otherwise select the button 1309 to initiate a drop down menu and/or dialogue box to help the user specify a desired property (e.g., “NAME”) associated with the object reference.
The “name” property for the object references is supplied, one at a time, to an input of a fifth node 1310. The fifth node 1310 may be fan in node, which retracts an iteration context. In some embodiments, the fan in node 1310 may be the same as and/or similar to the fan in node 1202 (
The array from the fifth node 1310 is supplied to an input of the sixth node 1312. The sixth node 1312 is a set var node that is used to store the list of all names of all objects in “Box Region 1”. In accordance with some embodiments, the sixth node 1312 may reference external variable “names” whose type is an array of strings. In some embodiments, the set var node may store the list of all names in a global variable.
The iteration context technique can be used for tasks other than list processing. For example, a common task in programming is to select which code to run based on a conditional expression. In a standard programming language, this is performed by an if-then statement as shown in
In accordance with some embodiments, one can perform the equivalent operation in a dataflow program by using another type of node that defines an iteration context. Such a node is sometimes referred to hereinafter as a guard node.
As further described hereinafter, in some embodiments, a guard node takes a Boolean argument and a second element (e.g., an arbitrary value) as input. If the Boolean argument evaluates to true or satisfies other test criteria, the second element is passed onto the output for further computation by successive nodes. If the Boolean argument evaluates to false or satisfies other test criteria, then the second element is not passed on and the successive nodes are not evaluated at all.
In accordance with some embodiments, the semantics of a guard node may be implemented using a node that defines an iteration context. In that regard, in some embodiments, when the condition argument is true or satisfies other test criteria, the node activates successive nodes as though it were processing a list with one element. The successive nodes may be activated one time. When the argument is false or satisfies test criteria, the node behaves as though it was processing an empty list and successive nodes are not activated at all.
Notably, the ability to perform no evaluation is absent from other dataflow languages.
In this embodiment, the guard node 1502 has two inputs 1504, 1506 and one output 1508. A first edge 1514 may connect the first input 1504 to an output of a node (e.g., 1524) which may be a source of data for the first input 1504. A second edge 1516 may connect the second input 1506 to an output of a node, e.g., 1526, which may be a source of data for the second input 1506. A third edge 1518 may connect the first output 1508 to an input of a node (e.g., 1528) which may receive data supplied by the first output 1508.
In accordance with some embodiments, the guard node 1502 may receive a Boolean value at the first input 1504. The Boolean value may be of any type and/or form. In some embodiments, the Boolean value may comprise a logic “true” or a logic “false”. The guard node 1502 further receives an element at the second input 1506. In some embodiments, the element may be of any type and/or form.
In accordance with some embodiments, the guard node 1502 passes the element to the first output 1508 if the Boolean value has a “true” state or satisfies other test criteria. The element may thereafter be supplied by the first output 1508. If the Boolean value does not satisfy the test criteria, the guard node 1502 requests that its iteration context be halted and/or no element is passed to the first output 1508. Thus, if the Boolean value does not satisfy the test criteria, the first output 1508 does not supply any element or elements to node 1528.
As stated above, node(s) within an iteration context defined by another node may be executed (or invoked) one time for each element output by such other node. In that regard, in accordance with some embodiments, a node or nodes within the iteration context defined by the guard node 1502 is/are executed (or invoked) if the Boolean value satisfies the test criteria. Otherwise, a node or nodes within the iteration context defined by the guard node 1502 is/are not executed.
In accordance with some embodiments, the dataflow program 1600 may be used in testing for and/or identifying an error condition in the simulation 800 (
Referring to
As stated above, since the conveyor belt 812 (
The array of object references is supplied to an input of the third node 1606. The third node 1606 is a size node, an output of which provides a value corresponding to a size of the array supplied to the input of the node 1606.
The value supplied by the third node 1606 is supplied to a first input of the fourth node 1608, a second input of which receives a value from the fifth node 1610. The fourth node 1608 is a number test node, which takes the two input values and can supply three Boolean values (e.g., <, =, >). One of the Boolean values (e.g., >) has a “true” state if the value supplied by node 1606 to the first input of the fourth node 1608 is greater than the value supplied from node 1610 to the second input of the fourth node 1608.
Such Boolean value from the fourth node 1608 is supplied to a first input of the sixth node 1612, a second input of which receives a color value (e.g., red) from the seventh node 1614. In some embodiments, the sixth node 1612 may be the same as and/or similar to the guard node 1502 (
If the sixth node 1612 supplies a color value, such color value is supplied to the eighth node 1616. The eighth node 1616 is a set color node that is within the iteration context defined by the sixth node 1612.
As stated above, node(s) within an iteration context defined by another node may be executed (or invoked) one time for each element output by such other node. For example, if the node that defines the iteration context has zero elements to output (i.e., no elements to output), then node(s) in the iteration context defined by such node may be executed zero times (i.e., not executed). If the node that defines the iteration context has one element to output, then the node(s) in the iteration context defined by such may be executed one time.
In that regard, in accordance with some embodiments, the eighth node 1616 is executed (or invoked) if the Boolean value satisfies the test criteria such that the sixth node 1612 supplies the color value (e.g., red). Otherwise, the sixth node 1612 does not supply a value and the eighth node 1616 is not executed.
The set color node 1616 may be the same as and/or similar to the set color node 908 (
In accordance with some embodiments, using the guard node 1612 ensures that the set color node 1616 is not executed at all if a condition is not met, i.e., if the number of boxes in the region of the object detector 814 exceeds four boxes in this example.
In accordance with some embodiments, a node may retract an iteration context and define an iteration context. In accordance with some embodiments, if a node retracts an iteration context and defines an iteration context, the node may retract the incoming iteration context and define a new iteration context for nodes connected to its outputs. In accordance with some embodiments, the opposite case may not be useful.
In this embodiment, the node 1702 has one input 1704 and one output 1708. A first edge 1714 may connect the input 1704 to an output of a node, e.g., node 1724, which may be a source of data for the input 1704. A second edge 1718 may connect the first output 1708 to an input of a node, e.g., node 1728, which may receive data supplied by the output 1708.
In accordance with some embodiments, the node 1702 retracts the incoming iteration context and defines a new iteration context for nodes (e.g., node 1728) connected to the output of the node 1702.
As stated above, in some embodiments, a node's input connection may be attached to another's output connection.
In some embodiments an output of a node can be connected to several inputs but each input of a node can only be connected to a single output.
Some embodiments may prohibit inappropriate mixing of iteration contexts. Two iteration contexts are mixed if they both propagate to input connections of the same node. Since a node can only be subjected to the iterations of a single context, having two or more independent contexts propagate to a node results in an ambiguous situation. It is permissible, however, for a context to mix with a prior context in which it is nested. In this case, the node with mixed inputs uses the most deeply nested iteration context as its context and there is no ambiguity.
In accordance with some embodiments, and as further described hereinafter, a node may be allowed to be joined to contexts that are nested (
Thus, connections that proceed from nodes defining iteration contexts (e.g., output connection of node C and output connection of node B via node D in
As stated above, in some embodiments, a user may utilize a graphical user interface to define one or more portions of a dataflow diagram and/or a dataflow network. In that regard, in some embodiments, one or more “bubbles” or other symbols may be used to represent an input or output of a node. For example, in the dataflow diagram 1800, a bubble 1801 represents an output of node A; a bubble 1802 represents an input of node B; bubbles 1803, 1804 represent first and second outputs, respectively, of node B; a bubble 1805 represents the input of node C; a bubble 1806 represents the input of node D; etc. Thus, an edge 1807 connects the output 1801 of node A to the input 1802 of node B. An edge 1808 connects the first output 1803 of node B to the input 1805 of node C. An edge 1809 connects the second output 1804 of node B to the input 1806 of node D. Edges 1807-1809 may or may not include an arrow that indicates a direction of “data flow”.
In some embodiments, a user may mouse-click and/or otherwise select a bubble to define an endpoint of an edge. After one endpoint is defined, the user may mouse-drag, mouse-click and/or otherwise select the other endpoint for the edge. In some embodiments, the graphical user interface may include a “snap to bubble” feature to assist the user in defining the second endpoint. In some embodiments, the graphical user interface may not allow the user to define an edge that creates a prohibited type connection. In some embodiments, the interface may allow the user to create such an edge and may inform the user (in some way shape or form) that the connection is prohibited.
Thus, an iteration context that is retracted does not apply to nodes connected after the retraction (e.g., iteration context retracted by node D does not apply to node F).
Some embodiments may prevent (or prohibit) iteration contexts from forming loops. A loop is formed if the diagram includes a path from an output of a node to an input of the same node. For example, a loop exists in a situation where starting from a node, a path can be found following a chain of edges from outputs to inputs that leads back to an input of the original node. An example of a loop in a dataflow network 1900 without an iteration context is shown in
To run a standard dataflow program, the dataflow nodes may first be sorted to determine an order of node invocation. Once the order of node invocation is determined, the function of each node is called in turn. Once every node is called one time, the process starts over from the beginning of the list repeatedly running all the nodes' functions in an endless loop.
In accordance with some embodiments, running a dataflow program using semantics of the present invention may be similar except that allowances are made for the iteration contexts. In some embodiments, after sorting the nodes according to their partial order, nodes are then grouped according to the iteration context in which they are nested (i.e., according to the iteration context that influences it). Every node can be a member of at most one iteration context. As stated above, a node that produces a new iteration context propagates its influence to all successive nodes until either the context is retracted or another iteration context replaces it. Because un-nested iteration contexts are not allowed to be connected to the inputs of the same node, the most deeply nested iteration context that arrives for any node will always be unique. If a node is not influenced by an iteration context, that node is kept in the global context group. In some embodiments, attention is paid to keep the relative order of the nodes in each group the same as it was when they were in the global list. An example showing how nodes in a dataflow diagram may be grouped is described hereinafter with respect to
In accordance with some embodiments, to execute the nodes, a system calls each node in order. Conventional nodes may compute their values and store results as described in the flowchart 600 (
As stated above, the dataflow diagram 1810 (
Referring to
If node M does not have an iteration context (i.e., node I is nil) at 2207, then the method returns to 2204 to determine whether any nodes in the network have not yet been selected, and if so, then execution may return to 2206 for the next selected node M. If node M has an iteration context (i.e., node I is not nil) at 2207, then the method at 2208 selects and evaluates a node N that is an input node of node M.
For the selected input node N, at 2210, the method determines if input node N is equal to node I. If so, then input node N is the node that produces the iteration context of node M, and the method returns to 2208 to determine whether any input nodes of node M have not yet been selected and evaluated.
If determined at 2210 that input node N is not equal to node I, then input node N is not the node that produced the iteration context of node M, and at 2212, the method may include determining a prior node J that produces or defines an iteration context of input node N. As discussed above, in accordance with some embodiments, if a node retracts an iteration context, the iteration context for successive (or following) nodes reverts to the prior iteration context, i.e., the iteration context defined previous to the iteration context of the node that defined the retracted iteration context. If there was no prior iteration context, then the successive nodes act as nodes having no iteration context. A new iteration context defined by a node replaces the current iteration context for following nodes. Thus, a given node has only one iteration context. When an iteration context is replaced by a new iteration context, the new iteration context is considered to be “nested” within the previous iteration context.
At 2214, the method may further include determining whether node J is equal to node I. If node J is equal to node I, then the node that produces the iteration context of the input node N is the same as the node that produces the iteration context of node M, and the method may continue at 2208 to determine whether any input nodes of node M have not yet been selected.
If determined at 2214 that node J is not equal to node I, then node M has a different iteration context than input node N, and at 2216, a temp node P is set equal to node I (i.e., the node that produces the iteration context for node M). At 2218, the method may include determining a prior node Q that produces an iteration context of temp node P. At 2220, the method may further include determining whether node Q is equal to node J. If node Q is equal to node J, then the prior node that produces the iteration context of temp node P is the same as the prior node that produces the iteration context of input node N, and the method may include creating at 2222 an implied dependency from input node N to temp node P. Then the method continues at 2208 for the next selected input node N.
If determined at 2220 that node Q is not equal to node J, then the node that produces the iteration context of temp node P is not the same as the node that produces the iteration context of input node N. Then, at 2224, temp node P is set equal to node Q (i.e., the node that produces the iteration context for temp node P) and execution continues at 2218.
If all of the input nodes N of node M have been evaluated and each node M of the network has been evaluated, then the method at 2204 is done and the method ends at 2226.
Referring to
Referring to
Referring to
Node B, node D and node F are the input nodes for node F. However, nodes D and E are not in the iteration context defined by node A. As discussed above, an implied dependency is created for each input node that is not in the iteration context defined by node A. Thus, an implied dependency 2440 is created between node D and node A so that when the nodes are sorted, node A must come after node D. In addition, an implied dependency 2450 is created between node E and node A so that when the nodes are sorted, node A must come after node E.
Referring to
Referring to
This example of
Referring to
In accordance with some embodiments, the system may determine using the method of
For node M=node A: node M does not follow an iteration context (i.e., node A is not within the iteration context defined by another node and node I is nil) so the method executes up to 2207 then returns to 2204.
For node M=node B: node B does not follow an iteration context (i.e., node I is nil) so the method executes up to 2207 then returns to 2204.
For node M=node C: node C follows the iteration context defined by input N=node B (i.e., node C is within the iteration context defined by node B, so node I=node B=node N) but has no other inputs. Accordingly, the method executes up to 2210 and returns to 2208 and then to 2204.
For node M=node D: node D follows the iteration context defined by input node N=node B (i.e., node D is within the iteration context defined by node B, so node I=node B=node N) but has no other inputs. Accordingly, the method executes up to 2210 and returns to 2208 and then to 2204.
For node M=node E: node E does not follow an iteration context (i.e., node E is not within the iteration context defined by another node and node I is nil) so the method executes up to 2207 and then returns to 2204.
For node M=Node F: node F follows the iteration context defined by node E (i.e., node I=node E). For input node N=node E, node N=node I, so the method executes up to 2210 and returns to 2208. Node F has one other input from node D. For input node N=node D, node N does not equal node I, so the method proceeds to 2212. As discussed in connection with
As stated above, the dataflow diagram 2600 (
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
The output device 2907 may comprise, for example, one or more devices used to output data and information, such as, for example: an IR port, a docking station, a display, a speaker, and/or a printer, etc. The storage device 2908 may comprise, for example, one or more storage devices, such as, for example, magnetic storage devices (e.g., magnetic tape and hard disk drives), optical storage devices, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices.
The storage device 2908 may store one or more programs 2910, which may include one or more instructions to be executed by the processor 2901 to perform one or more portions of one or more embodiments disclosed herein.
In some embodiments, one or more of the programs 2910 may include one or more programs for processing one or more portions of one or more dataflow diagrams that include one or more portions of one or more embodiments disclosed herein.
As stated above, in accordance with some embodiments, to run a standard dataflow program, the dataflow nodes may first be sorted to determine an order of node invocation. Once the order of node invocation is determined, the function of each node is called in turn. Once every node is called one time, the process starts over from the beginning of the list repeatedly running all the nodes' functions in an endless loop. In accordance with some embodiments, running a dataflow program using semantics of the present invention may be similar except that allowances are made for the iteration contexts.
In some embodiments, one or more of the programs 2910 may include one or more programs for processing one or more portions of one or more simulations that include one or more portions of one or more embodiments disclosed herein.
Data representing a dataflow network may be supplied by and/or received from any source(s). Notably, in some embodiments, the data may be received from one or more sources within the processing system 2900. In some embodiments, the data may be received from one or more sources outside the processing system 2900. In some embodiments, the data may be receive from one or more sources within the processing system and one or more outside the processing system 2900. As stated above, in some embodiments, the processing system 2900 comprises a dataflow processing system.
In some embodiments, data representing a dataflow network may be supplied by a user via a user interface. In some embodiments, nodes and/or edges may be rendered using typical computer graphical user interface displays. In some embodiments, node may be shown as a box or icon of some sort. The shape and/or size of different types of nodes can vary widely. That is, in some embodiments, nodes may not be depicted as rectangular.
In some embodiments, data representing a dataflow network may be received via the communication device 2902. In some embodiments, data representing a dataflow network may be stored on and/or received from the storage device 2908. In some embodiments, data representing a dataflow network may be received from a combination of the above. In some embodiments, data representing a dataflow network may be received from one or more sources in lieu of and/or in addition to one or more of the sources described herein.
In some embodiments, storage device 2908 may store one or more databases, including, for example, a dataflow diagram database 2912 (which may include, for example, one or more portions of one or more dataflow diagrams that include one or more portions of one or more embodiments disclosed herein), a simulation database 2914 (which may include, for example, one or more portions of one or more simulations that include one or more portions of one or more embodiments disclosed herein) and/or one or more other databases 2916.
Other programs and/or databases may also be employed.
As used herein, a processing system may be any type of processing system and a processor may be any type of processor. For example, a processing system may be programmable or non programmable, digital or analog, general purpose or special purpose, dedicated or non dedicated, distributed or non distributed, shared or not shared, and/or any combination thereof. A processing system may employ continuous signals, periodically sampled signals, and/or any combination thereof. If the processing system has two or more distributed portions, the two or more portions may communicate with one another through a communication link. A processor system may include, for example, but is not limited to, hardware, software, firmware, hardwired circuits and/or any combination thereof.
Thus, in some embodiments, a processing system may include any sort or implementation of software, program, sets of instructions, code, ASIC, or specially designed chips, logic gates, or other hardware structured to directly effect or implement such software, programs, sets of instructions or code. The software, program, sets of instructions or code can be storable, writeable, or savable on any computer usable or readable media or other program storage device or media such as, for example, floppy or other magnetic or optical disk, magnetic or optical tape, CD-ROM, DVD, punch cards, paper tape, hard disk drive, Zip™ disk, flash or optical memory card, microprocessor, solid state memory device, RAM, EPROM, or ROM.
As used herein, a communication link may be any type of communication link, for example, but not limited to, wired (e.g., conductors, fiber optic cables) or wireless (e.g., acoustic links, electromagnetic links or any combination thereof including, for example, but not limited to microwave links, satellite links, infrared links), and/or combinations thereof, each of which may be public or private, dedicated and/or shared (e.g., a network). A communication link may or may not be a permanent communication link. A communication link may support any type of information in any form, for example, but not limited to, analog and/or digital (e.g., a sequence of binary values, i.e. a bit string) signal(s) in serial and/or in parallel form. The information may or may not be divided into blocks. If divided into blocks, the amount of information in a block may be predetermined or determined dynamically, and/or may be fixed (e.g., uniform) or variable. A communication link may employ a protocol or combination of protocols including, for example, but not limited to the Internet Protocol.
In accordance with some embodiments, the present invention defines semantics for a dataflow diagram language so that it is better able to handle data stored as list-like collections of arbitrary types. First, the dataflow network permits the use of dynamically sized lists for any data edge connection. Second, it allows nodes to be defined that have an “iteration context.” A node with an iteration context controls the number of times that nodes connected its outputs are invoked. Third, a node can be defined to eliminate a level of iteration context so that nodes connected to its output are not controlled by the node that originated an iteration context.
In accordance with some embodiments, the present invention allows data from both input and output connections of nodes to form ordered lists of arbitrary length. There are many kinds of data types that resemble lists and are treated by the present invention in the same manner. For example, a vector or array is a list with fixed size whose values can be accessed by an integer index. A set is an unordered list of a fixed set of values. The programmer implements these types using the generic list type.
In accordance with some embodiments, the present invention provides new semantics for dataflow programming that permit simpler handling of arbitrarily-sized list data. Unlike standard dataflow programming languages that require the programmer to create a second diagram embedded within a node of the main diagram, the present invention allows the programmer to handle lists within a single diagram.
In accordance with some embodiments, the present invention defines an iteration context that a dataflow node can use to influence the behavior of successive nodes connected to its output. The iteration context is used to invoke nodes as many times as is needed to support the computation. This is important because an arbitrary list can have any number of elements (including possibly being empty).
In accordance with some embodiments, nodes can both produce and retract an iteration context. Each context forms an implicit nesting where the nested dataflow nodes are invoked a number of times controlled by the node that produced the iteration context. This feature is primarily used for array manipulation, as performed by the fan-in and fan-out nodes, but can also be used for other purposes such as the guard node.
In accordance with some embodiments, by implementing iteration directly in a single diagram, the programmer has to manage fewer programming conventions. Connecting nodes that produce iteration contexts in a diagram is identical to connecting all other nodes. There is also no need to create multiple diagrams for list processing tasks. Keeping the dataflow program together in a single diagram reduces the risk of not seeing code because the embedded part of the diagram is not on screen.
Unless otherwise stated, terms such as, for example, “in response to” and “based on” mean “in response at least to” and “based at least on”, respectively, so as not to preclude being responsive to and/or based on, more than one thing.
In addition, unless stated otherwise, terms such as, for example, “comprises”, “has”, “includes”, and all forms thereof, are considered open-ended, so as not to preclude additional elements and/or features. In addition, unless stated otherwise, terms such as, for example, “a”, “one”, “first”, are considered open-ended, and do not mean “only a”, “only one” and “only a first”, respectively. Moreover, unless stated otherwise, the term “first” does not, by itself, require that there also be a “second”.
Although various features, attributes and/or advantages may be described herein and/or may be apparent in light of the description herein, it should be understood that unless stated otherwise, such features, attributes and/or advantages are not required and need not be present in all aspects and/or embodiments.
While various embodiments have been described, such description should not be interpreted in a limiting sense. It is to be understood that modifications of such embodiments, as well as additional embodiments, may be utilized without departing from the spirit and scope of the invention, as recited in the claims appended hereto. It is therefore contemplated that the appended claims will cover any such modifications or embodiments as fall within the true scope of the invention.
This application claims priority under 35 U.S.C. § 119 to U.S. Provisional Patent Application Ser. No. 60/848,424, entitled “Inline List Iteration in a DataFlow Network”, filed in the name of Richard Gary McDaniel on Sep. 29, 2006, the contents of which are hereby incorporated by reference in their entirety for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 60848424 | Sep 2006 | US |
