Function and arguments

[ValeryOchkov]

It would be helpful

[StuartBruff]

---

@ValeryOchkov wrote:

It would be helpful

---

How is Mathcad supposed to know that the variables h & r are name-associated with the (arbitrarily named) function parameters h & r?   

What would you expect if the function parameters were named "radius" and "height", yet called with (h,r) as opposed to (r,h), or vice versa?

Are you perhaps intimating that Mathcad should have a type system of some kind, so that h & r could be defined as variables of types, say, "tHeight" and "tRadius", respectively? 

(I'm not averse to a type system, I thnk I've proposed it before, but it should be implemented so as to have minimal impact on existing worksheets.  I envisage it more like a "restriction" system that can apply restraints upon a value / variable that would otherwise behave as normal.  For example, I'd like to be able to restrict a variable (or, perhaps, more formally value) to being an integer, and not just in the symbolic processor.   That would simplify several of my worksheets where I have to apply a rounding function to get what I want.  I'd also envisage such a system as using the largest integer type available, eg int64 rather than restrit it to either 32 or 53 bits.)

Stuart

[LucMeekes]

I oppose to this suggestion, certainly the way it is written here. The two (dummy) parameters r and h in the definition of Vcone(r,h) have no relation whatsoever to the two variables h and r used in the calling of that function, further down.

If you really really need this, it should be implemented like it's done in some programming languages:

      With Vcone(r,h) defined, you can call it with:

            Vcone(h=h, r=r)    or    Vcone (r=r, h=h), or more generally:

            Vcone (h=height, r=radius)   or    Vcone(r=radius, h=height)

where the identifier before the = indicates the name of a dummy parameter of the function, and the one following the = should be a defined variable. 

But, I see no need for it, and given PTC, Prime will not get it in the near future.

Luc

[StuartBruff]

---

@LucMeekes wrote:

I oppose to this suggestion, certainly the way it is written here. The two (dummy) parameters r and h in the definition of Vcone(r,h) have no relation whatsoever to the two variables h and r used in the calling of that function, further down.

Luc

---

To be effected the way Valery has written it, the only way I can see it being done is if a function's local parameter names become global, and if the naming convention is broken such as to maintain a link to the name at definition within the worksheet and any subsequent redefinitions within the worksheet (the new variable values shouldn't flow back up the worksheet, though).  I imagine there'd be some kind of precedence order in place to deal with multiple uses of the same name, perhaps even the ability to choose which name (eg, by prefixing) to avoid error and ambiguity.   I sympathize with your objection.

---

But, I see no need for it, 

---

Clearly, Valery does see a need for it, and I can see that it has some merit, but I wouldn't like breaking the way Mathcad works to implement it.   Maybe a flag in Options or a worksheet variable to enable it (and make clear that it's in force).  However, I have a loooonnngggg list of things I think should be ahead of it in PTC's priority list ...

and given PTC, Prime will not get it in the near future.

---

"near future"?  Do you mean before the Sun enters its red giant phase or merely the next major asteroid extinction event?    😈

Stuart

[StuartBruff]

---

@StuartBruff wrote:

---

@LucMeekes wrote:

I oppose to this suggestion, certainly the way it is written here. The two (dummy) parameters r and h in the definition of Vcone(r,h) have no relation whatsoever to the two variables h and r used in the calling of that function, further down.

Luc

---

To be effected the way Valery has written it, the only way I can see it being done is if a function's local parameter names become global ...

Stuart

---

Or, I suppose, if Mathcad noted the calling argument names and overrode the standard positional association for any arguments that were the same as a parameter name?  That would be preferable to my previous thought.  Again, something that would benefit from being an option.

Stuart

[StuartBruff]

---

@StuartBruff wrote:

---

---

But, I see no need for it, 

---

Clearly, Valery does see a need for it, and I can see that it has some merit, but I wouldn't like breaking the way Mathcad works to implement it.   Maybe a flag in Options or a worksheet variable to enable it (and make clear that it's in force).  However, I have a loooonnngggg list of things I think should be ahead of it in PTC's priority list ...

and given PTC, Prime will not get it in the near future.

---

"near future"?  Do you mean before the Sun enters its red giant phase or merely the next major asteroid extinction event?    😈

Stuart

---

Thinking about whilst the Sun is up (I'm assuming, one can never be sure In Glasgow.  I'm going by the brightness of the clouds), I' can recall several recent occasions when it would have been useful.  I tend to use the same variables for the same thing, but often forget which way round I'm supposed to put the arguments.  Naturally, I'm too lazy to look at the documentation (if any) or hunt for the definition beforehand, so it would be useful on such occasions,

Stuart

[ValeryOchkov]

Thanks for remarks.

See please one solution of this problem in my WaterSteamPro cloud packadge: I have arguments names in functions names.