I like Mathematica so much, it has almost everything, it's just crazy. Soz, just had to say it.

@anhnha What you are after is @@. which replaces the Head (which is List). @@@ applies @@ to each of the elements, and is equivalent to f @@#&/@ {{a,b...

@WeavingBird1917 nope, I know @@. I just wonder about @@@.

it seems that {a, b, c}, {d, e} is not considered as a sequence

Oh, why would should it be considered a sequence?

a, b, c is a sequence so I thought {a, b, c}, {d, e} is also a sequence

a, b, c isn't a sequence but a List in {{a, b, c...

well, {a,b,c} is a list

not a,b,c

{{a, b, c}, {d, e}} can be written as {Sequence[{a, b, c}, {d, e}]}

so why doesn't @@@ just replace the head Sequence?

that's my question

I think it's because the sequence gets converted before @@@ is applied.

Since it's basically Apply[f, {Sequence[{a, b, c}, {d, e}]}, {1}]

but you wrote exactly the same thing

The arguments of Apply will get evaluated first, where {Sequence[{a, b, c}, {d, e}]} -> {{a, b, c}, {d, e}}

just longform

okay, that makes sense

@b3m2a1 Aaaah, that makes sense. Sounds fun.

Can I check unevaluated form of {{a, b, c}, {d, e}}?

@anhnha {{a,b,c},{d,e}} is the unevaluated form - the expression is inert, so there is nothing to evaluate.

As for your question about @@@: The expression {{a,b,c},{d,e}} does not contain Sequence, it is exactly what it looks like. When working with Apply it often helps to think about the full-form of an expression. In your case, this would be List[List[a,b,c], List[d,e]]. Now, @@ replaces the head of the entire expression, so f@@List[List[a,b,c], List[d,e]] -> f[List[a,b,c], List[d,e]].

For @@@, the heads of each of the elements of the expression are replaced. Here, the elements are List[a,b,c] and List[d,e], so f@@@List[List[a,b,c], List[d,e]] -> List[f[a,b,c], f[d,e]]

You might be interested in Level: It returns all the expressions at a certain level of another expression - this way, you can see what Apply[f,expr,levelspec] will affect when given a certain levelspec. In the case above, see Level[{{a,b,c},{d,e}}, {0}], and Level[{{a,b,c},{d,e}}, {1}]

@LukasLang that's a good way to look at it. Actually I tried Level[{{a,b,c},{d,e}}, {1}] before and it returned {{a, b, c}, {d, e}} so I thought {a, b, c}, {d, e} as a sequence.

is there any advantage than Range[100]-1?

@anhnha No - I think it should just serve as an easy-to-understand example of Outer, where one can easily predict the result

I tried this and got the error: Plot::pllim: Range specification {x,-3,-([Pi]/2),[Pi]/2,3} is not of the form {x, xmin, xmax}.

@anhnha I also got that error in v12. Where did you get that example from?

@ChrisK it's from this tutorial: library.wolfram.com/infocenter/Books/8510/…

@anhnha that syntax is no longer supported, see Exclusions for the new way to specify singularities. Interestingly, the linked tutorial says "Mathematica 7.0 and up", but rhe feature is not documented in Version 7.0 (although it still works. Also, I might have simply missed it in the documentation)

How about this one?

Both lines are thick on my machine

@JasonB. Yes, I did. It doesn't really work for me because I'm interested in larger queen's graphs than what Wolfram has precomputed

But it works nicely with RelationGraph and a suitable adjacency function

Actually it works but the thickness isn't easy to distinguish with the normal one.

I have a paclet that implements a context, say "Foo`". In it there is a Manipulate[] demo, say coolDemo[], for my students to use. However, all the Manipulate variables get the context "`Foo`Private`" and the variable names show up as Foo`Private`x etc. in the output. I'd like the users to be able to enter just x. Workarounds: (1) Bracket the definition of coolDemo[] with Begin["Global`"] and End[]. (2) Pass the variables as arguments, coolDemo[x, y].

Any other suggestions?

Option (1) causes all the Manipulate variables to leak into the global context. Bracketing with Begin["Foo`"] allows the variables to display as simply x. However, if Global`x already exists, you get a shadowing warning and x displays as red.

I probably didn't make this clear: The user needs to be able to enter a formula in an InputField. I thought it would be ok to make my class have to use x and y.

@MichaelE2 When formatting use Internal`$ContextMarks = False?

Block[{Internal`$ContextMarks = False},
 ToBoxes[b`c`d`e`f]
 ]

"f"

Block[{Internal`$ContextMarks = True},
 ToBoxes[b`c`d`e`f]
 ]

"b`c`d`e`f"

That requires a bit of FE leg-work on your part, though

What's a place where this bites you?

It's hard to know which workaround to apply

Like if it's in the controls, use multi-argument control specs

If it's in some symbolic output, you can use that Internal`$ContextMarks = False and convert it into boxes from the get-go

If all symbols will be single letters and you're doing symbolic processing you can also use the Formal... symbols

@b3m2a1 That's a cool flag I didn't know about. However, I think Manipulate beats Block in this application. Here's an MWE:

Remove[x];
Begin["Foo`Private`"];
Manipulate[
 {f, D[f, x]},
 {{f, Cos[x]}, InputField}
 ]
End[];

Will the output always be small?

If so you can use Block[{Internal`$ContextMarks=False}, RawBoxes@ToBoxes[content]]

Currently:

Ohh I see the issue is in the InputField?

Yes

So, two options, one: make this an ExpressionCell and put CellContext->"Foo`Private`"

I'll try that...

Second one: pre-process any symbol in "Foo`Private`" to be formal

As long as people use single letters the second will work well

What's the control spec you're using there?

You can also pass a multi-argument form of any control spec where you get complete control over the rendered control

The first row is a Row of standard Control objects -- is that what you're asking about?

Can you give me the exact expression?

I can probably write a minimal fix

Row[{
  Control@{{F, {-y, 2 x}, "F"}, InputField,
    TrackingFunction -> ((F = #; theta = 0.) &)},
  Control@{{vplotter, VectorPlot, ""}, {VectorPlot, StreamPlot}},
  " ",
  Control@{{update, False, "update"}, {False, True},
    TrackingFunction -> ((update = #;
        If[TrueQ@update, t0 = theta, t0 = 0.]) &)}
  }]

Are they obligated to use x and y?

There are also Bookmarks with some preprogrammed examples for them, in terms of x and y.

The vector field is differentiated with respect to x and y

I wanted to avoid their having to enter what variables they are using.

The bookmarks are a list of things like:

Bookmarks -> {
  "node 1 (asymptotically stable)" :> (F = {-2 x, -3 y}; theta = 0.;
    pts = 20),
  ...}

Forgot how InputField worked for a bit but try this:

boxMeUpScotty[content_] :=

  Block[{Internal`$ContextMarks = False}, RawBoxes@ToBoxes[content]];

Control@{
  {F, {-y, 2 x}, "F"},
  InputField[
    Dynamic[
     boxMeUpScotty@F,
     ((F = #; theta = 0.) &)]
    ] &
  }

We only change how the Dynamic displays

@b3m2a1 OK, the CellContext -> "FooPrivate" seems to work in the MWE. (The first time f was not initialized for some reason, but I'm not able to reproduce that behavior.)

Sounds good. If that starts to break down you can get finer-grained control with that Control method.

E.g.:

Remove[x];
Begin["Foo`Private`"];
Manipulate[boxMeUpScotty@{f, D[f, x]}, {
  {f, Cos[x], f},
  InputField[
    Dynamic[
     boxMeUpScotty@f,
     ((f = #) &)]
    ] &}]
End[];

@b3m2a1 Thanks! The CellContext option seems to be working on the real thing, and it seems simple enough.

It also means if the students executes x = 3 it doesn't mess up the demo.

@MichaelE2 I think CellContext could even be an option to Manipulate (and would do exactly this). That'd help with lots of these localization issue.

@b3m2a1 When the user enters a new expression for f, the x is assigned to the Global` context.

@b3m2a1 Oh, cool. That sounds even better.

I don't think it exists right :)

That was like a future feature thought

If I had any control over that kind of thing

CellContext shows up as red in Manipulate and it doesn't work. :)

As expected

It's really an option to Cell

But since Manipulate is basically a way to hide the messiness of FE programming from the user when the use case is simple, I think WRI should add it as an option.

Or LocalizeVariable -> context

Exactly

Although that usage might make people think it will truly localize their variables

But thanks for the CellContext solution.

Which would be a difficult introspection