Range variables in local definition

[keyboarder-disa]

Range variables can be used to assign multiple vector or matrix values. For example:
M[i := i^2
A[i := B[j,i+1

However, the same construct does not work with a local definition--in a function definition, for example.
M[i <- i^2

Is this behavior expected? Do I really need to use a for loop to reproduce the behavior for local definitions inside a function? Or is it a bug? I consider it a bug since there is no apparent reason this shouldn't work. I should be able to do the same thing inside a function that I do in the main worksheet.

I'm using Mathcad 14.0 M030.

[TomGutman]

>> Do I really need to use a for loop to reproduce the behavior for local definitions inside a function?<<

Yep. Local variables are never range variables, even if their value is a range. And a global range variable cannot be used in a function definition, due to the restriction that if a range variable appears on the right of an assignment (:=) it must also appear on the left.
__________________
� � � � Tom Gutman

[ptc-1368288]

>Do I really need to use a for loop to reproduce the behavior for local definitions inside a function? Or is it a bug ? <<br> ____________________________

Certainly not a bug. Your proposal is incomplete.
A range variable is a variable,
if you don't assign, how can you have to process ?



jmG

[keyboarder-disa]

On 4/20/2010 1:15:59 AM, jmG wrote:

>Certainly not a bug. Your proposal is incomplete.

>A range variable is a variable, if you don't

>assign, how can you have to process ?



Of course. In my example, I was assuming the range variable was already defined over a valid range. (I guess there's all types and levels of users that might actually have missed that point, but I was just trying to be concise.)


Here's the same example on my installation of Mathcad 14.0 M030 with all compatibility options set to MC12.

[ptc-1368288]

>Here's the same example on my installation of Mathcad 14.0 M030<<br> ___________________________

I couldn't not work with that kind of illogical setup. This is one of the reason why most of the work sheets done up to version 11 didn't work after that version and were eliminated from the repository, thus scraping the best of the Mathcad collabs or contributors ... V[3 has a single value, not a ranged value. If you never had Mathcad 11 or earlier versions, you have no idea how great Mathcad was.

jmG

[keyboarder-disa]

On 4/20/2010 9:46:42 AM, jmG wrote:
>I couldn't not work with that
>kind of illogical setup. This
>is one of the reason why most
>of the work sheets done up to
>version 11 didn't work after
>that version and were
>eliminated from the
>repository, thus scraping the
>best of the Mathcad collabs or
>contributors

I'm not quite sure what you mean. Is it my
example and worksheet snapshot that are
"illogical"? Or are you talking about the buggy
Mathcad results?

>... V[3 has a
>single value, not a ranged
>value.

Your example is exactly what I expect Mathcad to
return, but it does not work on my installation.
My point was that I tried to reproduce what you
showed, but my installation of Mathcad did not
return the same basic result. It's that simple.
Do you have the same version 14.0 M030? Or is
your example from Mathcad 11?

I had hoped that someone might know why or
indicate some way to fix this. It is also curious
that your example works, but others say that a for
loop is required in a local definition... and they
say it is "by design". I wonder how many bugs
have been around so long that they are now "by
design".

[RichardJ]

On 4/21/2010 4:04:47 AM, cperk wrote:
>On 4/20/2010 9:46:42 AM, jmG wrote:
>>I couldn't not work with that
>>kind of illogical setup. This
>>is one of the reason why most
>>of the work sheets done up to
>>version 11 didn't work after
>>that version and were
>>eliminated from the
>>repository, thus scraping the
>>best of the Mathcad collabs or
>>contributors
>
>I'm not quite sure what you mean. Is it
>my
>example and worksheet snapshot that are
>"illogical"? Or are you talking about
>the buggy
>Mathcad results?

It's not a bug, although it was (note the past tense) a very bad design decision.

>Your example is exactly what I expect
>Mathcad to
>return, but it does not work on my
>installation.

Yes it does.

>My point was that I tried to reproduce
>what you
>showed, but my installation of Mathcad
>did not
>return the same basic result. It's that
>simple.
>Do you have the same version 14.0 M030?
>Or is
>your example from Mathcad 11?

It is from MC11.

>I had hoped that someone might know why

Because when they went from MC11 to MC12 they rewrote the compute engine. Lot's of things changed (mostly, although not exclusively, for the worse) and/or simply didn't work anymore. Some of those things were bugs, some were just bad decisions. Version 12 is a really bad version. It's so bad that last time I installed Mathcad I didn't bother with 12, even for testing purposes (I have 11, 13, and 14 installed). Fortunately, since version 12 most of the really bad bugs and decisions have been fixed.


>or
>indicate some way to fix this.

Easy. Don;t set the compatibility to version 12. Set it to version 11, which may be an older version, but it's a much better one. Basically, if you ever have the option of doing something the "12 way" or some other way, choose the other way.

> It is
>also curious
>that your example works, but others say
>that a for
>loop is required in a local
>definition... and they
>say it is "by design".

The definition of the range variable is not local in that example, it is global. You cannot locally define a range variable, but you can locally use one. If you want to loop within a program you are much better off using a program loop (either for or while) though. A range variable is essentially a loop variable at the worksheet level, but the loop is not delimited in any way. The range variable is valid until the end of the sheet, or you overwrite the definition. A program loop is delimited: it applies to a specific, well defined, block of statements.

Richard

[ptc-1368288]

On 4/21/2010 10:45:26 AM, rijackson wrote:
>On 4/21/2010 4:04:47 AM, cperk wrote:
>>On 4/20/2010 9:46:42 AM, jmG wrote:
__________________________________________

Who wrote what ? getting hairy.
Mathcad is just a tool, there was no need to recode after version 11, simply add functions/functionalities/ergonomics maybe some solvers... etc. The "recoders" didn't consider that their version should read at least down to Mathcad 8. The only bugs known in Mathcad 11 is the 3D bug and the Matrix symbolic misinterpretation. Too many great talkers and little doers not respecting the structure, doing wrong does not mean bug, just doing wrong.

jmG

[RichardJ]

On 4/21/2010 11:32:27 AM, jmG wrote:
> The only bugs known in
>Mathcad 11 is the 3D bug and the Matrix
>symbolic misinterpretation.

And then there would be the cfft memory leak bug that we discussed (again) only a few days ago, and....

MC11 doesn't have nearly as many bugs as MC12, but it has plenty of bugs.

Richard

[ptc-1368288]

Oh ! Yes, Richard ... CFFT memory leak.
In case you have a demo list of more, that might help 11 users.
I have no other ones in mind, maybe you have.

Jean

[RichardJ]

Sorry, but I don't have a list. I can think of one more though easily enough though. Graphs are inaccurate. As I recall, you were the first to point it out 🙂

The bug is actually that the numbers on the axes are wrong (they have been incorrectly rounded off). It's been fixed.

Richard

[TomGutman]

>>Basically, if you ever have the option of doing something the "12 way" or some other way, choose the other way. <<

Not as simple as that. There are two compatibility options. The local assignment result was indeed broken in MC12 (doesn't meet the specificiations) and should be set to MC11 mode for proper operation.

But the multiple assignment was broken in MC11 (doesn't meet the specifications, does assignments serially rather than the documented parallel) and was fixed in MC12. That option should be set to MC12.

It's rather unfortunate that they chose to identify the compatibility options by MC version numbers rather than by the actual functions. It makes it rather difficult for somebody not intimately familiar with all the quirks of all versions to know what to choose.
__________________
� � � � Tom Gutman

[keyboarder-disa]

On 4/21/2010 9:56:21 PM, Tom_Gutman wrote:
>There are two compatibility options.
>The local assignment result
>was indeed broken in MC12
>and should be set to
>MC11 mode for proper operation.
>
>But the multiple assignment
>was broken in MC11
>and was fixed in MC12. That
>option should be set to MC12.
>__________________
>� � � � Tom Gutman

Thank you for the direct, useful response. This change allows my original local assignment expressions to work as I initially expected them to.

[StuartBruff]

On 4/21/2010 4:04:47 AM, cperk wrote:
== Your example is exactly what I expect Mathcad to return, but it does not work on my installation. My point was that I tried to reproduce what you showed, but my installation of Mathcad did not return the same basic result. It's that simple. Do you have the same version 14.0 M030? Or is your example from Mathcad 11?
== I had hoped that someone might know why or
indicate some way to fix this. It is also curious that your example works, but others say that a for loop is required in a local definition... and they say it is "by design". I wonder how many bugs have been around so long that they are now "by design".

Following up on Richard's comments, M11 returns the last calculated value from a program. In this instance, it is the scalar value associated with M_i. M12, however, returns the entire current value of the vector M.

There are some legitimate instances in M11..M14 where a range variable can be used on the rhs only of a definition, eg Range Variable Sums and Products. M13 and M14 will also allow you to pass a range variable as an argument to a function on the rhs only, eg:

f(i):=|for k ∈ i
| x_k ← k
|x

i:=0..5
z:=g(i)

I have a long-standing feature request in to allow a program to carry out range variable calculations in a similar manner to the top level worksheet.

Stuart

[RichardJ]

On 4/21/2010 3:10:13 PM, stuartafbruff wrote:

>I have a long-standing feature request
>in to allow a program to carry out range
>variable calculations in a similar
>manner to the top level worksheet.

I have a long standing request that if it is obvious what a construct should do, then the construct should be allowed. The local definition of a range variable is just one of many examples.

Richard

[ptc-1368288]

On 4/21/2010 3:10:13 PM, stuartafbruff wrote:
...
>I have a long-standing feature request
>in to allow a program to carry out range
>variable calculations in a similar
>manner to the top level worksheet.
>
>Stuart
___________________________________

"top level work sheet",
I may be the only collab not clear on what you mean [whatever]. In this example, no need to specify about 'n' iterate in the program ... it does by built-in structure. Range 'n' as you wish by figuring what you expect and it plots so. For the independent range argument, obviously the programme carries, the programme being a function ... that's where I think you mean "top level work sheet".
The other way I can think of is the "Createmesh" structure where the LHS of the programme carries the start/end of the range in each direction and the number of meshes ... + ... it can carry a parameter, which parameter can be ranged in the same way as the attached example, except that in this example the 'n' iterate need not be included because of the different structure.

The contour is "B", cut by the chain saw.
Just a personal demo from archives.

jmG

[PhilipOakley]

On 4/19/2010 10:27:18 PM, cperk wrote:
>Range variables can be used to
>assign multiple vector or
>matrix values. For example:
> M[i := i^2
> A[i := B[j,i+1
>
>However, the same construct
>does not work with a local
>definition--in a function
>definition, for example.
> M[i <- i^2
>
>Is this behavior expected? Do
>I really need to use a for
>loop to reproduce the behavior
>for local definitions inside a
>function? Or is it a bug? I
>consider it a bug since there
>is no apparent reason this
>shouldn't work. I should be
>able to do the same thing
>inside a function that I do in
>the main worksheet.
>
>I'm using Mathcad 14.0 M030.

A range variable isn't a 'vector' as would happen in MatLab. It is one of the confusions.

Also, for no particular reason, a for loop is required in programmes (i.e. when using <- ). It is a design choice.

Philip Oakley

[keyboarder-disa]

On 4/20/2010 6:21:40 AM, philipoakley wrote:
>A range variable isn't a 'vector' as
>would happen in MatLab. It is one of the
>confusions.

Thank you. I understand the difference. Even
though they are not the same, it is common
practice to access and assign vector and matrix
values using a range variable in the subscripts.
Until now I had just never tried doing that inside
a function. I just expected (and I think it was a
reasonable assumption) that the same construct
would be allow there.

>Also, for no particular reason, a for
>loop is required in programmes (i.e.
>when using <- ). It is a design choice.

Thank you again. At least as you and Tom pointed
out that is not necessarily a "bug". I now know to
use a for loop inside a program/function. I still
consider it a bug however, because sometimes it
allows the syntax but gives erroneous results
without any indication of an error. It is also a
poor design decision, at least from a user and
interface perspective. The documentation does not
warn about the difference... that I could find.

[PhilipOakley]

On 4/21/2010 3:52:01 AM, cperk wrote:
>On 4/20/2010 6:21:40 AM, philipoakley
>wrote:
..
>>Also, for no particular reason, a for
>>loop is required in programmes (i.e.
>>when using <- ). It is a design choice.
>
>Thank you again. At least as you and
>Tom pointed
>out that is not necessarily a "bug". I
>now know to
>use a for loop inside a
>program/function. I still
>consider it a bug however, because
>sometimes it
>allows the syntax but gives erroneous
>results
>without any indication of an error. It
>is also a
>poor design decision, at least from a
>user and
>interface perspective. The
>documentation does not
>warn about the difference... that I
>could find.

Yes, It is what Tom calls a design bug. It is 'wrong' by design!

Philip Oakley

[TomGutman]

Nowhere near as simple as that.

It starts with the definition of a range variable iteration. It iterates statements. There are two types of statements that it can iterate (execute repeatedly), assignment (:=) and evaluation (=). Such statements are top level constructs, not part of any other construct nor do they have values.

Local assignment (←) is quite different. It is not a statement, but an operator. It results in an expression, which is typically a part of a larger construct. It is not at all clear how an expression (rather than a statement) should be iterated). Even less clear is what the value of such an iterated expression should be. Also unclear is how the implied local variable (the iterator) should be handled, and how it interacts with other local variables.
__________________
� � � � Tom Gutman

[AlvaroDíaz]

On 4/21/2010 10:03:21 PM, Tom_Gutman wrote:

>Nowhere near as simple as ...

Very clear explanation.

As an addendum, reading a range variable as an equivalent 'for' loop, the hidden 'next' statement it's at the end of the worksheet, or just before a redefinition of the range variable. That's at the worksheet level, in the usual way.

An equivalent range construction inside a program, probably can put the hidden next's at the end of the program, and then work just like and for case is writing, following the for rules, and not the global range variable rules.

What I don't know if it is possible to write in that case unlogical expression. Like, for example, the very bad situation: two range variable definitions, one in the 'if' case, and other in the 'otherwise' case. Which 'next' go first? Remember that mathcad have not "delayed" assignations. Can compile well this situation?

For unexpected results, just see this example (mathcad 11 only):



Regards. Alvaro.

[keyboarder-disa]

Tom's difference between a "statement" and an "expression" helps. An assignment using a range variable is like a for loop, repeatedly executing the assignment for each value in the range variable. I suppose the entire assignment either has no value, or perhaps it could be viewed as having multiple values... Mathcad apparently treats it as having no value (which is somewhat limiting since other non-assignment statements using range variables can display multiple values). A single local assignment, on the other hand, returns the same value being assigned--the expression itself has a value. That makes sense.

I agree, it is nowhere near as simple as that. The differentiation between a "statement" and "expression with a value" is blurred with Mathcad's recent ability to immediately show the result of a worksheet assignment by typing an inline =. It implies that the worksheet "statement" does indeed have a value in many instances, just like a local assignment.

The term "local definition" or "local assignment" implies an issue of scope--global vs local for instance--not an entirely different operation or statement type. I gather that many Mathcad users think it is the same operation as a worksheet variable assignment statement; an assignment to a variable with local scope with otherwise the same exact functionality as a "worksheet assignment". Even if this idea is technically incorrect, it is certainly a natural assumption given the name "local definition" and familiarity with other programming languages, etc. It only emphasizes a need for something to improve... documentation, implementation, changing what they call certain "operators", etc.

jmG's and my images show that the simplest example produced different results. How can that be misunderstood? I entered exactly the same statements and got different, unexpected results. It was not meant to be a complicated example. Various explanations followed, from MC11 and MC12 compatibility options and bugs, to implications that I am just "doing wrong". I don't care what you call it, be it a bug, a "design decision", whatever. It is obvious that it does not work as one would expect without an unprecedented deep understanding of the history of Mathcad and all of its past implementations! Ridiculous!

I will abandon the word "bug" to avoid flaming the fire. However, from the face of it, Mathcad is supposed to offer an intuitive, natural syntax. This entire conversation emphasizes that the Mathcad "design" misses the mark with the syntax we're discussing. Certainly a deeper understanding of the various constructs helps, but it demands better, more explicit documentation and perhaps a more intuitive implementation.

[ptc-1368288]

"jmG's and my images show that the simplest example produced different results."
__________________________________

As a single Mathcader, it takes years to discover the Mathcad visionary structure. If your version opens "Casteljau" [posted above], just admire that 3 lines of Mathcad doing same as pages of coding. "expression" is a "scalar definition" that you learn from the error message "This is not scalar". A "statement" is a very, too very general word ... "declaration" is no better. You would need a word [if any can be thought of] in term of Mathcad rather than in term of other coding. In 1970 FORTRAN IV you would "declare" an array for instance, a range variable by punching card. Today, the numerical computing structure is just a bit different and the old words don't necessarily mean the same thing, and in this collab every one has its own words.

jmG