Martin,
I was afraid of this difference in versions being a problem with our discussion. Unfortunately, this is the very reason I have not upgraded to newer versions. I did not want my extensive work based on 0.89 to show errors. It would be a huge problem to try to debug them all to make them work properly in newer versions.
There clearly are differences in the handling of global vs local in our two different versions. Some are feature changes and some are bug fixes implemented in the advancement from my version to yours. I hope none of the differences are caused by the introduction of new bugs into the newer versions.
You are on the right track with your understanding of my use of the term active definition. However, the assignments are only a part of it. smath doesn't just handle embedded assignments during a definition, it also parses the RHS, assembles local and global variables, does numeric and symbol substitutions, applies some optimizations, constructs a sequence of operations on the local and global variables, and generates a mini computer subroutine that represents the function. We must understand all this activity, because much of it (often in unexpected ways) can affect the global environment subsequent to the definition. That is why I use the term active definition.
The algorithms for doing all these things are different depending on the specific structures that are used and how they are combined in an expression. The goal of smath is to generate a subroutine that behaves as we would expect in a mathematical perspective that is analogous to what a mathematician might create with pen and paper. The problem is that the possibilities are so vast that even when things work exactly as we want them too, surprising effects can occur that confuse us. For example, in a global sheet, an assignment in the beginning of the sheet to a variable name may have been forgotten and we reuse the same variable later on with unexpected results. Also, the handling of global and local spaces differs among the many structures and even among the many usage possibilities of each structure. To gain the benefit of the power and potential of smath, we must spend much time learning about its structures, how it represents expressions, and get our thinking in sync with it so we can create expressions that are handled in exactly the way we want and get result that are in tune with what we are looking for.
Radovan,
I surely would like to use the math tags. However, with my version (a known bug), the copy does not correctly represent an expression in its text string format that I can paste into the forum posting editor. Since I don't know the exact ascii syntax of complicated expressions that smath generates, I am at a loss. I will make some time soon and study how to provide file attachments, screen shots, and live smath embedding into my posts. It will probably have to wait till after the holidays.
Also, thank you for trying out the if statement. I don't believe you have made any mistakes. My belief is that the algorithm for parsing has been updated for the better. The circular nature of the original expression makes it difficult to say what is a correct parsing. I'm not even sure there is a correct parsing, just one that follows a set of consistent rules and with results that allow us to understand how and why the reconstructed expression is created. In this case, I think I like your versions result better than my own. I can even accept that for the embedded assignment p := p + q, the parser saw it was circular since global p is not numerically initialized and chose to ignore it leaving global p undefined. I can live with that ground rule. It also seems the parser initialized global m to the value global r and left the local m in the algebraic formula unchanged. Again, this is a ground rule I can live with. This parser behavior is easy to understand and allows us to create predictably behaving formulas (at least in this case).
Martin,
I have some more information about how the for loop behaves, at least in my version. I also looked into the issue with the imaginary number and discovered some interesting things, including some mishandling by smath.
For loop:
In my brief explanation in my previous post, I stated the index variable is local. I spoke too soon. Using i as the index caused its own quirky and misleading behavior. It looks like index handling is more complicated and its behavior using i is just a further complication. i is a reserved character, so we will talk about that later and not use it in this discussion. My latest exploration in my version shows the following behavior:
Using the for loop as RHS in an assignment operation:
Behavior upon definition:
- the LHS must have parens and at least one parameter for smath to use the for loop, or it won't create the definition
- the parameter must be that of the first value in the range
- additional parameters are permitted, but not necessary
- on the RHS, the index variable must be a single, naked variable, no embedded assignment is allowed
- the index variable has no local or global effects at definition time (it is inactive)
- the first and second range variables may be assigned to other variables and the assignment is active
- such assignments use global values the range vars had prior to the definition and assign to global vars with subsequent effect
- the body of the for loop has no local or global effects at definition time (it is inactive)
- embedded assignments are allowed in the body, but are inactive at definition time
Behavior upon call:
- a check is made that the number of parameters matches that from the definition, won't execute if there is mismatch
- parameter for index var is ignored completely by the index var
- value of global var with same name as index var is ignored
- in my version, the index var is global and its final index value has global effect after execution
- assignments to index var embedded in range vars are superseded by the index assignment
- assignments to index var in body of for loop become final value (from last loop iteration) in the global environment
- in yours, it only is global if used in the body of the for loop as shown in your example
- the first range var takes value of its parameter
- the second range var takes value of its parameter if it exists, if not, takes value from the global variable
- both range variables are strictly local vars unless assigned to, in which case their values are copied into global counterparts
- embedded assignments of the range vars are carried out
- if range vars don't have integer values execution is halted
- if range vars have values that allow body execution, it proceeds
- any embedded global assignments are carried out
Use of the for loop as free floating expression holds no surprises and behaves as we would expect with all global variables.
smath sometimes does not execute a call to the function after an editing change. F9 must be hit to recalculate. Don't know why. So when investigating, sometimes we examine expressions that are considered syntax errors and smath can be confused. It will mislead the investigation if F9 is not hit and we make note of a result that isn't real because smath forgot to recalculate. FYI. We must always make sure a recalculation is made after an edit in order to be sure that we are seeing the real effects of the edit on smath's behavior.
Imaginary number:
- imaginary i is reserved and smath confuses itself as explained below
- if reassigned in global environment i := 5, smath redefines i as integer 5 thereafter in the sheet correctly
- dynamic assistance will show as imaginary anywhere on the sheet before the reassignment and i -> 5 afterwards
- if used as an index in a free floating for loop (with no global reassignment prior), i will be reassigned properly
- HOWEVER, the dynamic assistance shows that if the for loop is RHS of an assignment, i is MISHANDLED
- i is not reassigned after function definition, this is correct
- i should be reassigned after function call is executed and this works correctly
- BUG: any i typed in anywhere on the sheet before or after for loop call is assumed by smath to be imaginary
- sometimes, doing so can cause other i's present after the function call to revert to imaginary
- sometimes moving an expression i-> will cause all i's after function call to revert to imaginary
- this only occurs when the change triggers smath to recalculate
- but only when smath forgets to recalculate the function call when it recalculates
- maybe smath is only recalculating below the i-> and if i-> is below the function call, the call isn't recalculated
- when the page is recalculated, the for loop's reassignment takes over again for all i's present after the for loop
- the for loop may not be the only example of this behavior and we should identify where it occurs
- BUG: is smath only sometimes recalculated and if so, why and why not?
- is function call sometimes not included, if so, why and why not?
- is this behavior a bug or feature?
- what are the rules for recalculation and what should I look for to make sure those rules are being properly followed?
-
Edited by user 17 December 2012 21:24:13(UTC)
| Reason: Not specified