Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming of arguments #27

Open
RobinHankin opened this issue Aug 23, 2019 · 4 comments
Open

Naming of arguments #27

RobinHankin opened this issue Aug 23, 2019 · 4 comments

Comments

@RobinHankin
Copy link
Owner

RobinHankin commented Aug 23, 2019

In the package functions, spray objects are pretty consistently denoted S. But kform and ktensor objects are less consistent. I have been using notation consistent with whatever textbook I was using at the time, but this leads to inconsistent argument naming. Here is a compilation of argument names, arranged by manpage:

Rdfile		kform	ktensor
stokes-package  "various" "T1 T2"
contract        "K"     NA
hodge           "K"	NA
kform           "S"	NA
issmall         "x"	NA
keep 		"K"     NA
Ops.kform 	"e1 e2" "e1 e2"
symbolic 	"K"	"K"
transform 	"K"     NA
is.volume 	"K"	NA
wedge2 		"K1 K2" NA
Alt 		NA	"S"

(NB: this table is edited from time to time as I modify the package)

@RobinHankin
Copy link
Owner Author

in scalar.Rd we have is.scalar(x) which I think is OK because the argument might be a kform or a ktensor. Perhaps M would be better because both kforms and ktensors are multilinear maps.

@RobinHankin
Copy link
Owner Author

OK so the best I can come up with is this: S for spray objects, K for kforms, U for ktensors, M for multilinear maps that can be either ktensors or kforms. I will try to use these unless there is a good reason why not (e.g. Ops.foo(), where e1,e2 is universal.

RobinHankin added a commit that referenced this issue Aug 24, 2019
@RobinHankin
Copy link
Owner Author

fixed in commit 9e00f23 (the commit message was "fixes issue #27" which did not close the issue).

@RobinHankin
Copy link
Owner Author

Quite a lot of docs use omega but I am not sure if this is OK or not

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant