dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start [2022/03/22 13:12] char [Overview] |
dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start [2022/05/27 19:47] (current) nick grammar |
||
|---|---|---|---|
| Line 21: | Line 21: | ||
| [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]] | [[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 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, 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 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 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: |
| * 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> | * 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> | ||
| Line 89: | Line 89: | ||
| [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]] | [[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 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. | + | **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. | 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]] | [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]] | ||
| - | **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. | + | **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 === | === Stack Data === | ||
| [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]] | [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]] | ||
| - | **[[dido:public:ra:xapend:xapend.a_glossary:s:stack_memory]]** is generally allocated and un-allocated from contiguous blocks of memory automatically during the execution of a program. When a program is executed, memory is allocated for all the parameters passed to the program and all the variables declared in the program. Upon the completion of the program, all the memory allocated for the program is released to be used by the next program. Often, the first program executed is often referred to as the **Main** program. | + | **[[dido:public:ra:xapend:xapend.a_glossary:s:stack_memory]]** is generally allocated and unallocated from contiguous blocks of memory automatically during the execution of a program. When a program is executed, memory is allocated for all the parameters passed to the program and all the variables declared in the program. Upon the completion of the program, all the memory allocated for the program is released to be used by the next program. Often, the first program executed is often referred to as the **Main** program. |
| Any other programs (i.e., subprograms) called during the program are again allocated more memory for its parameters and declared variables from the **Stack**. Upon termination of the subprogram, the memory allocated to the subprogram is released back to the system to be reused for other subprograms. **Note:** the original memory allocated for the main (or calling program) program remains allocated until that program ends. This repetitive and successive allocation creates a **stack** of allocation, with the most recent subprogram being at the top of the **stack**. The **stack** gets deeper and shallower depending on the depth of subprogram allocations. | Any other programs (i.e., subprograms) called during the program are again allocated more memory for its parameters and declared variables from the **Stack**. Upon termination of the subprogram, the memory allocated to the subprogram is released back to the system to be reused for other subprograms. **Note:** the original memory allocated for the main (or calling program) program remains allocated until that program ends. This repetitive and successive allocation creates a **stack** of allocation, with the most recent subprogram being at the top of the **stack**. The **stack** gets deeper and shallower depending on the depth of subprogram allocations. | ||
| 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 **''main''** routine | ||
| - During compilation of the file, the compiler determines the amount of memory required to run **''greetings''** 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 **''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 | - 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]] | [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility:start| Return to Top]] | ||
| - | [[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 | - 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 **''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 | - 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 148: | Line 148: | ||
| * 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(( | * 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]] | 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**(( | 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)." | )), "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 pointer 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 ===== | ===== Arguments and Parameters ===== | ||
| Line 174: | Line 174: | ||
| There is often confusion about Arguments and Parameters while discussing functions, procedures, methods or operations. In .NET and Javascript the following definitions are used: | 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 or operation | + | * **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 or 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 necessary in the order specified by the function declaration. | + | * 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> | <Code html> | ||
| Line 237: | Line 237: | ||
| ))</caption> | ))</caption> | ||
| ^ Fortran | <WRAP> | ^ Fortran | <WRAP> | ||
| - | * Always used the inout semantics model | + | * Always used the INOUT semantics model |
| * Before Fortran 77: pass-by-reference | * Before Fortran 77: pass-by-reference | ||
| * Fortran 77 and later: scalar variables are often passed by value-result | * Fortran 77 and later: scalar variables are often passed by value-result | ||
| Line 254: | Line 254: | ||
| * p2 is pass-by-value | * p2 is pass-by-value | ||
| * p3 is pass-by-reference | * 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> | | </WRAP> | | ||
| ^ Java | <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 | * However, because objects can be accessed only through reference variables, object | ||
| parameters are in effect passed by reference | parameters are in effect passed by reference | ||
| Line 265: | Line 265: | ||
| </WRAP> | | </WRAP> | | ||
| ^ Ada and SQL | <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 be referenced but not assigned; inout parameters can be referenced and assigned | + | * 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 |
| </WRAP> | | </WRAP> | | ||
| ^ C# | <WRAP> | ^ C# | <WRAP> | ||
| Line 293: | Line 293: | ||
| - | <color darkblue><todo @nick>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 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 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> | ||
dido/public/ra/1.2_views/3_taxonomic/4_data_tax/07_volitility/start.1647969141.txt.gz · Last modified: 2022/03/22 13:12 by char
