Differences

This shows you the differences between two versions of the page.

--- dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start [2022/01/28 10:09]
nick
+++ dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start [2022/05/27 19:47] (current)
nick grammar
@@ Line 5: / Line 5: @@
 [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]]
-Data is tied to the memory where it is used during the [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_in_use| Data-In-Use ]] state. Basically, there are six different taxons that cover Data-In-Use. Although memory categories presented in Figure {{ref>MemoryStack}} are shown as having definite boundaries with definite rules governing the use of the categories; there are situations where these classification and boundaries deviate from the definiton. For example, the use dynamic code written as strings and processed at runtime, intepretive code, and reflection.
+Data is tied to the memory where it is used during the [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:02_state_taxonomy:data_in_use| Data-In-Use ]] state. Basically, there are six different taxons (i.e., taxonomic groups) that cover Data-In-Use. Although the memory categories presented in Figure {{ref>MemoryStack}} are shown as having definite boundaries with definite rules governing the use of the categories; there are situations where these classification and boundaries deviate from the definition. For example, the use of interpretive code using dynamic code written as strings or the use of reflection.
@@ Line 16: / Line 16: @@
 [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]]
-A computer program is a ordered sequence of computer instructions that when executed in order accomplish a goal or task. Each computer architecture defines its own [[dido:public:ra:xapend:xapend.a_glossary:i:instruction_set]]. When a program is executed, a Program Counter is set to the first instruction in the program. As the program executes each individual instruction, the program can modify data within the Variable area or it can modify the program counter (i.e., ''GO TO'' a specific instruction in the instruction set). As a general rule, the Instruction data can not be changed during the execution of a program. When the programs do change the contents of the excuting program, it is usually considered a fault and the program stops executing (see [[dido:public:ra:xapend:xapend.a_glossary:s:segfault]]).
+A computer program is an ordered sequence of computer instructions that when executed in order accomplish a goal or task. Each computer architecture defines its own [[dido:public:ra:xapend:xapend.a_glossary:i:instruction_set]]. When a program is executed, a Program Counter is set to the first instruction in the program. As the program executes each individual instruction, the program can modify data within the Variable area or it can modify the program counter (i.e., ''GOTO'' a specific instruction in the instruction set). As a general rule, the Instruction data cannot be changed during the execution of a program. When programs do change the contents of the executing program, it is usually considered a fault and the program stops executing (see [[dido:public:ra:xapend:xapend.a_glossary:s:segfault]]).
 ===== Constant Data ======
 [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]]
-**Constant Data** is a value that is expected to remain constant overtime (i.e., the number of pennies in a dollar, the number of seconds in a minute, the value of Pi, the gravitation constant, speed of light, etc.). In software, constants are usually hardcoded into the software and require a recompile and link in order to change them. Therefore, although in programming constants can change, it is generally not a trival task. Sometimes constants might need to change or updated is when the precision used to represent the constant value needs to change (i.e., the value of Pi going from single precison ''3.1415927'' to double precision ''3.14159265358979323846''. Constants in programming should not change during the normal execution of the program. Sometimes the "constancy" canbe violated or pruposely circumvented by by overwriting the memory location where the value is stored or by using self-modifying code or dynamic code. Using constants in software can:
+**Constant Data** is a value that is expected to remain constant over time (i.e., the number of pennies in a dollar, the number of seconds in a minute, the value of Pi, the gravitation constant, the speed of light, etc.). In software, constants are usually hardcoded into the software and require a recompile and link in order to change them. Therefore, although programming constants can change, it is generally not a trivial task. Sometimes constants might need to change or be updated such as when the precision used to represent the constant value needs to change (i.e., the value of Pi going from single-precision ''3.1415927'' to double-precision ''3.14159265358979323846''. Constants in programming should not change during the normal execution of the program. Sometimes the "constancy" can be violated or purposely circumvented by overwriting the memory location where the value is stored or by using self-modifying code or dynamic code. Using constants in software can:
-  * Alow for compile-time or editing-time checking of operations such as assigning a value to a constant. In the following examle, most modern editors and all compilers raise erros on the second line. <WRAP>
+  * Allow for compile-time or editing-time checking of operations such as assigning a value to a constant. In the following example, most modern editors and all compilers raise errors on the second line. <WRAP>
 <code C++>
   const float PI = 3.1415927;
@@ Line 29: / Line 29: @@
 </code>
 </WRAP>
-  * Increase reability (i.e., myVar*PI where PI is the value of the numerical constant 3.1415927 is more readable than myVar*3.1415927)<WRAP>
+  * Increase readability (i.e., myVar*PI where PI is the value of the numerical constant 3.1415927 is more readable than myVar*3.1415927)<WRAP>
 <code C++>
   const float PI = 3.1415927;
@@ Line 37: / Line 37: @@
 </code>
 </WRAP>
-  * Icrease performance by aiding in compiler optimation (i.e., allocating memory once to hold the constant rather than once per usage)<WRAP>
+  * Increase performance by aiding in compiler optimization (i.e., allocating memory once to hold the constant rather than once per usage)<WRAP>
 <code C++>
   const float PI = 3.1415927;
@@ Line 57: / Line 57: @@
 [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]]
-**Literal Constansts** are the actual numeric values (i.e., 3.1415927) or are characters (i.e., '''H'''), or strings of characters (i.e., ''"Hello World"'') used in the software. In the following example, ''"Helo World! %d"'', ''42'' and ''0'' are literal constants.
+**Literal Constants** are the actual numeric values (i.e., 3.1415927) or are characters (i.e., '''H'''), or strings of characters (i.e., ''"Hello World"'') used in the software. In the following example, ''"Hello World! %d"'', ''42'' and ''0'' are literal constants.
 <code C++>
 int main()
@@ Line 81: / Line 81: @@
 [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]]
-**Variable Data**, in contrast to **[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start#constant_data| Constant Data]]**, is a data item whose value can change during the program’s execution. In other words, the **Variable Data** value varies over time. There are two main categories based on the lifespan of the of **Variable Data**:
+**Variable Data**, in contrast to **[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start#constant_data| Constant Data]]**, is a data item whose value can change during the program’s execution. In other words, the **Variable Data** value varies over time. There are two main categories based on the lifespan of the **Variable Data**:
   * [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start#static_data| Static Data]]
@@ Line 89: / Line 89: @@
 [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]]
-**Static Data** is data that does not change after it has been set. Static Data is usually defined during startup or initialization os a system or subsystem. Some comon examples of Static Data are setup parameters of a system; or properties or attributes of objects within a system (i.e., constructor settings). Data that is static differs form immutable data because immutable data can have newer values, but the original values are never replaced, lost or destroyed. Generally, newer immutable data has pointers to the privious values of the data.
+**Static Data** is data that does not change after it has been set. Static Data is usually defined during the startup or initialization of a system or subsystem. Some common examples of Static Data are setup parameters of a system; or properties or attributes of objects within a system (i.e., constructor settings). Data that is static differs from immutable data because immutable data can have newer values, but the original values are never replaced, lost, or destroyed. Generally, newer immutable data has pointers to the previous values of the data.
 It is a fixed data set. Experts contrast static data with dynamic data, where dynamic data may change after it is recorded, and has to be continually updated.
@@ Line 96: / Line 96: @@
 [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]]
-Dynamic Data is usually data is created, updated and maintained by the programs. It is generally divided into two areas, the **Heap** and the **Stack**. The two areas are organized and managed differently and the boundary between the two areas is fluid (i.e., the amount of space allocated to either the **Heap** or the **Stack** can expand and contract as long as the total amount of memory in the **Heap** or the **Stack** does not exceed the amount of **Dynamic Data** allocated for the program.
+**Dynamic Data** is usually data that is created, updated, and maintained by the programs. It is generally divided into two areas, the **Heap** and the **Stack**. The two areas are organized and managed differently and the boundary between the two areas is fluid (i.e., the amount of space allocated to either the **Heap** or the **Stack** can expand and contract as long as the total amount of memory in the **Heap** or the **Stack** does not exceed the amount of **Dynamic Data** allocated for the program.
 === Stack Data ===
@@ Line 110: / Line 110: @@
   - During compilation of the file, the compiler determines the amount of memory required to run **''main''** routine
   - During compilation of the file, the compiler determines the amount of memory required to run **''greetings''** routine
-  - The **''main''** program is executed from the command lime and the amount of memory required to run the **''main''** is allocated and placed on the **stack**
+  - The **''main''** program is executed from the command line and the amount of memory required to run the **''main''** is allocated and placed on the **stack**
-  - When the **''main''** program executes the line that invokes the **''greetings''** routine, the memory required for it is allocated and place onto the **stack**
+  - When the **''main''** program executes the line that invokes the **''greetings''** routine, the memory required for it is allocated and placed onto the **stack**
   - When the **''greetings''** routine is finished, the memory used to execute the routine is removed from the **stack** and released for re-use
   - When the **''main''** routine is finished, the memory used to execute the routine is removed from the **stack** and released for re-use
@@ Line 123: / Line 123: @@
 [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]]
-The [[dido:public:ra:xapend:xapend.a_glossary:h:heap]] is essentially a large pool of memory (typically per process) from which a running program requests chunks of memory for use within the program. The memory is dynamically allocated during the execution of a program using allocation operations such as **''malloc''** or new operators on arrays or objects. When the program (i.e., process terminates, the chunks of memory allocated during the execution of the program are returned. Because the memory is allocated as it is needed and returned as it is required, the memory available for allocation often gets fragmented into small blocks which is very difficult to use and can result in memory exhaustion. This is why modern programming languages have implemented automatic memory management and a process called garbage collection.
+[[dido:public:ra:xapend:xapend.a_glossary:h:heap]] is essentially a large pool of memory (typically per process) from which a running program requests chunks of memory for use within the program. The memory is dynamically allocated during the execution of a program using allocation operations such as **''malloc''** or new operators on arrays or objects. When the program (i.e., the process terminates, the chunks of memory allocated during the execution of the program are returned. Because the memory is allocated as it is needed and returned as it is required, the memory available for allocation often gets fragmented into small blocks which are very difficult to use and can result in memory exhaustion. This is why modern programming languages have implemented automatic memory management and a process called garbage collection.
   - A program is written into a file that contains a **''main''**. **Note:** During compilation of the file, the compiler determines the amount of memory required to run **''main''** routine
-  - The **''main''** program is executed from the command lime and the amount of memory required to run the **''main''** is allocated and placed on the **stack**
+  - The **''main''** program is executed from the command line and the amount of memory required to run the **''main''** is allocated and placed on the **stack**
   - When the **''main''** program executes the line that invokes the **''malloc''** statement, the memory required for it is allocated from the **heap**
   - When the **''main''** program executes the line that invokes the **''free''** statement, the memory required for it is returned to the *Heap** for later use (see
@@ Line 142: / Line 142: @@
 [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]]
-Often the two terms: **Attribute** and **Property** are used interchageable in Computer Science because we often use them to describe the elements of an [[dido:public:ra:xapend:xapend.a_glossary:o:object]] in [[dido:public:ra:xapend:xapend.a_glossary:o:oop]]. However, it is useful to understand the difference between the two gramatically:
+Often the two terms: **Attribute** and **Property** are used interchangeably in Computer Science because we often use them to describe the elements of an [[dido:public:ra:xapend:xapend.a_glossary:o:object]] in [[dido:public:ra:xapend:xapend.a_glossary:o:oop]]. However, it is useful to understand the difference between the two grammatically:
-  * An **Attribute** is a quality or object that we attribute to someone or something. For example, intelligence is an attribute of a person. You can not go to the store and buy intelligence, it is an attribute of the individual. Another example would be a planet belonging to a solar system. Planets do not usually exist outside a solar system.
+  * An **Attribute** is a quality or object that we attribute to someone or something. For example, intelligence is an attribute of a person. You cannot go to the store and buy intelligence; it is an attribute of the individual. Another example would be a planet belonging to a solar system. Planets do not usually exist outside of a solar system.
   * A **Property** is a quality that exists without any attribution. Geometric shapes are properties in their own right. They can be used to independently describe many things. For example, a planet or a ball can be described as a sphere((
 Sphere, In geometry, the set of all points in three-dimensional space lying the same distance (the radius) from a given point (the center), or the result of rotating a circle about one of its diameters. The components and properties of a sphere are analogous to those of a circle.[[https://www.britannica.com/science/sphere]]
-)). A definition of the sphere exists without the attribution to a planet or a ball. Therefore, we say that a planet or a ball have spherical properties.
+)). A definition of the sphere exists without the attribution to a planet or a ball. Therefore, we say that a planet or a ball has spherical properties.
 In UML, an **Attribute** and a **Property** both represent a structural association between two entities. **Attributes** are most often represented as **Composition**((
@@ Line 167: / Line 167: @@
 )), "UML Attributes are DataTypes (e.g., Strings, Integers, etc.) whereas [[dido:public:ra:xapend:xapend.a_glossary:s:sysml]] properties are ValueTypes (e.g., can be assigned computed values)."
-Some parameters are Mutable and others are [[dido:public:ra:xapend:xapend.a_glossary:i:immutable]]. Mutable parameters can be changed inside an operation, and an immutable parameter can not. When a parameter is marked as **Immutable** (i.e., **''in''**) in some programming languages, a copy of the original value is made and passed to the operation on the Stack. One the operation is completed, the copied value is lost as the stack is unwound. Some languages such as the C, all values are passed by value (i.e., are **immutable**) unless the value is passed by reference using a pointer to the variable. When a parameter is marked as mutable, then a new values is returned. In C, the general way to do this is by returning the value via a **''return''** statement. If the **mutable** parameter is a pointer, then the value that the pointer points to can be changed, but not the pointer itself. In C, it is possible to have a ppointer to a pointer allowing the value pointed to be changed, but not the original pointer.
+Some parameters are Mutable and others are [[dido:public:ra:xapend:xapend.a_glossary:i:immutable]]. Mutable parameters can be changed inside an operation, and an immutable parameter can not. When a parameter is marked as **Immutable** (i.e., **''in''**) in some programming languages, a copy of the original value is made and passed to the operation on the Stack. Once the operation is completed, the copied value is lost as the stack is unwound. In some languages such as the C, all values are passed by value (i.e., are **immutable**) unless the value is passed by reference using a pointer to the variable. When a parameter is marked as mutable, then a new value is returned. In C, the general way to do this is by returning the value via a **''return''** statement. If the **mutable** parameter is a pointer, then the value that the pointer points to can be changed, but not the pointer itself. In C, it is possible to have a pointer to a pointer allowing the value pointed to be changed, but not the original pointer.
+===== Arguments and Parameters =====
+[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]]
+There is often confusion about Arguments and Parameters while discussing functions, procedures, methods or operations. In .NET and Javascript the following definitions are used:
+  * **Arguments** are the **Keys** or **Names** of the arguments, usually provided during the specification of the  function, procedure, method of operation
+  * **Parameters** are the **Values** associated with the **Arguments** during the invocation of the function, procedure, method of operation
+  *  that you pass. This enables you to pass arguments in any order, and not necessarily in the order specified by the function declaration.
+<Code html>
+<!DOCTYPE html>
+<html>
+<body>
+<?php
+# Declare a function that looks for a needle in a haystack.
+# $haystack is an ARGUMENT
+# $needle is an ARGUMENT
+function string_contains (
+    string $haystack,
+    string $needle
+  ): bool {}
+# Using Positional Notation, the PARAMETERS must be in the same order as defined in the function
+# Foobar is the first PARAMETER
+# Foo is the second PARAMETER
+string_contains (
+    'FooBar',
+    'Foo'
+  );
+# Using Named Notation, the PARAMETERS are named haystack and needle and can occur in any order
+string_contains (
+    haystack: 'FooBar',
+    needle: 'Foo'
+  );
+string_contains (
+    needle: 'Foo',
+    haystack: 'FooBar'
+  );
+?>
+</body>
+</html>
+</Code>
 <table mutabilty>
@@ Line 180: / Line 228: @@
 <table inOutspecifics>
-<caption>How various programing languages pass Mutable and Immutable parameters((
+<caption>How various programing languages pass **Mutable** and **Immutable** parameters((
-Adapted from:
+Adapted from: Dr. Kuo-pao Yang,
+Southeastern Louisiana University,
+Computer Science 401, Survey of Programming Languages
+September 2014,
+Accessed: 28 January 2022,
+[[https://www2.southeastern.edu/Academics/Faculty/kyang/2019/Fall/CMPS401/ClassNotes/CMPS401ClassNotesChap09.pdf]]
 ))</caption>
 ^ Fortran | <WRAP>
-  * Always used the inout semantics model
+  * Always used the INOUT semantics model
   * Before Fortran 77: pass-by-reference
   * Fortran 77 and later: scalar variables are often passed by value-result
@@ Line 201: / Line 254: @@
   * p2 is pass-by-value
   * p3 is pass-by-reference
-  * Neither p1 nor p3 need be explicitly dereference in fun
+  * Neither p1 nor p3 need be explicitly dereferenced in fun
 </WRAP> |
 ^ Java  | <WRAP>
-  * All parameters are passed are passed by value
+  * All parameters are passed by value
   * However, because objects can be accessed only through reference variables, object
 parameters are in effect passed by reference
@@ Line 211: / Line 264: @@
 cause the change
 </WRAP> |
-^ Ada  | <WRAP>
+^ Ada and SQL | <WRAP>
-  * Three semantics modes of parameter transmission: in, out, inout; in is the default mode
+  * Three semantics modes of parameter transmission: in, out, INOUT; IN is the default mode
-  * Formal parameters declared out can be assigned but not referenced; those declared in can
+  * Formal parameters declared out can be assigned but not referenced; those declared in can be referenced but not assigned; INOUT parameters can be referenced and assigned
-be referenced but not assigned; inout parameters can be referenced and assigned
 </WRAP> |
 ^ C#  | <WRAP>
@@ Line 241: / Line 293: @@
+<color darkblue><todo @nick #char:2022-03-22>this line doesn't make sense .. especially the end .. "For example, the use of dynamic code written as strings and processed at runtime, interpretive code, and reflection." Processed at runtime is OK but the next don't make sense.  Should it be "used as interpretive code, and support reflection"???</todo></color>\\
+<color blue><todo @char #char:2022-03-16>New Section -- review  -- finished have comment above -- had to get rid of a number of duplicate sections.</todo></color>
-<color darkblue><todo @nick>Is this page still under construction?</todo></color>\\
-<color red><wrap hi>Page is still being updated -- especially the sections above that are still blank</wrap></color>\\
-<color blue><todo @char>New Section -- review </todo></color>
 /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

DIDO Wiki

User Tools

Site Tools

Differences

Page Tools