The parameter ORIGIN does not work inside a program block.

[JCBanks]

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.

[LucMeekes]

Please attach a worksheet that demonstrates the problem that you are experiencing.

Success!
Luc

[JCBanks]

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

.

[LucMeekes]

Attachments to your mail do (apparently) NOT make it to this forum, so I cannot see it.

Check: https://community.ptc.com/t5/Mathcad-Installation/The-parameter-ORIGIN-does-not-work-inside-a-program-block/m-p/899806#M3295

Success!
Luc

[JCBanks]

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

[LucMeekes]

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

[JCBanks]

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.

[LucMeekes]

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

[JCBanks]

Luc, I will define the ORIGIN outside the Programming blocks.

"Kill the dog, get rid of the fleas" 🙂

Thanks, Luke.

Julio Banks

[JCBanks]

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

[LucMeekes]

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