Lew_Merrick
Guest
First of all, let me reiterate that describing these values as parameters is intrinsically (and mathematically) wrong! A parameter is, by definition, a variable created by an extera function -- not merely another variable. What we have are Local and Project-Wide variables. Being clear about this will make our system mathematically correct.
What we have as our basis are types of variables: defined as: Distance, Angle, Count (Integer), and Scale (Floating Point Number). We need, added to that foundation, String and Validity. These two additions will make our use of variables much more powerful.
Another thing that confuses many starting out in using these variables is how strongly they are Typed. This is not truly a "bad thing," is just needs to be explained more clearly in (what passes as) the Equation Editor documentation. What is needed are operators to TypeCast operations. One of the things I do quite regularly is to reduce the thickness and width of Parts machined from Bar Stock to assure that the resulting surfaces are truly flat and square. In the case of Hot Rolled Steel material, an allowance of .060 inch is (generally) sufficient. Thus, the thickness of the Bar may be defined as, had I such a TypeCasting operator as: Thick_Dist = Cast_Dist(( Cast_Count(Part_T hick/.0625) + 1) * .0625). Here in the U.S HRS Bar up to 1.000 inches thick is (generally) readily available in increments of 1/16 inch. This assures that, for Bars thinner than 1.000 inches thick, that the Thick_Dist variable is correctly set. A change to the Part model (within reason) will result in an appropriate change to the Thick_Dist value. Thus, a Cast_Dist TypeCast insures that the overall variable is a Distance value while the Cast_Count TypeCast insures that the (Part_T hick/.0625) + 1) value is interpreted as a
Count. Similarly, a Wide_Dist value for HRS Bar would span from 1/2 inch to 1-1/2 inch wide by 1/8 inch increments, from 1-12 inch wide to 3-1/2 inches wide by 1/4 inch increments, from 3-1/2 inches wide to 4-1/2 inches wide by 1/2 inch increments, and those wider than 5 inches wide (to 12 inches wide) by 1 inch increments.1. Rules such as these are (fairly) easy to determine and make for better Stock Size designations.
It should be immediately obvious that some knd of IF, THEN, ELSE operator would be incredibly useful in such operations. Using the Thick_Dist example from above, a sequence of IF statements in the form of: IF Part_Thick < .95, THEN Cast_Dist(( Cast_Count(Part_T hick/.0625) + 1) * .0625), ELSE IF Part_Thick < 1.2, THEN[/i] (etc). The number of times an IF, THEN, ELSE operator would have made for more powerful relationship settings would be hard for me to list! I know that many users I have spoken with agree with me.
String values raise their own "issues." Converting numeric values into String values is one of them. I began "high level language" programming using Algol. Therefore the "1f3" type of operator leaps to what's lefr of my mind. Modern spreadsheets use the Text("numeric variable name", "0.000") command. Something is needed to accomplish such formatting.
A Concatenation operand is needed. I assume that it would work something like: Stock_Size = concatenate( TEXT(Thick_Dist, "#.000"), " X ", TEXT(Wide_Dist, "#.000"), " "). This would make it (relatively) simple to "group" all parts to a Project made from (say) HRS Bar 1.000 X 3.000 and find out how long a piece is required to make all such Parts needed for the Project.
Whereas I am a big fan of the Validity operation, it is somewhat hard to justify in terms of variables. The only use that leaps to (what's left of0 my mind would be for Factors_of_Safety. I often have Parts in a Project where deformation
is not all that critical. In such cases a Factors_of_Safety of "1.11" is sufficient. Other Parts may require a Factors_of_Safety of "1.18." Still other Parts may require a Factors_of_Safety of "1.50." A Validity selection will reduce typographic errors and improve accuracy -- something I believe to be worthwhile.
Finally, I will argue that Project-wide (or Company-wode) "base versions" should be "loadable" at Part or Assembly initiation. As we used to have a Save and Load function for the Equation Editor, it ought to fall into the doable category.
What we have as our basis are types of variables: defined as: Distance, Angle, Count (Integer), and Scale (Floating Point Number). We need, added to that foundation, String and Validity. These two additions will make our use of variables much more powerful.
Another thing that confuses many starting out in using these variables is how strongly they are Typed. This is not truly a "bad thing," is just needs to be explained more clearly in (what passes as) the Equation Editor documentation. What is needed are operators to TypeCast operations. One of the things I do quite regularly is to reduce the thickness and width of Parts machined from Bar Stock to assure that the resulting surfaces are truly flat and square. In the case of Hot Rolled Steel material, an allowance of .060 inch is (generally) sufficient. Thus, the thickness of the Bar may be defined as, had I such a TypeCasting operator as: Thick_Dist = Cast_Dist(( Cast_Count(Part_T hick/.0625) + 1) * .0625). Here in the U.S HRS Bar up to 1.000 inches thick is (generally) readily available in increments of 1/16 inch. This assures that, for Bars thinner than 1.000 inches thick, that the Thick_Dist variable is correctly set. A change to the Part model (within reason) will result in an appropriate change to the Thick_Dist value. Thus, a Cast_Dist TypeCast insures that the overall variable is a Distance value while the Cast_Count TypeCast insures that the (Part_T hick/.0625) + 1) value is interpreted as a
Count. Similarly, a Wide_Dist value for HRS Bar would span from 1/2 inch to 1-1/2 inch wide by 1/8 inch increments, from 1-12 inch wide to 3-1/2 inches wide by 1/4 inch increments, from 3-1/2 inches wide to 4-1/2 inches wide by 1/2 inch increments, and those wider than 5 inches wide (to 12 inches wide) by 1 inch increments.1. Rules such as these are (fairly) easy to determine and make for better Stock Size designations.
It should be immediately obvious that some knd of IF, THEN, ELSE operator would be incredibly useful in such operations. Using the Thick_Dist example from above, a sequence of IF statements in the form of: IF Part_Thick < .95, THEN Cast_Dist(( Cast_Count(Part_T hick/.0625) + 1) * .0625), ELSE IF Part_Thick < 1.2, THEN[/i] (etc). The number of times an IF, THEN, ELSE operator would have made for more powerful relationship settings would be hard for me to list! I know that many users I have spoken with agree with me.
String values raise their own "issues." Converting numeric values into String values is one of them. I began "high level language" programming using Algol. Therefore the "1f3" type of operator leaps to what's lefr of my mind. Modern spreadsheets use the Text("numeric variable name", "0.000") command. Something is needed to accomplish such formatting.
A Concatenation operand is needed. I assume that it would work something like: Stock_Size = concatenate( TEXT(Thick_Dist, "#.000"), " X ", TEXT(Wide_Dist, "#.000"), " "). This would make it (relatively) simple to "group" all parts to a Project made from (say) HRS Bar 1.000 X 3.000 and find out how long a piece is required to make all such Parts needed for the Project.
Whereas I am a big fan of the Validity operation, it is somewhat hard to justify in terms of variables. The only use that leaps to (what's left of0 my mind would be for Factors_of_Safety. I often have Parts in a Project where deformation
is not all that critical. In such cases a Factors_of_Safety of "1.11" is sufficient. Other Parts may require a Factors_of_Safety of "1.18." Still other Parts may require a Factors_of_Safety of "1.50." A Validity selection will reduce typographic errors and improve accuracy -- something I believe to be worthwhile.
Finally, I will argue that Project-wide (or Company-wode) "base versions" should be "loadable" at Part or Assembly initiation. As we used to have a Save and Load function for the Equation Editor, it ought to fall into the doable category.
