3
$\begingroup$

This question already has an answer here:

I have developed a notebook of 30+ functions for Geometric Algebra, all of which involved using the symbol e with subscripts like Subscript[e,1]. I write them here as e1, e2, e3 ... for readability. The functions all work correctly in the Notebook with the default Global` context. Two items that complicate my question is my use of infix operators and a Palette I designed as a user-friendly device (with sliders, etc.) for the user to enter values that set up his environment.

I would like to make the functions available to others so I am trying to write my first package, and everything seems to work except a few instances of context shadowing. I believe I know how to modify the palette to eliminate those shadows but if not I may have to ask for help on that. I've boiled the other problem down to a short package (.m file) and data notebook, shown below. To illustrate the problem, I have created a simple wedge (^) infix operator, Fooxy. The result of x ^ y should be 4, as the last line shows, but it is not because the symbol e is shadowed in contexts Globaland Geom.

ClearAll["Geom`*"];

BeginPackage["Geom`"]
Fooxy::usage="Fooy[x,y]";

Begin["`Private`"]
Wedge:=Fooxy
Fooxy[x_,y_]:=Expand[x y]/.Subscript[e, u_]->1

End[]
EndPackage[]

Here is a sample user notebook:

Needs["Geom`"]
x=1+Subscript[e,2];y=1+Subscript[e,1];
z=x^y
z = Expand[x,y]/.->1

Here is the output I get:

1 + Subscript[e, 1] + Subscript[e, 2] + Subscript[e, 1] Subscript[e, 2]
4

If the user sticks to a simple notebook using just Global` context, then a VERY SIMPLE FIX is to insert

e=Global`e;

after Begin["Private"]. This also fixes my palette issue and it may not be unreasonable for me to just release the package as is and put this limitation in the docs.

The current fix for shadow problems like this (Kuba, et. al. will correct me if I misunderstand this) is to have the user input Fooxy with the context of his e symbol:

Fooxy[x_,y_,e_]

If I make that small change, again all is well as long as I use Fooxy. But if I do this I don't think I can continue to use wedge, and wedge is necessary for the user to be able to do manipulations like x ^ y ^ z ^ w which are unwieldy otherwise. The package has 4 or 5 such infix operators currently with perhaps more to come.

I tried fixing this in a few ways but failed. One pretty reasonable approach is to require the user during setup to execute an initialization function that lets the package grab his context into a variable and somehow use it in function Fooxy or to replace the e-Global`e statement in the Private section. Alternately I could design a context input in the Palette, allowing the user to change it on-the-fly. Another approach might involve Removing all e symbols except for the one in the user's context?

$\endgroup$

marked as duplicate by Kuba, Feyre, m_goldberg, MarcoB, Mr.Wizard Dec 21 '16 at 22:49

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 4
    $\begingroup$ Take a look at: 114769 and 41741 $\endgroup$ – Kuba Dec 21 '16 at 6:59
  • 1
    $\begingroup$ @matrixbud but 114768 is not advising to use Global` at all. The solution would be to define Fooy[x_, e_]:= like Integrate or D do. Your quick fix with Global` will fail as soon as someone will load your package from a notebook which has local context (CellContext->Notebook) because then e in the notebook will be Notebook$123`e or something. $\endgroup$ – Kuba Dec 21 '16 at 22:27
  • 1
    $\begingroup$ I'm encouraging you to read 114769 and linked topics, especially Szabolcs' answer about new symbols' context: 43381 $\endgroup$ – Kuba Dec 21 '16 at 22:29
  • 1
    $\begingroup$ @Mr. Wizard I am trying to learn and adhere to stackexchange protocols. I could edit my questions again to better illustrate my questions above to J.M, but after your comment I hesitate to do more than put my question as an additional comment. I do believe my problem is a little different than 114769, etc. if I explain the infix and other complications but I am not the expert and you folks might think it is still a duplicate question $\endgroup$ – matrixbud Dec 22 '16 at 21:34
  • 1
    $\begingroup$ @matrixbud I believe it is entirely appropriate to edit your question in an effort to differentiate it from the other one. Doing so will automatically add it to the Reopen Review Queue. At worst people don't think it is different enough and it stays closed; at best you have a clarified question with fresh eyes on it. Looking at the timeline I see that I recommended you post and answer and then joined in voting to close the question preventing you from doing so. That must have been confusing and I am sorry. Self-answers are still encouraged. (continued) $\endgroup$ – Mr.Wizard Dec 22 '16 at 22:14

Browse other questions tagged or ask your own question.