« first day (2189 days earlier)      last day (2296 days later) » 

theorist
theorist
1:41 AM
@MichaelE2 Yeah, but it seems it’s not just about the toolset; the mathematical space restrictions applied to the individual variables also matter. Consider these four examples (where I’ve made the “Complexes” domain restriction explicit for clarity, even though it’s the default and is thus not necessary):
Reduce[-0.1547*d + 11.74 == Log[10, a*Exp[-d/c]], {a, c, d}, Reals] vs.
Reduce[-0.1547*d + 11.74 == Log[10, a*Exp[-d/c]], {a, c, d},
Complexes] vs.
Reduce[-0.1547*d + 11.74 ==
Log[10, a*Exp[-d/c]] && {a, d, c} \[Element] Reals, {a, d, c},
The 1st fails but the 2nd, which you describe as using the most powerful tools (Complexes), fails as well. But note from the 3rd example that if we add, to the 2nd, the variable restrictions, we get an answer. Indeed, note from the 4th example that, even with the less powerful toolset (Reals), the variable restrictions permit an answer.
I.e., here, the variable domain restrictions trump the 3rd argument restrictions (and the respective toolsets that result from the latter) (assuming I’ve understood you correctly, that it’s the 3rd argument restriction, and not the individual variable domain restrictions, that determines the toolset).
If I may, here's my best guess at what's going on: When I don't specify a general (3rd argument) domain restriction, the system defaults to Complexes and, for most problems (even those for which the solutions are real or integers), that gives a more powerful tool set than that available when you specify Reals or Integers.
At the same time, if (say) the answers (variable values) are all reals, and you tell Reduce that beforehand, it makes it easier for Reduce to find an answer, since it has to search a smaller space (or, if you prefer, you’ve given it a “hint”). Thus, with my preferred method, you’ve got the best of both worlds: by not specifying a third argument, you have access to the most powerful tools (Complexes), but by individually restricting the variables, you are making Reduce’s job easier.
 
theorist
theorist
1:57 AM
[I.e., my preferred method is not the one with the fewest restrictions. Rather, it's the one that applies the fewest restrictions to the third argument, but the greatest possible restrictions (consistent with the problem) to the individual variables.
 
Michael E2
Michael E2
2:30 AM
@theorist Your assertion "which you describe as using the most powerful tools (Complexes)" seems to contradict mine, "the complexes have advantages over the reals and vice versa." There's hardly a linear ordering....You seem to be thinking about this in the wrong way. E.g. "it has to search a smaller space" -- it doesn't do a search (except after it has isolated a root, or with Integers - SystemOptions["ReduceOptions" -> "ExhaustiveSearchMaxPoints"]).
@theorist Sounds like the one I was referring to: "I’ve always gotten an equal or better result by by applying the domain restriction directly to the variables rather than specifying the domain as the 3rd argument."
@theorist It's not clear what you have in mind. If the problem is Reduce[-0.1547*d + 11.74 == Log[10, a*Exp[-d/c]], {a, c, d}, Complexes], then the other answers are wrong. If the problem, is to solve for reals variables, then over this seems the wrong way to set it up. Note that Reduce[-0.1547*d + 11.74 == Log[10, a*Exp[-d/c]], {a, d, c}, Reals] works but Reduce[-0.1547*d + 11.74 == Log[10, a*Exp[-d/c]] && {a, c, d} \[Element] Reals, {a, c, d}] does not, counter to your preference.
Well, actually I pulled fast one, the same as you did in your examples. ;)
 
 
1 hour later…
theorist
theorist
4:06 AM
@MichaelE2 Sorry if I misunderstood/misrepresented you. I was thinking of your statement that my "preferred method is the one....with fewer restrictions (more tools)". That method has no 3rd argument, which is equivalent to "Complexes", as contrasted with my other example, in which the 3rd argument is Reals. Thus I was taking your statement to mean that specifying Complexes as the 3rd argument [or, equivalently , not specifying anything] gives more tools than Reals.
Though, to be more precise, I should have written "more tools" rather than "more powerful" in characterizing what you said.
I'll need some time to think about what you said about my examples. It wasn't my intention to "pull a fast one"!
 
 
5 hours later…
Szabolcs
Szabolcs
9:25 AM
I am looking for opinions on what would be the best API for a graph-function that can return a number for one or more (or all) graph vertices. See the usage message here for an example.
A naive way (and in fact what I did) is to have fun[graph] return a list of value (each correspond to a vertex, in the same order as VertexList[graph]). fun[graph, {v1, v2, ...}] computes it for selected vertices. And fun[graph, v] computes it for one vertex.
But vertices of graphs can they themselves be lists.
So there is an ambiguity: does f[graph, {1,2}] compute something for two vertices, named 1 and 2? Or a single vertex, named {1,2}?
Perhaps this is just a bad API design and it should not be allowed to pass a single vertex to the function.
Right now I chose the solution that if the second argument is a list, it is always interpreted as a list of vertices. If you want t o request the value for vertex {1,2}, you must use f[graph, {{1,2}}] instead.
Similar problems appear with builtin functions too.
Consider e.g. Extract's second argument. That one is not so difficult though because position specifications can only take certain limited forms. Disambiguation is much easier. Vertex names on the other hand can be any expressions—and list-vertex-names are actually very useful.
Then there are graph-functions affected too:
g = Graph[{1 <-> 2, 2 <-> {1, 2}}, VertexLabels -> "Name"] 
In[54]:= VertexList@Subgraph[g, {1, 2}]
Out[54]= {{1, 2}}
Oops!!
There's no way to disambiguate, and take the subgraph with the two vertices 1 and 2! (If there is, let me know.)
 
Szabolcs
Szabolcs
10:01 AM
And of course Subgraph[g, _Integer] gives a wrong result too ... not surprised about complete unreliability anymore.
 
 
3 hours later…
Jason B.
Jason B.
1:27 PM
@Szabolcs I'm looking into the same issue now - finding the right syntax for querying for vertices of a molecule. One idea is that if you use anything other than an integer or a string as the key for a vertex, then you need to wrap it in Key when querying for it.
 
halirutan
halirutan
@JasonB. There is a similar issue with associations, Query and datasets..
 
Michael E2
Michael E2
2:12 PM
@theorist I didn't really think you were pulling a fast one. At first I didn't notice the change in the ordering of the variables, so I tricked myself. :) The order in effect requests a certain cylindrical algebraic decomposition, which generally means later variables in the list will be solved in terms of earlier ones. Solving for some variables may be more difficult.
 
Michael E2
Michael E2
2:46 PM
Reminds me of the ambiguity with 3 datasets vs. 3 points: ListPlot[{{1, 2}, {3, 6}, {7, 5}}, DataRange -> All]. - I think a list implies a list of vertices is probably the only way other than using a wrapper like Key.
 
Jason B.
Jason B.
2:57 PM
Not finding an exact duplicate for this question, but surely one exists....
 
 
3 hours later…
theorist
theorist
5:41 PM
@MichaelE2 Ah, sorry, I wasn't paying attention to the variable ordering when I created the examples! Thanks for catching that.
 
Szabolcs
Szabolcs
6:21 PM
@JasonB. But in my specific situation, once you have to wrap it, you might as well wrap it with List ... I mean, is it really better to do Lookup[<|{1, 2} -> a, 1 -> b, 2 -> c|>, Key[{1, 2}]] than First@Lookup[<|{1, 2} -> a, 1 -> b, 2 -> c|>, {{1, 2}}]?
But yes: others too have come to the conclusion that graph vertices really need a wrapper. mathematica.stackexchange.com/a/161415/12
 
 
2 hours later…
Edmund
Edmund
8:32 PM
Is there such a thing as a "Run from here" command in a notebook. This would run all code from the currently selected cell to the end of the notebook. Perhaps some hidden front-end token?
 
Jason B.
Jason B.
9:10 PM
@Edmund - doesn't look like a simple task, mathematica.stackexchange.com/q/13909/9490, but still doable
 
 
3 hours later…
Nasser
Nasser
11:45 PM
Wolfram says in his new book the following:

"Is there a way to do interactive step-by-step debugging in the Wolfram Language?

Yes (at least with a native desktop interface)—though it’s rarely used. Given the structure of the Wolfram Language, systematically capturing and analyzing intermediate results is almost always a better approach."
But I have to, with all due respect to the author, disagree with the above. It is rarely used because no one can figure how to use it.

https://www.wolfram.com/language/elementary-introduction/2nd-ed/47-debugging-your-code.html
 

« first day (2189 days earlier)      last day (2296 days later) »