Differences between "Equal" and "SameQ"

There are different ways of comparing two elements or more, the first one is less strict: using Equal (==); the second one, is more strict: using SameQ (===).

Let's take a look at the documentation page for Equal:

And now, the documentation page for SameQ...

This alone doesn't tell much, but how exactly these two operators (== and ===) are different? The difference lies in their individual strictness.

If you want to compare numbers AND their types, use SameQ, if you want less strict comparisons, use Equal.

Sometimes, Equal outputs a symbolic equation, and that can be bad sometimes, if you want to ALWAYS output a boolean value, use SameQ.

WARNING: SameQ has a higher precedence as an operator. If you want to replace values, replace the values while holding the operation.

If i would get a euro for every time I see horrible/bad approach…

Properties & Relations of constraining a locator

Since the example of constraining a (interactive, or, editable) point or locator to the edge of the unit circle appears over and over again in different yet similar teaching contexts, it can become confusing for the beginner to discern all the coding variations by heart and know which one to use in a given active coding situation. In order to constrain a locator (or point or plot tracker/tracer or alike) key functions can be Locator, LocatorPane, Dynamic, DynamicModule, Manipulate, TrackingFunction, Slider2D, but not all of them at the same time. It depends on what you want and what you start with.

In the end it all boils down to the exploitation of the optional 2nd argument of Dynamic which must be a function (or a list of functions); typically the function is a pure function func[val, expr] processing the "mouse position" (val) and the dynamic expression expr (usually just a single dynamic variable u).

The attached short notebook tries to give a helpful overview of all seven (common) variations for reference and easy comparison.

Also check out the Monday morning quiz testing your beginner's Wolfram L vocabulary!

Attachments:

exampleConstrain...nb

Numerical vs Symbolic -- What to do when plots are blank (and other strange errors)

The plotting functions require numerical inputs. This sounds obvious but most people have trouble debugging plots that come out empty. When something does not plot, the first thing to do is to evaluate the expression and look for undefined variables or typos.

Consider the following:

A = 12;
b = 3;
expr = a* b sin[theta];
Plot[expr, {theta, 0, 10}]

which yields a less than informative plot:

The best approach is to take the plot argument and evaluate it at a point somewhere in the plot range and see that it is numerical. It is often a good idea to evaluate it at the two extremes and the middle to make sure it is numerical everywhere.

expr /. theta -> 0
expr /. theta -> 5
expr /. theta -> 10

to get

 (* 3 a sin[0] 
3 a sin[5] 
3 a sin[10] *)

It becomes clear that the a is undefined and that sin does not evaluate (because of the lower case 's')

Consider Reap/Sow Instead of AppendTo

When using the output of a program to build large lists, a combination of Reap and Sow is often cited as the most efficient (computationally speaking) approach. Put simply, AppendTo trades speed in favour of flexibility by creating a copy of the original list when called. Indeed, Reap/Sow is also point 7 of 10 Tips For Writing Fast Mathematica Code.

I remember first seeing Reap/Sow as a beginner and feeling like it was an 'advanced' feature for other users. Instead I fell into the pattern of defining an empty list and using AppendTo which in hindsight was a beginner's mistake I frequently made by the justification given above.

The example from the link above says it best:

In[7]:= data = {}; 
 Do[AppendTo[data, RandomReal[x]], {x, 0, 40000}]; // AbsoluteTiming

Out[7]= {11.6127, Null}

In[8]:= data = 
   Reap[Do[Sow[RandomReal[x]], {x, 0, 40000}]][[2]]; // AbsoluteTiming

Out[8]= {0.164533, Null}

This is one small change which will Reap large benefits for any beginner.

Thanks, had added a previous version of ApplyTo, now fixed, and also added [Application]. (https://reference.wolfram.com/language/ref/Application.html)

Also added this explicitly. thanks!

Not sure how you are entering the left and right floor brackets but that is the problem,

\[LeftFloor]5.5\[RightFloor]
(* 5 *)

To enter from the keyboard esclfesc and escrfesc where esc is escape.

Sorting numerical data and the behavior of Sort

Mathematica has various ways of sorting data. Most commonly one wants to sort numbers. The command Sort can be used to do so:

Sort[{4, 2, 8, 1}]

returns:

{1, 2, 4, 8}

all very well. However, if one has symbolic answers, Sort might not do what you expect:

data3 = Sin[Range[10]]
data3 // N
Sort[data3]

gives:

{Sin[1],Sin[2],Sin[3],Sin[4],Sin[5]}
{0.841471,0.909297,0.14112,-0.756802,-0.958924}
{Sin[1],Sin[2],Sin[3],Sin[4],Sin[5]}

It looks like if Sort did not do anything! What is happening here? Well, Sort puts things in canonical order and decides whether they are ordered correctly using the default function Order (which works basically the same as OrderedQ):

OrderedQ[1,2]  (* True, they are ordered *)
OrderedQ[2,1]  (* False; they are not ordered *)
OrderedQ[Sin[2], Sin[3]]    (* True, they are ordered! *)

That might be a bit unexpected. Sort will only look at the structure, and then 2 comes before 3. If we want to explicitly sort by numerical value (rather than canonical order) one needs to specify this:

data3 = Sin[Range[5]]
data3 // N
Sort[data3, Less]  (* prior to V11.1 *)
N[%]
Sort[data3, NumericalOrder]   (* V11.1 and up *)
N[%]

One can do this in the above two ways (using NumericalOrder rather than Order) or using the function Less which will evaluate the number numerically and then compare them. Since Version 11.1 there is also a new function called NumericalSort which just does that:

data3 = Sin[Range[5]]
data3 // N
NumericalSort[data3]
N[%]

Now that we know why Sort sometimes gives unexpected results, and that we have found alternate ordering functions, we find that this is generally not fast.

data = RandomReal[1, 10^6];
AbsoluteTiming[Sort[data, Less];]

It takes several seconds (5.3 seconds on my laptop) to sort a million numbers! Ok, what's going on here? The problem is that Sort with a second argument does pair-wise comparisons, such that the algorithm scales very poorly. If the problem can be re-stated such that each element in a list gets a numerical value which can be sorted using the default ordering function (Order), then this is much faster. We can then improve the performance considerably by using SortBy and a second argument:

AbsoluteTiming[SortBy[data, N];]

or equivalently in this case (we already have approximate numbers so N is not necessary):

AbsoluteTiming[SortBy[data, Identity];]

which only takes 0.17 seconds on my laptop. Since we have approximate numbers, Sort itself works correctly and is fast as well:

AbsoluteTiming[Sort[data];]

Takes 0.16 seconds on my laptop.

Summary

• If one only has pure numbers (1337, 1.337 et cetera) use Sort (or from version 11.1 on use NumericalSort).

• If one has numbers but in some kind of symbolic form (Sin[3], Sqrt[5], Pi, E, Exp[2], 10 Degree, Quantity[Sqrt[..],...] or ...) use NumericalSort (or SortBy[... , N] for versions prior to 11.1).

• If your problem is not one of those, then check if the problem can be recast in one where a single function gives a 'value' to each element that then can be sorted efficiently, if that is possible use SortBy with the correct second argument

Compare the following two examples:

SortBy[{"abc","ab","e","cd","efg"},StringLength]
Sort[{"abc","ab","e","cd","efg"},StringLength[#1]<=StringLength[#2]&]

Give the same result but the first one is generally much faster.

• If such a rephrasing of the problem is not possible use the general Sort with appropriate ordering function.

Final words

Much more can be said about Sort (like the ordering of Sort for a mix of strings, symbols, and numbers). Feel free to comment on this post for additional things to consider when sorting...

Basic syntax of built-in functions

• All built-in functions start from capital letters and are in CamelCase for compound names. Users of many other programming languages might miss this as they are used to different conventions. Examples: Plot, ListPlot, FindSpanningTree, etc.

• Arguments of a function are inclosed in square brackets. Round parenthesis are used only for ordering of operations. Again, other languages use different conventions. Examples:

  • Cos[Pi] --- is a function with a single argument Pi.
  • BesselJ[1/2, 5] --- is a function with 2 arguments
  • (2-Cos[Pi])Sin[Pi/3] --- round parenthesis are used to order operations