I have a matrix addition with several terms that I want to display in a Jupyter Notebook. I need the order of terms to match the standard notation - in my case, of linear regression. But, the terms do not, by default, appear in the correct order for my purpose, and I would like to ask how to control the order of display of matrices in a matrix addition (MatAdd) term in Sympy. For example, here we see that Sympy selects a particular order for the terms, that appears to be based on the values in the Matrix.
from sympy import MatAdd, Matrix
A = Matrix([1])
B = Matrix([0])
print(MatAdd(A, B, evaluate=False))
This gives
Matrix([[0]]) + Matrix([[1]])
Notice the matrix terms do not follow the order of defintion or the variable names.
Is there anything I can do to control the print output order of Matrix terms in a MatAdd expression?
You can use init_printing to chose from a few options. In particular, the order keyword should control how things are shown on the screen vs how things are stored in SymPy objects.
Now comes the differences: by setting init_printing(order="none") printers behave differently. I believe this is some bug.
For example, I usually use Latex rendering when using Jupyter Notebook:
from sympy import MatAdd, Matrix, init_printing
init_printing(order="none")
A = Matrix([1])
B = Matrix([0])
add = MatAdd(A, B, evaluate=False)
print(add)
# out: Matrix([[0]]) + Matrix([[1]])
display(add)
# out: [1] + [0]
Here you can see that the latex printer is displaying the elements as they are stored (check add.args), whereas the string printer is not following that convention...
Related
Hi I was working on a model for oscilation problems with Lagrangian mechanichs for my Classical Mechanics I course.
My problem is the following:
When I try to Simplify some expressions like the one in the image below, sympy just shows the division and doesn´t reduce the expression.
I was wondering whether this is some kind of limitation of SymPy (probably that´s not the case) or is just me missing something.
enter image description here
If SymPy doesn't know enough about the variables (like whether they are positive or zero) then it doesn't make a simplification. For sqrt you will get better results if you indicate that the variables are positive. Alternatively, you can use posify on the expression before attempting the simplification.
>>> from sympy import symbols
>>> x,y = symbols('x y', positive=True)
>>> sqrt(x/y)/sqrt(y/x)
x/y
This would not be true if x were positive and y were negative (in which case the answer would be -x/y)
I have noticed that my gensim Doc2Vec (DBOW) model is sensitive to document tags. My understanding was that these tags are cosmetic and so they should not influence the learned embeddings. Am I misunderstanding something? Here is a minimal example:
from gensim.test.utils import common_texts
from gensim.models.doc2vec import Doc2Vec, TaggedDocument
import numpy as np
import os
os.environ['PYTHONHASHSEED'] = '0'
reps = []
for a in [0,500]:
documents = [TaggedDocument(doc, [i + a])
for i, doc in enumerate(common_texts)]
model = Doc2Vec(documents, vector_size=100, window=2, min_count=0,
workers=1, epochs=10, dm=0, seed=0)
reps.append(np.array([model.docvecs[k] for k in range(len(common_texts))])
reps[0].sum() == reps[1].sum()
This last line returns False. I am working with gensim 3.8.3 and Python 3.5.2. More generally, is there any role that the values of the tags play (assuming they are unique)? I ask because I have found that using different tags for documents in a classification task leads to widely varying performance.
Thanks in advance.
First & foremost, your test isn't even comparing vectors corresponding to the same texts!
In run #1, the vector for the 1st text in in model.docvecs[0]. In run #2, the vector for the 1st text is in model.docvecs[1].
And, in run #2, the vector at model.docvecs[0] is just a randomly-initialized, but never-trained, vector - because none of the training texts had a document tag of (int) 0. (If using pure ints as the doc-tags, Doc2Vec uses them as literal indexes - potentially leaving any unused slots less than your highest tag allocated-and-initialized, but never-trained.)
Since common_texts only has 11 entries, by the time you reach run #12, all the vectors in your reps array of the first 11 vectors are garbage uncorrelated with any of your texts/
However, even after correcting that:
As explained in the Gensim FAQ answer #11, determinism in this algorithm shouldn't generally be expected, given many sources of potential randomness, and the fuzzy/approximate nature of the whole approach. If you're relying on it, or testing for it, you're probably making some unwarranted assumptions.
In general, tests of these algorithms should be evaluating "roughly equivalent usefulness in comparative uses" rather than "identical (or even similar) specific vectors". For example, a test whether apple and orange are roughly at the same positions in each others' nearest-neighbor rankings makes more sense than checking their (somewhat arbitrary) exact vector positions or even cosine-similarity.
Additionally:
tiny toy datasets like common_texts won't show the algorithm's usual behavior/benefits
PYTHONHASHSEED is only consulted by the Python interpreter at startup; setting it from Python can't have any effect. But also, the kind of indeterminism it introduces only comes up with separate interpreter launches: a tight loop within a single interpreter run like this wouldn't be affected by that in any case.
Have you checked the magnitude of the differences?
Just running:
delta = reps[0].sum() - reps[1].sum()
for the aggregate differences results with -1.2598932e-05 when I run it.
Comparison dimension-wise:
eps = 10**-4
over = (np.abs(diff) <= eps).all()
Returns True on a vast majority of the runs which means that you are getting quite reproducible results given the complexity of the calculations.
I would blame numerical stability of the calculations or uncontrolled randomness. Even though you do try to control the random seed, there is a different random seed in NumPy and different in random standard library so you are not controlling for all of the sources of randomness. This can also have an influence on the results but I did not check the actual implementation in gensim and it's dependencies.
Change
import os
os.environ['PYTHONHASHSEED'] = '0'
to
import os
import sys
hashseed = os.getenv('PYTHONHASHSEED')
if not hashseed:
os.environ['PYTHONHASHSEED'] = '0'
os.execv(sys.executable, [sys.executable] + sys.argv)
I am a complete noob in Julia and its syntax. I am trying to follow this article on semi-definite-programming on Julia.
I would apprecieate if someone can help me figure out what the for loop in In[4] actually does:
for i in 1:m
A[:, (i-1)*n+1:i*n] .= random_mat_create(n)
b[i] = tr(A[:, (i-1)*n+1:i*n]*X_test)
end
To my understanding it should create a vector of matrices A (m of those) as well as an m-dimensional vector b. I am totally confused though on the indexing of A and the indexing of b.
I would like an explanation of the :, (i-1)*n+1:i*n part of this code. The reason I ask here is because I also dont know what to Google or what to search for in Julia documentation.
(i-1)*n+1:i*n creates a range from (i-1)*n + 1 to i*n. For example, if i=2 and n=10, this range becomes 11:20, so A[:, (i-1)*n+1:i*n] will grab all the rows of A (that's what : does), and columns 11-20.
There are two operations there that are not clear to you:
: operator. Consider a Matrix a = zeros(3,3). You could use array slicing operator (similarly to numpy or Matlab) to select the entire second columns as: a[1:end,2]. However, when selecting everything from start to the end those two values can be omitted and hence you can write a[:,2] (this always looked the easiest way for me to remember that)
. (dot) operator. Julia is very careful about what gets vectorized and what not. In numpy or R, vectorizing operations happens kind of always automatically. In Julia you have the control - but with the control comes the responsibility. Hence trying to assign values to the second column by writing a[:, 2] = 5.0 will throw an error because there is vector on the right and a scalar on the left. If you want to vectorize you need to tell that to Julia. Hence the dot operator .= means "perform element-wise assignment". Note that any Julia function or operator, even your own functions can be decorated by such dot .. Since this is a very important language feature have a look at https://docs.julialang.org/en/v1/manual/arrays/#Broadcasting
I'm newer to Mathematica language, and I'm having a big issue in graphing a set of points. It goes as follows:
f[w_] = expr.1
calculations = Table[expr.1, {w,0,numtimes}]
omegas = Table[i,{i,0,numtimes}]
orderedpairs = Transpose[{calculations,omegas}]
ListPlot[orderedpairs]
This returns a graph with just one point rather than numtimes amount of points, and it doesn't match the first point in the dataset. I've tried a listplot command for the two lists seperately, like
Listplot[{orderedpairs[[i]],omegas[[i]]},{i,0,numtimes}]
but i get an error that says "the expression i cannot be used as a part specification."
The data set is in the form x+iy, where x and y are real numbers. If I could get some help, I would appreciate it greatly.
Plot the real by itself
ListPlot[Re[orderedpairs]]
I am trying to better understand this syntax in Lua when using Torch:
local ten = torch.Tensor{{1,2,3},{4,5,6},{7,8,9}}
for i=1,(#ten)[2] do
print(ten[i][{{2}}])
end
Specifically the line
print(ten[i][{{2}}])
When I run the code, it prints
2
[torch.DoubleTensor of size 1]
5
[torch.DoubleTensor of size 1]
8
[torch.DoubleTensor of size 1]
I am familiar with table literals and their basic syntax, but what is the purpose of wrapping the '2' in double curly-braces, and how does it work in the engine?
The following answer was posted on GitHub when I asked the same question:
https://github.com/torch/torch7/issues/501#issuecomment-171290546
Have a look at this part of the documentation.
When you have single curly-braces, you are creating a selection of the tensor. So ten[{1}] is equivalent to ten[1], which is in turn equivalent to ten:select(1,1). If you have several indices like ten[{1,2}], this is also equivalent to the slower ten[1][2] (because the latter returns 2 times a tensor, whereas the former only returns it once). If you select on a 1D tensor, your output is a number.
When you have double curly-braces, it returns a narrow of the tensor, and a narrowed tensor is always a tensor (even if it only has one element). With double curly-braces, you can specify a range in which the tensor will be narrowed, which is not possible with single curly-braces. For example, you can do ten[{{1,2},1}], which will be a 1D tensor of dimension 2, and if your do ten[{{1,2},{2}}] it will return a 2D tensor of size 2x1.
For more information, have a look at select and narrow.
One last note, the doc for select is not precisely correct, as it's possible to do a select on a 1D tensor, and the output is a number.