update:
I've isolated the issue of why the legend() wasn't working. The question regarding that:
Does `legend ( )` require implicit variables which get lost in different scope
I am trying to call a variable in the format ";displayname;" property for a legend in plot 15.2.1 2-D plots, but I can't find any documentation regarding it.
I can't get the legend() to work probably due to the way my actual code is structured. And I am unable to debug as the Octave GUI is not working on my pc & I don't know how to debug on the Octave CLI.
so, defining legend within the plot() somehow is the only resort as it seems to me.
Isolated test codes:
cur = char ( ["hi";"he";"le"] )
% Legend works in isolation, but not in my actual program
loglog ( 3*[1:10].^3 )
legend ( cur(1,:) )
% Tries:
% Prints verbatim
loglog ( 3*[1:10].^3, ";cur(1,:);" )
% Throws syntax error
loglog ( 3*[1:10].^3, ";"cur(1,:)";" )
% Throws error "__plt2vv__: vector lengths must match"
loglog ( 3*[1:10].^3, (";" + cur(1,:) + ";") )
The second & third tries were based on this post on MATLAB central
You can use sprintf() to explicitly build strings. Use %s to denote a string variable to add: sprintf(";%s;", cur(1, :)).
Using array concatenation you could do [";", cur(1, :), ";"]. Octave doesn't do string concatenation using the + operator as far as I know.
Related
In fortran, we can simply use & to do line continuation.
But I wonder, in Julia, is there a safe way to do line continuation?
I heard that sometimes Julia cannot identify line continuation and it can cause bugs? Because after, Julia does not seem to have any symbol to do line continuation. Can Julia correctly recognize the line continuation?
Like I define the below function with long arguments,
function mean_covar_init(kmix::Int64,dim_p::Int64,weight::Array{Float64,1},sigma::Array{Float64,2},mu::Array{Float64,2})
return nothing
end
If I do things like
function mean_covar_init(kmix::Int64
,dim_p::Int64
,weight::Array{Float64,1}
,sigma::Array{Float64,2}
,mu::Array{Float64,2})
return nothing
end
Is it safe? Thank you very much!
If you do the thing like you have presented it is safe because Julia sees ( in the first line of code so it will look for a closing ).
However a problematic code would be:
f() = 1
+ 2
The reason is that the f() = 1 part is a valid and complete function definition. Therefore you need to make sure to signal Julia that the line is incomplete. The three most typical ways to do it are:
Move the + to the end of first line:
f() = 1 +
2
Use ( and ) as a wrapper:
f() = (1
+ 2)
Use begin and end:
f() = begin 1
+ 2 end
Let me give another example with macros, which do not require parenthesis or punctuation and therefore can be often tricky. Therefore the following:
#assert isodd(4) "What even are numbers?"
if rewritten as
#assert isodd(4)
"What even are numbers?"
does not produce what you expect, and you need to do e.g.:
#assert(isodd(4),
"What even are numbers?")
We have a UI for users to put down LaTex responses. To evaluate those responses, we translate LaTex to R, then run some script similar to the following to compare the response to the correct answer.
x = #{random number}
y = #{random number}
abs(x*x*y - x^2*y) < 10^-6
It's working fine for those functions mapped well. For example:
\frac{x}{y} => x/y
\left|x\right| => abs(x)
{\cdot} => *
But I didn't find any match for the following functions/notations:
\hat{x} -- unit vector
\vec{x} -- vector
\sqrt[3]{x} -- nth root
Any suggestions?
PS:
There is a hat function in R, but I'm not sure if it's the same as the one in LaTex.
Also, \sqrt[3]{x} can be replaced by x^(1/3). Will this be always working? Any performance concern? Someone's saying x^(1/2) is slower than sqrt(x).
I am trying to display both sides of a vector equation.
I am able to display() the rhs of the equation but I am unable to define an equality sympy.Eq(symbols("F_T"), F_Tx*N.x + F_Ty*N.y + F_Tz*N.z) using vectors. Ideally I would like F_T to its own symbol (for use in other equations) but creating a vector modifies the type() from "symbol" to "Vector".
Therefore I am unable to print the desired full equation (like a textbook might). I am open to printing in LaTeX but I am uncertain how to combine my sympy expressions with created LaTeX. Any help is appreciated, Thanks!
I would like to be able to pretty-print: F_T = F_Tx*N.x + F_Ty*N.y + F_Tz*N.z
I've been wondering about how to do the same thing. The following tips are not a perfect solution, but they may prove useful to someone.
def create_vector(sym, refFrame):
unit_vectors = refFrame.base_vectors()
syms = sp.symbols(' '.join([sym + '_{' + str(ax) + '}' for ax in unit_vectors]))
vector = reduce(add, [sym * unit for sym, unit in zip(syms, unit_vectors)])
return (vector,) + syms
This function allows you to quickly create a vector with unresolved symbolic components, like so:
XYZ = CoordSys3D('XYZ', vector_names=('I', 'J', 'K'))
r_rel, r_rel_i, r_rel_j, r_Rel_k = create_vector('\mathbf{r_{rel}}', XYZ)
r_rel
Now, if you try to render this in Jupyter, you get the ugly component representation:
But, if you are prepared to be a bit hacky, you can work around this. The Zero vector stores it's own latex representation internally, as self._latex_form. The sympy latex
printer determines if a vector is the zero vector by checking if expr == expr.zero.
We can abuse these and trick the latex printer into printing a nicer representation:
r_rel.zero = r_rel
r_rel._latex_form = '\mathbf{r_{rel}}'
r_rel
For which we get this prettier representation:
Admittedly, this could break things, and it will make you feel dirty. But it may help someone.
Try creating an equality to display: eq = Eq(F_T, F_Tx*N.x ...). An equality is printed with an equals sign separating the lhs and rhs of the equality.
I am playing around with the idea of CoVectors in Julia and am getting some behaviour I didn't expect from the parser/compiler. I have defined a new CoVector type that is the ctranspose of any vector, and is just a simple decoration:
type CoVector{T<:AbstractVector}
v::T
end
They can be created (and uncreated) with ' using ctranspose:
import Base.ctranspose
function CoVector(T::DataType,d::Integer=0)
return CoVector(Array(T,d))
end
function Base.ctranspose(cv::CoVector)
return cv.v
end
function Base.ctranspose(v::AbstractVector)
return CoVector(v)
end
function Base.ctranspose(v::Vector) # this is already specialized in Base
return CoVector(v)
end
Next I want to define a simple dot product
function *(x::CoVector,y::AbstractVector)
return dot(x.v,y)
end
Which can work fine for:
v = [1,2,3]
cv = v'
cv*v
returns 14, and cv is a CoVector. But if I do
(v') * v
I get something different! In this case it is a single element array containing 14. How come parenthesis doesn't work how I expect?
In the end we see the expression gets expanded to Ac_mul_B which defaults to [dot(A,B)] and it seems that this interpretation is defined at the "operator" level.
Is this expected behaviour? Can Julia completely ignore my bracketing and change the expression as it wants? In Julia I like that I can override things in Base but is it also possible to make self-consistent changes to how operators are applied? I see the expression doesn't have head call but Symbol call... does this change in Julia 0.4? (I read somewhere that call is becoming more universal).
I guess I can fix the problem by redefining Ac_mul_B but I was very surprised that it was called at all, given my above definitions.
The manual states:
The operator ‘<-’ can be used anywhere,
whereas the operator ‘=’ is only allowed at the top level (e.g.,
in the complete expression typed at the command prompt) or as one
of the subexpressions in a braced list of expressions.
The question here mention the difference when used in the function call. But in the function definition, it seems to work normally:
a = function ()
{
b = 2
x <- 3
y <<- 4
}
a()
# (b and x are undefined here)
So why the manual mentions that the operator ‘=’ is only allowed at the top level??
There is nothing about it in the language definition (there is no = operator listed, what a shame!)
The text you quote says at the top level OR in a braced list of subexpressions. You are using it in a braced list of subexpressions. Which is allowed.
You have to go to great lengths to find an expression which is neither toplevel nor within braces. Here is one. You sometimes want to wrap an assignment inside a try block: try( x <- f() ) is fine, but try( x = f(x) ) is not -- you need to either change the assignment operator or add braces.
Expressions not at the top level include usage in control structures like if. For example, the following programming error is illegal.
> if(x = 0) 1 else x
Error: syntax error
As mentioned here: https://stackoverflow.com/a/4831793/210673
Also see http://developer.r-project.org/equalAssign.html
Other than some examples such as system.time as others have shown where <- and = have different results, the main difference is more philisophical. Larry Wall, the creater of Perl, said something along the lines of "similar things should look similar, different things should look different", I have found it interesting in different languages to see what things are considered "similar" and which are considered "different". Now for R assignment let's compare 2 commands:
myfun( a <- 1:10 )
myfun( a = 1:10 )
Some would argue that in both cases we are assigning 1:10 to a so what we are doing is similar.
The other argument is that in the first call we are assigning to a variable a that is in the same environment from which myfun is being called and in the second call we are assigning to a variable a that is in the environment created when the function is called and is local to the function and those two a variables are different.
So which to use depends on whether you consider the assignments "similar" or "different".
Personally, I prefer <-, but I don't think it is worth fighting a holy war over.