Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X
I am using Mathcad Prime Release 9.0 and Datecode9.0.0.0
The parameter ORIGIN does not work inside a program block.
Here are the errors that I faced:
The parameter ORIGIN does not work inside a program block.
Please attach a worksheet that demonstrates the problem that you are experiencing.
Success!
Luc
Attached is the file with the reported issue.
Thanks,
Julio C. Banks
Solutions Consultant
“Doing Business by the Book”
e-mail: Creo_Solutions@Outlook.com
(772) 577-9744
P Please consider the environment before printing this email.
“Education is a better safeguard of liberty than a standing army"
Edward Everett
.
Attachments to your mail do (apparently) NOT make it to this forum, so I cannot see it.
Success!
Luc
Dear Luc, the System parameter, ORIGIN, does not
work inside programming blocks.
Attached is the work book you provided which I
modified to demonstrate the issue.
The program in Mathcad Prime 9.0 is intended
for "reader using software such as Excel" that
thy can implement but thank you anyway for
indicating to me that it is a built-in function.
Please advise, Luc
As I explained, you should not (try to) modify the value of ORIGIN within a program; it does not work.
If you delete the first assignment in that program
ORIGIN <- 1
Then the program calculates the correct value of Q, irrespective of the setting of ORIGIN.
In short: Don't change ORIGIN in a worksheet. You normally should use it. E.g. to sum all values of an array, use:
This will let the index i run from the first index (no matter what the setting of ORIGIN is, it can be 0, 1 or -200) to the last index. as shown here:
Now if you change ORIGIN to any (other, integer) value , Sum(A) will still produce the same answer. And if you change the number of elements in A, the result will follow accordingly.
Success!
Luc
Understood, Luc.
It seems logical to me that if ORIGIN set on the outside
of a programming block controls the definition of the
ORIGIN of arrays then it should also work inside
Programing blocks.
In any event, I could live with the fact Mathcad does
not allow the user to define "The arrays ORIGIN inside
programing blocks".
The question I have is:
Is it logical for the Mathcad Prime software to
allow a "Local definition of ORIGIN" when it is
"defined inside a Programming block"? - As a
customer requested enhancement?
I do not see why this suggestion would not be
logical.
Please advise the logic of not allowing the definition
of the ORIGIN of arrays that are only used within
Programing blocks.
Thanks, Luc.
You should think of ORIGIN as being a setting, not a variable. And one shouldn't mess with settings...
Note that there are many programming languages where the index start is fixed, generally 0, sometimes 1, but you cannot change it. There may not be many applications that call for other values than 0 or 1, At least Mathcad allows to change it at will on worksheet level.
It's logical in the sense that it's always been this way, with Mathcad, and now with Prime.
As to why? My guess is as good as yours, we're in the same boat: users.
Success!
Luc
Luc, I will define the ORIGIN outside the Programming blocks.
"Kill the dog, get rid of the fleas" 🙂
Thanks, Luke.
Julio Banks
Luc, attached is the file showing the error when
assigning ORIGIN inside "Program blocks".
Notice that ORIGIN := 1 on page 1 and ORIGIN := 0
on the second page.
Thanks,
Julio Banks
You're confusing
with
The first is the system variable ORIGIN, which defines the first/starting index for arrays (vectors and matrices).
The second is a(n ordinary) variable ORIGIN, which has NOTHING to do with array indexing.
If you want to define ORIGIN, you must ensure that the identifier is labelled correctly:
Apart from that, you are right to observe that the statement ORIGIN <- 1 (or whatever other value) does not work (as might be expected) in a program. See this:
Note that I use different font settings for the differently labelled items, because that makes life easier, and helps to prevent errors. My program demonstrates that even if ORIGIN is 3, I can still use index 0 for array b.
Now is this a bug? I think not. I think that changing the value of ORIGIN to various values within one sheet should not be done. In the case of your Ft calculation along b, you apparently need i to run from 1 to a value n, so it would be better programmed as:
Finally. It seems as though you are programming a function that is (almost) readily available in Prime.
Check out pnorm():
then
and
Your second function is related to the built-in qnorm():
then
Success!
Luc