I have a problem using Which. I am making a function in Mathematica where one of the arguments (arg2) is supposed to be a Symbol (either None or Full).
I want the output of the function to be dependent on arg2 like this, but it doesn't work:
testFunction[arg1_,arg2_:None]:=Which[arg2==None,arg1*2,arg2==Full,arg1*3]
If arg2 is None there seems to be no problem, but for arg2 is Full, testFunction just returns itself.
When using reals or integers instead of symbols None and Full, testFunction functions properly.
Am I making a mistake using symbols in the tests? Or are there any other 'rules' I should be aware of when using Which and symbols together?
I already search this and other sites for an answer but couldn't find any. The Mathematica help files didn't provide an answer to me either. Everywhere I looked Which is not used witch symbols.
The solution is to use SameQ (i.e. the operator ===) instead of Equal (the operator ==).
Equal is for Mathematical equality. a==b does not evaluate, meaning Mathematica does not know if these variables have the same value or not. 1==2 evaluates to False while a==a evaluates to True.
SameQ is for structural equality, and will always evaluate either to True or to False. It will only evaluate to True if the expressions being compared are equal structurally. It does not attempt to test mathematical equality, so e.g. 0 === 0.0 will give False as the two expressions are structurally different (one is an exact number, the other a machine precision one).
Here you need structural equality because you need Full === None to evaluate to False (while Full == None stays unevaluated). Just use
testFunction[arg1_,arg2_:None]:=Which[arg2===None,arg1*2,arg2===Full,arg1*3]
While using SameQ is a solution, I think there are better ways to construct this. Switch is the most direct replacement:
f[arg1_, arg2_: None] := Switch[arg2, None, arg1*2, Full, arg1*3]
f[7]
f[7, None]
f[7, Full]
14
14
21
Often it is best to avoid Which/Switch etc. and use patterns, e.g.:
ClearAll[f]
f[arg1_, Full] := arg1*3
f[arg1_, None | PatternSequence[]] := arg1*2
f[7]
f[7, None]
f[7, Full]
14
14
21
Related
I'm on Angular (typescript) but it's more a question of pure algorithm
I have an array that receives conditions (as a string).
example: ['a<b', 'a==b-1',...]
the array receives a new condition: if the new condition doesn't contradict those already contained in the array
so that:
array = []
a==b -> yes ['a==b']
c<b -> yes ['a==b', 'c<b']
c==a -> no ['a==b', 'c<b'] impossible because a==b and c<b
c==a-1 -> yes ['a==b', 'c<b', 'c==a-1']
...
I limit myself to the conditions of equality, superiority, inferiority (strict): ==, >, < to begin and i'll add <=, >= if it's not really more complicated...
I want to do that with just real number but the condition can be like:
'a+2<b+c+n+t', 'a=c+2', 'a=b', 'a=1', 'a<4'...
Actually, I'm still at the guesswork stage without succeeding in finding an obvious angle of resolution.
replace the variables with integers to test the conditions between them ?
I cannot find anything convincing... right now!
I do not realize the level of difficulty of such an algorithm, does this seem simple to you on first reading?
Do you have any solutions, leads?
hat you want is to know if the constraint-satisfaction-problem (CSP) has at least one solution.
https://en.wikipedia.org/wiki/Constraint_satisfaction_problem
There are a vast amount of papers, algorithms and tool out there to solve this.
XPath 2.0 has some new functions and syntax, relative to 1.0, that work with sequences. Some of theset don't really add to what the language could already do in 1.0 (with node sets), but they make it easier to express the desired logic in ways that are more readable. This increases the chances of the programmer getting the code correct -- and keeping it that way. For example,
empty(s) is equivalent to not(s), but its intent is much clearer when you want to test whether a sequence is empty.
Correction: the effective boolean value of a sequence is in general more complicated than that. E.g. empty((0)) != not((0)). This applies to exists(s) vs. s in a boolean context as well. However, there are domains of s where empty(s) is equivalent to not(s), so the two could be used interchangeably within those domains. But this goes to show that the use of empty() can make a non-trivial difference in making code easier to understand.
Similarly, exists(s) is equivalent to boolean(s) that already existed in XPath 1.0 (or just s in a boolean context), but again is much clearer about the intent.
Quantified expressions; e.g. "some $x in expression satisfies test($x)" would be equivalent to boolean(expression[test(.)]) (although the new syntax is more flexible, in that you don't need to worry about losing the context item because you have the variable to refer to it by).
Similarly, "every $x in expression satisfies test($x)" would be equivalent to not(expression[not(test(.))]) but is more readable.
These functions and syntax were evidently added at no small cost, solely to serve the goal of writing XPath that is easier to map to how humans think. This implies, as experienced developers know, that understandable code is significantly superior to code that is difficult to understand.
Given all that ... what would be a clear and readable way to write an XPath test expression that asks
Does value X occur in sequence S?
Some ways to do it: (Note: I used X and S notation here to indicate the value and the sequence, but I don't mean to imply that these subexpressions are element name tests, nor that they are simple expressions. They could be complicated.)
X = S: This would be one of the most unreadable, since it requires the reader to
think about which of X and S are sequences vs. single values
understand general comparisons, which are not obvious from the syntax
However, one advantage of this form is that it allows us to put the topic (X) before the comment ("is a member of S"), which, I think, helps in readability.
See also CMS's good point about readability, when the syntax or names make the "cardinality" of X and S obvious.
index-of(S, X): This one is clear about what's intended as a value and what as a sequence (if you remember the order of arguments to index-of()). But it expresses more than we need to: it asks for the index, when all we really want to know is whether X occurs in S. This is somewhat misleading to the reader. An experienced developer will figure out what's intended, with some effort and with understanding of the context. But the more we rely on context to understand the intent of each line, the more understanding the code becomes a circular (spiral) and potentially Sisyphean task! Also, since index-of() is designed to return a list of all the indexes of occurrences of X, it could be more expensive than necessary: a smart processor, in order to evaluate X = S, wouldn't necessarily have to find all the contents of S, nor enumerate them in order; but for index-of(S, X), correct order would have to be determined, and all contents of S must be compared to X. One other drawback of using index-of() is that it's limited to using eq for comparison; you can't, for example, use it to ask whether a node is identical to any node in a given sequence.
Correction: This form, used as a conditional test, can result in a runtime error: Effective boolean value is not defined for a sequence of two or more items starting with a numeric value. (But at least we won't get wrong boolean values, since index-of() can't return a zero.) If S can have multiple instances of X, this is another good reason to prefer form 3 or 6.
exists(index-of(X, S)): makes the intent clearer, and would help the processor eliminate the performance penalty if the processor is smart enough.
some $m in S satisfies $m eq X: This one is very clear, and matches our intent exactly. It seems long-winded compared to 1, and that in itself can reduce readability. But maybe that's an acceptable price for clarity. Keep in mind that X and S could potentially be complex expressions themselves -- they're not necessarily just variable references. An advantage is that since the eq operator is explicit, you can replace it with is or any other comparison operator.
S[. eq X]: clearer than 1, but shares the semantic drawbacks of 2: it computes all members of S that are equal to X. Actually, this could return a false negative (incorrect effective boolean value), if X is falsy. E.g. (0, 1)[. eq 0] returns 0 which is falsy, even though 0 occurs in (0, 1).
exists(S[. eq X]): Clearer than 1, 2, 3, and 5. Not as clear as 4, but shorter. Avoids the drawbacks of 5 (or at least most of them, depending on the processor smarts).
I'm kind of leaning toward the last one, at this point: exists(S[. eq X])
What about you... As a developer coming to a complex, unfamiliar XSLT or XQuery or other program that uses XPath 2.0, and wanting to figure out what that program is doing, which would you find easiest to read?
Apologies for the long question. Thanks for reading this far.
Edit: I changed = to eq wherever possible in the above discussion, to make it easier to see where a "value comparison" (as opposed to a general comparison) was intended.
For what it's worth, if names or context make clear that X is a singleton, I'm happy to use your first form, X = S -- for example when I want to check an attribute value against a set of possible values:
<xsl:when test="#type = ('A', 'A+', 'A-', 'B+')" />
or
<xsl:when test="#type = $magic-types"/>
If I think there is a risk of confusion, then I like your sixth formulation. The less frequently I have to remember the rules for calculating an effective boolean value, the less frequently I make a mistake with them.
I prefer this one:
count(distinct-values($seq)) eq count(distinct-values(($x, $seq)))
When $x is itself a sequence, this expression implements the (value-based) subset of relation between two sets of values, that are represented as sequences. This implementation of subset of has just linear time complexity -- vs many other ways of expressing this, that have O(N^2)) time complexity.
To summarize, the question whether a single value belongs to a set of values is a special case of the question whether one set of values is a subset of another. If we have a good implementation of the latter, we can simply use it for answering the former.
The functx library has a nice implementation of this function, so you can use
functx:is-node-in-sequence($X, $Y)
(this particular function can be found at http://www.xqueryfunctions.com/xq/functx_is-node-in-sequence.html)
The whole functx library is available for both XQuery (http://www.xqueryfunctions.com/) and XSLT (http://www.xsltfunctions.com/)
Marklogic ships the functx library with their core product; other vendors may also.
Another possibility, when you want to know whether node X occurs in sequence S, is
exists((X) intersect S)
I think that's pretty readable, and concise. But it only works when X and the values in S are nodes; if you try to ask
exists(('bob') intersect ('alice', 'bob'))
you'll get a runtime error.
In the program I'm working on now, I need to compare strings, so this isn't an option.
As Dimitri notes, the occurrence of a node in a sequence is a question of identity, not of value comparison.
I have a huge set (20000) of boolean expressions. They consist of AND, OR and NOT operators and a large number of boolean variables A1, A2, A3 ... (about 1000). Most expression contain only 5, maybe 20 of these variables.
Given an assignment of the variables (A1 = true, A2 = false, A3 = false ...) I have to find those expressions that evaluate to false.
The same set of expressions will be evaluated for multiple (10-100) assignments
For this purpose:
How should I store the expressions on disk so I can load and parse them fast (I currently have them either as some specialized DSL or as a more or less normalized (and dead slow) relational data structure, but I can change that)
Is there a fast algorithm / data structure for evaluating such expressions that I can use?
Do implementations on the JVM exist?
You may want to look at converting your expressions into Conjunctive Normal Form and combining like terms. You then can have a two-way mapping of an expression to a set of terms, any of which evaluating to false implies that the whole expression evaluates false. For each assignment of variables, start with a set of expressions, evaluate CNF terms until one evaluates to false. If that term is false, then all expressions involving that term will also be false, so those expressions can also be removed from the set.
Whether such an approach fits your case can't be said without looking at the expressions - with 1000 variables and 20000 expressions, it might not be that they have many CNF terms in common.
Outside of Java, and for much larger numbers of expressions, DNF is possibly more useful, since its implementation on the GPU is obvious.
The SOP answer to this is to store the expressions as strings in RPN (Reverse Polish Notation) and then write a simple Stack Machine parser to evaluate them.
Generally, an RPN string can be evaluated almost as fast as an already in-memory AST (Abstract Symbol Tree). And the stack machine parser is dead easy to write.
You seem attached to Java, but have you considered feeding these things to a language that has an eval() function? It would probably reduce the problem to saving an expression in a file and evaluating it. Note that if you don't trust the (source of the) expressions, this has security implications!
Jython comes to mind, but there are probably several that would make very short work of this.
If you're married to java, you could probably implement a recursive descent parser for boolean algebra. But that's quite a bit more involved.
UPDATE: The following site has code that might help.
Convert your list of expressions into source code for a function that when called with the value of the variables will evaluate all the functions and return an indication of which expressions evaluate to false. compile the function then call it for your different variable values.
I have done similar and used Python. The only parsing and interpretation I had to write was to translate the input boolean operators, '&', '|', '~' into their Python equivalents.
Your problem size seems quite OK for a Python solution.
You could build an index where for each variable you record two sets of expressions, those where the variable occurs positively and those where it occurs negatively. Depending on the values of the variables you collect those expressions which could become false due to this variable (positive occurrences if the variables is set to false and vice versa). Edit: These are just candidates, you still need to evaluate them to find out if they really become false.
Whether this helps compared to just evaluating all your expressions depends on the structure of your expressions and how many evaluate to false.
Try to convert them into CNF and use MiniSat to check whether the expression evaluates to true or false
I want to assign values to variables (like c for speed of light or G for gravitational constant) but have formulas calculated symbolically until last step.
How is it possible to do this in shortest way?
Replace is very long and duplicating while HoldForm can require multiple RealeaseHold if nested.
Is there some other functions for this?
We can define N values for our constants. For example:
N[c] = 299792458;
This defines a numerical value for c. We can define a function that uses the constant:
f[v_] := Sqrt[1-v^2/c^2]
When we evaluate this function normally, it leaves c in symbolic form:
In[11]:= f[200000000]
Out[11]= Sqrt[1 - 40000000000000000/c^2]
But if we apply N, then c gets evaluated numerically:
In[12]:= f[200000000] // N
Out[12]= 0.744943
an example will help. But if I understood you, then you have
expr=9 c + 10 gravity
then you can write
expr /. {c -> 299792458, gravity -> 9.8}
to evaluate the symbolic expression with new values for the symbols involved.
The expression can remain symbolic all the time, and you can simply evaluates it for different values for the symbols in it.
I think this question has two parts.
(1) Whether we should force Mathematica to do all calculations symbolically. This is (almost always) wrong. Mathematica can do arbitrary precision numerics, so we should prefer to tell it the precision of our physical constants (when they exceed $MachinePrecision) and let it choose the most efficient way to solve the problem.
(2) How do we print intermediate steps in symbolic form. For this, use HoldForm[expr], and then
expr //. HoldForm[x_]:>ReleaseHold[HoldForm[x]]
should give you the evaluation results as you indicate.
Regarding a "ReleaseHoldAll" function, MapAll (short form //#) maps a function to all parts of an expression. Therefore, you can use:
ReleaseHold //# expr
where expr is your expression containing Hold, HoldForm, etc., at any level.
There are strange attributes to using the replacement operator in mathematica sometimes. This has to do with the context in which you apply it. The above answer will probably work well, but personally I always use Block[{variable=number}, code] command, which makes the variables act as global within the Block brackets, but once the evaluation proceeded outside, the variables remain undeclared.
use it like this:
Block[{c = 299792458, gravity = 9.0 }, answer = 9 c + 10 gravity ]
gives output:
2.69813*10^9
and also sets answer globally to the value of the output so you can use it after :
answer/2
results in:
1.34907*10^9
I recently rediscovered a small package by Roman Maeder that tells Mathematica to automatically thread arithmetic and similar functions over expressions such as x == y. Link to Maeder's package.
First, to demonstrate, here's an example given by Maeder:
In[1]:= Needs["EqualThread`"]
Now proceed to use the threading behavior to solve the following equation for x 'by hand':
In[7]:= a == b Log[2 x]
In[8]:= %/b
Out[8]:= a/b == Log[2 x]
Now exponentiate:
In[9]:= Exp[%]
Out[9]= E^(a/b) == 2 x
And divide through by 2:
In[10]:= %/2
Out[10]= (E^(a/b))/2 == x
Q: From a design perspective, can someone explain why Mathematica is set to behave this way by default? Automatically threading seems like the type of behavior a Mathematica beginner would expect---to me, at least---perhaps someone can offer an example or two that would cause problems with the system as a whole. (And feel free to point out any mathematica ignorance...)
Seems natural when thinking of arithmetic operations. But that is not always the case.
When I write
Boole[a==b]
I don't want
Boole[a] == Boole[b]
And that is what Maeder's package does.
Edit
Answering your comment below:
I noticed that Boole[] was added in v.5.2, whereas Maeder's package was authored for v.3. I guess the core of my question still revolves around the 'design' issue. I mean, how would one get around the issue you pointed out? To me, the clearest path would be declaring something about variables you're working with, no? -- What puzzles me is the way you can generally only do this with Assumptions (globally or as an option to Simplify, etc). Anyone else think it would be more natural to have a full set of numerical Attributes? (in this regard, the Constant Attribute is a tease)
My answer is by no means a critic to Maeder's package, which is nice, but a statement that it should not be the mainstream way to treat Equal[ ] in Mma.
Equal[ ] is a function, and not particularly easy to grasp at first:
returns True if lhs and rhs are identical
returns False if lhs and rhs are determined to be unequal by comparisons between numbers or other raw data, such as strings.
remains unevaluated when lhs or rhs contains objects such as Indeterminate and Overflow.
is used to represent a symbolic equation, to be manipulated using functions like Solve.
The intent of Maeder's package, which I understand is well aligned with yours, is to give to the expression lhs == rhs the same meaning and manipulation rules humans use when doing math.
In math, equality is an equivalence relation, imposing a partial order in a set, and an equation is an assertion that the expressions are related by this particular relation.
Compare these differences with other Mma "functions". Sin[x] is in Mma, and in usual math the same thing (well, almost), and the same can be said of most Mma beasts. There are a few Mma constructs, however, that do not hold that exact isomorphism to math concepts: Equal, SameQ, Equivalent, etc. They are the bridge from the math world to the programming world. They are not strict math concepts, but modified programming concepts to hold them.
Sorry if I got a little on the philosophical side.
HTH!
I guess it is partly because the behavior can not be extended over to inequalities. And also because the behavior should make sense both when equalities become evaluated:
Would be nice:
In[85]:= Thread[Power[a == b, 2], Equal]
Out[85]= a^2 == b^2
In[86]:= Thread[Power[a == b, c == d], Equal]
Out[86]= a^c == b^d
but:
In[87]:= Thread[Power[a == b, c == d] /. {c -> 2, d -> 2}, Equal]
Out[87]= a^True == b^True