Why does Sage not solve this system of (linear) equations, but then it does after some manual substitutions? - sage

I have a system of equations in which there are two unknowns. Originally (the system is derived from the analysis of an electrical circuit) I have four equations with four unknowns, but two of them (irc1 and ire) are linear combinations of the "real" unknowns (ib1 and ib2). All the other variables are treated as parameters of the circuit and its devices. When I try to solve the full set of four equations, Sage does not give an answer. This:
ib1, ib2, ire, irc1, rfb, re, vcc, veb1, veb2, rc1, b1, b2 = var('ib1 ib2 ire irc1 rfb re vcc veb1 veb2 rc1 b1 b2')
solve([ veb1 == -ib1*rfb + ire*re,
vcc == ire*re + veb2 + rc1*irc1,
irc1 == b1*ib1 + ib2,
ire == (b2+1)*ib2 - ib1
], ib1, ib2)
Yields:
[]
But if I manually substitute the last two equations into the first ones:
ib1, ib2, rfb, re, vcc, veb1, veb2, rc1, b1, b2 = var('ib1 ib2 rfb re vcc veb1 veb2 rc1 b1 b2')
solve([ veb1 == -ib1*rfb + ((b2+1)*ib2 - ib1)*re,
vcc == ((b2+1)*ib2 - ib1)*re + veb2 + rc1*(b1*ib1 + ib2)
], ib1, ib2)
Then it does output the answer I am looking for:
[[ib1 == ((b2*(vcc - veb2) + vcc - veb2)*re - ((b2 + 1)*re + rc1)*veb1)/((b1*b2*rc1 + (b1 + 1)*rc1)*re + ((b2 + 1)*re + rc1)*rfb), ib2 == (re*(vcc - veb2) + rfb*(vcc - veb2) + (b1*rc1 - re)*veb1)/((b1*b2*rc1 + (b1 + 1)*rc1)*re + ((b2 + 1)*re + rc1)*rfb)]]
I am probably missing something obvious, but I'd be grateful if someone could explain why does Sage behave like this. You can try the first example in SageMathCell using this link, and the second one (the one that provides the answer) using this link.
Also, the first example does provide an answer if the two "fake" uknowns are included in the list of variables to solve for. This:
ib1, ib2, ire, irc1, rfb, re, vcc, veb1, veb2, rc1, b1, b2 = var('ib1 ib2 ire irc1 rfb re vcc veb1 veb2 rc1 b1 b2')
solve([ veb1 == -ib1*rfb + ire*re,
vcc == ire*re + veb2 + rc1*irc1,
irc1 == b1*ib1 + ib2,
ire == (b2+1)*ib2 - ib1
], ib1, ib2, irc1, ire)
Yields:
[[ib1 == (((b2 + 1)*vcc - (b2 + 1)*veb2)*re - ((b2 + 1)*re + rc1)*veb1)/((b1*(b2 + 1) + 1)*rc1*re + ((b2 + 1)*re + rc1)*rfb), ib2 == (re*(vcc - veb2) + rfb*(vcc - veb2) + (b1*rc1 - re)*veb1)/((b1*(b2 + 1) + 1)*rc1*re + ((b2 + 1)*re + rc1)*rfb), irc1 == -((b1*(b2 + 1) + 1)*re*veb1 - ((b1*(b2 + 1) + 1)*vcc - (b1*(b2 + 1) + 1)*veb2)*re - rfb*(vcc - veb2))/((b1*(b2 + 1) + 1)*rc1*re + ((b2 + 1)*re + rc1)*rfb), ire == ((b1*(b2 + 1) + 1)*rc1*veb1 + ((b2 + 1)*vcc - (b2 + 1)*veb2)*rfb)/((b1*(b2 + 1) + 1)*rc1*re + ((b2 + 1)*re + rc1)*rfb)]]
So I could happily live with this version (link to SageMathCell) and just discard the solutions for ire and irc1, but I'd like to understand Sage's behaviour and to know what I am missing or doing wrong.
Thank you in advance.

Related

How to solve R not recognizing white-space after long line of code?

I am trying to add equations to my code which are quite long. When I do so, R does not quite grasp where the end of the equation is and when I go to the next line filled with whitespace, it puts the cursor to the middle of the line rather than the beginning, as usually.
When I run the code, it ignores the end of the long equation, as one can tell from the console output
+ # 3.b) Initialize ODEs
+ initialstate <- c(
Error: unexpected symbol in:
"# 3.b) Initialize ODEs
initialstate"
-- so using + rather than > -- following this input:
C_PL_s_ss = (Rin_s*(CL_dis_s*T1*T2*V_IS + CL_dis_s*T1*T2*V_PE + CL_dis_s*T1*T2*V_PL + CL_dis_s*T1*T3_s*V_IS + CL_dis_s*T1*T4_s*V_IS + CL_dis_s*T2*T3_s*V_IS + CL_dis_s*T2*T4_s*V_IS + CL_dis_s*T2*T5_s*V_IS + CL_dis_s*T2*T6_s*V_IS + CL_dis_s*T1*T3_s*V_PE + CL_dis_s*T1*T4_s*V_PE + CL_dis_s*T2*T3_s*V_PE + CL_dis_s*T2*T4_s*V_PE + CL_dis_s*T2*T5_s*V_PE + CL_dis_s*T2*T6_s*V_PE + CL_dis_s*T1*T3_s*V_PL + CL_dis_s*T1*T4_s*V_PL + CL_dis_s*T2*T3_s*V_PL + CL_dis_s*T2*T4_s*V_PL + CL_dis_s*T2*T5_s*V_PL + CL_dis_s*T2*T6_s*V_PL + CL_dis_s*T1*T2*V_IS*delta_Rin_s_TI + CL_dis_s*T1*T3_s*V_IS*delta_Rin_s_TI + CL_dis_s*T1*T4_s*V_IS*delta_Rin_s_TI + CL_dis_s*T2*T3_s*V_IS*delta_Rin_s_TI + CL_dis_s*T2*T4_s*V_IS*delta_Rin_s_TI + CL_dis_s*T2*T5_s*V_IS*delta_Rin_s_TI + CL_dis_s*T2*T6_s*V_IS*delta_Rin_s_TI + CL_dis_s*CLup_s^2*V_IS*V_PE*V_VC + CL_dis_s*CLup_s^2*V_IS*V_PL*V_VC + CLup_s^2*T1*V_IS*V_PE*V_PL + CLup_s^2*T2*V_IS*V_PE*V_VC + CLup_s^2*T2*V_PE*V_PL*V_VC + CLup_s^2*T3_s*V_IS*V_PE*V_PL + CLup_s^2*T4_s*V_IS*V_PE*V_PL + CLup_s^2*T5_s*V_IS*V_PE*V_PL + CLup_s^2*T6_s*V_IS*V_PE*V_PL + CLup_s^2*T3_s*V_PE*V_PL*V_VC + CLup_s^2*T4_s*V_PE*V_PL*V_VC + CLup_s^3*V_IS*V_PE*V_PL*V_VC + CL_dis_s*CLup_s*T1*V_IS*V_PE + CL_dis_s*CLup_s*T1*V_IS*V_PL + CL_dis_s*CLup_s*T2*V_IS*V_VC + CL_dis_s*CLup_s*T2*V_PE*V_VC + CL_dis_s*CLup_s*T2*V_PL*V_VC + CL_dis_s*CLup_s*T3_s*V_IS*V_PE + CL_dis_s*CLup_s*T4_s*V_IS*V_PE + CL_dis_s*CLup_s*T5_s*V_IS*V_PE + CL_dis_s*CLup_s*T6_s*V_IS*V_PE + CL_dis_s*CLup_s*T3_s*V_IS*V_PL + CL_dis_s*CLup_s*T4_s*V_IS*V_PL + CL_dis_s*CLup_s*T5_s*V_IS*V_PL + CL_dis_s*CLup_s*T6_s*V_IS*V_PL + CL_dis_s*CLup_s*T3_s*V_PE*V_VC + CL_dis_s*CLup_s*T4_s*V_PE*V_VC + CL_dis_s*CLup_s*T3_s*V_PL*V_VC + CL_dis_s*CLup_s*T4_s*V_PL*V_VC + CLup_s*T1*T2*V_IS*V_PE + CLup_s*T1*T2*V_PE*V_PL + CLup_s*T1*T3_s*V_IS*V_PE + CLup_s*T1*T4_s*V_IS*V_PE + CLup_s*T2*T3_s*V_IS*V_PE + CLup_s*T2*T4_s*V_IS*V_PE + CLup_s*T2*T5_s*V_IS*V_PE + CLup_s*T2*T6_s*V_IS*V_PE + CLup_s*T1*T3_s*V_PE*V_PL + CLup_s*T1*T4_s*V_PE*V_PL + CLup_s*T2*T3_s*V_PE*V_PL + CLup_s*T2*T4_s*V_PE*V_PL + CLup_s*T2*T5_s*V_PE*V_PL + CLup_s*T2*T6_s*V_PE*V_PL + CL_dis_s*CLup_s*T2*V_IS*V_VC*delta_Rin_s_TI + CLup_s*T1*T2*V_IS*V_PE*delta_Rin_s_TI + CLup_s*T1*T3_s*V_IS*V_PE*delta_Rin_s_TI + CLup_s*T1*T4_s*V_IS*V_PE*delta_Rin_s_TI + CLup_s*T2*T3_s*V_IS*V_PE*delta_Rin_s_TI + CLup_s*T2*T4_s*V_IS*V_PE*delta_Rin_s_TI + CLup_s*T2*T5_s*V_IS*V_PE*delta_Rin_s_TI + CLup_s*T2*T6_s*V_IS*V_PE*delta_Rin_s_TI + CLup_s^2*T2*V_IS*V_PE*V_VC*delta_Rin_s_TI))/(CLR_s*CL_dis_s*T1*T2 + CLR_s*CL_dis_s*T1*T3_s + CLR_s*CL_dis_s*T1*T4_s + CLR_s*CL_dis_s*T2*T3_s + CLR_s*CL_dis_s*T2*T4_s + CLR_s*CL_dis_s*T2*T5_s + CLR_s*CL_dis_s*T2*T6_s + CLR_s*CL_dis_s*CLup_s^2*V_IS*V_VC + CL_dis_s*CLup_s^2*Q*V_IS*V_VC + CLR_s*CLup_s^2*T1*V_IS*V_PE + CLR_s*CLup_s^2*T2*V_PE*V_VC + CL_dis_s*CLup_s^2*T1*V_IS*V_PE + CL_dis_s*CLup_s^2*T1*V_IS*V_PL + CL_dis_s*CLup_s^2*T2*V_PE*V_VC + CL_dis_s*CLup_s^2*T2*V_PL*V_VC + CLR_s*CLup_s^2*T3_s*V_IS*V_PE + CLR_s*CLup_s^2*T4_s*V_IS*V_PE + CLR_s*CLup_s^2*T5_s*V_IS*V_PE + CLR_s*CLup_s^2*T6_s*V_IS*V_PE + CLR_s*CLup_s^2*T3_s*V_PE*V_VC + CLR_s*CLup_s^2*T4_s*V_PE*V_VC + CL_dis_s*CLup_s^2*T3_s*V_IS*V_PE + CL_dis_s*CLup_s^2*T4_s*V_IS*V_PE + CL_dis_s*CLup_s^2*T5_s*V_IS*V_PE + CL_dis_s*CLup_s^2*T6_s*V_IS*V_PE + CL_dis_s*CLup_s^2*T3_s*V_IS*V_PL + CL_dis_s*CLup_s^2*T4_s*V_IS*V_PL + CL_dis_s*CLup_s^2*T5_s*V_IS*V_PL + CL_dis_s*CLup_s^2*T6_s*V_IS*V_PL + CL_dis_s*CLup_s^2*T3_s*V_PE*V_VC + CL_dis_s*CLup_s^2*T4_s*V_PE*V_VC + CL_dis_s*CLup_s^2*T3_s*V_PL*V_VC + CL_dis_s*CLup_s^2*T4_s*V_PL*V_VC + CLR_s*CLup_s^3*V_IS*V_PE*V_VC + CL_dis_s*CLup_s^3*V_IS*V_PE*V_VC + CL_dis_s*CLup_s^3*V_IS*V_PL*V_VC + CLup_s^2*Q*T2*V_PE*V_VC + CLup_s^2*Q*T3_s*V_IS*V_PE + CLup_s^2*Q*T4_s*V_IS*V_PE + CLup_s^2*Q*T5_s*V_IS*V_PE + CLup_s^2*Q*T6_s*V_IS*V_PE + CLup_s^2*Q*T3_s*V_PE*V_VC + CLup_s^2*Q*T4_s*V_PE*V_VC + CLup_s^3*Q*V_IS*V_PE*V_VC + CLup_s^2*T1*T2*V_PE*V_PL + CLup_s^2*T1*T3_s*V_PE*V_PL + CLup_s^2*T1*T4_s*V_PE*V_PL + CLup_s^2*T2*T3_s*V_PE*V_PL + CLup_s^2*T2*T4_s*V_PE*V_PL + CLup_s^2*T2*T5_s*V_PE*V_PL + CLup_s^2*T2*T6_s*V_PE*V_PL + CLup_s^3*T1*V_IS*V_PE*V_PL + CLup_s^3*T2*V_PE*V_PL*V_VC + CLup_s^3*T3_s*V_IS*V_PE*V_PL + CLup_s^3*T4_s*V_IS*V_PE*V_PL + CLup_s^3*T5_s*V_IS*V_PE*V_PL + CLup_s^3*T6_s*V_IS*V_PE*V_PL + CLup_s^3*T3_s*V_PE*V_PL*V_VC + CLup_s^3*T4_s*V_PE*V_PL*V_VC + CLup_s^4*V_IS*V_PE*V_PL*V_VC + CLR_s*CL_dis_s*CLup_s*T1*V_IS + CLR_s*CL_dis_s*CLup_s*T2*V_VC + CLR_s*CL_dis_s*CLup_s*T3_s*V_IS + CLR_s*CL_dis_s*CLup_s*T4_s*V_IS + CLR_s*CL_dis_s*CLup_s*T5_s*V_IS + CLR_s*CL_dis_s*CLup_s*T6_s*V_IS + CLR_s*CL_dis_s*CLup_s*T3_s*V_VC + CLR_s*CL_dis_s*CLup_s*T4_s*V_VC + CL_dis_s*CLup_s*Q*T2*V_VC + CL_dis_s*CLup_s*Q*T3_s*V_IS + CL_dis_s*CLup_s*Q*T4_s*V_IS + CL_dis_s*CLup_s*Q*T5_s*V_IS + CL_dis_s*CLup_s*Q*T6_s*V_IS + CL_dis_s*CLup_s*Q*T3_s*V_VC + CL_dis_s*CLup_s*Q*T4_s*V_VC + CLR_s*CLup_s*T1*T2*V_PE + CL_dis_s*CLup_s*T1*T2*V_PE + CL_dis_s*CLup_s*T1*T2*V_PL + CLR_s*CLup_s*T1*T3_s*V_PE + CLR_s*CLup_s*T1*T4_s*V_PE + CLR_s*CLup_s*T2*T3_s*V_PE + CLR_s*CLup_s*T2*T4_s*V_PE + CLR_s*CLup_s*T2*T5_s*V_PE + CLR_s*CLup_s*T2*T6_s*V_PE + CL_dis_s*CLup_s*T1*T3_s*V_PE + CL_dis_s*CLup_s*T1*T4_s*V_PE + CL_dis_s*CLup_s*T2*T3_s*V_PE + CL_dis_s*CLup_s*T2*T4_s*V_PE + CL_dis_s*CLup_s*T2*T5_s*V_PE + CL_dis_s*CLup_s*T2*T6_s*V_PE + CL_dis_s*CLup_s*T1*T3_s*V_PL + CL_dis_s*CLup_s*T1*T4_s*V_PL + CL_dis_s*CLup_s*T2*T3_s*V_PL + CL_dis_s*CLup_s*T2*T4_s*V_PL + CL_dis_s*CLup_s*T2*T5_s*V_PL + CL_dis_s*CLup_s*T2*T6_s*V_PL)
# 3.b) Initialize ODEs
initialstate <- c(*[...some other cade that work unless you add the long equation above...])*
Bizarrely, if I write more than one of these longer equations, it recognises the end of exactly every second one, i.e. it pairs two, which leads to the issue. For the ones that it does not pair, it also has the > rather than + in the respective place in the console. I could get it to work fine for 5 short equations.
As I am exporting the equations from Matlab (as I need to use the symbolics toolbox to find the solution), I checked whether any of
cutting whitespaces out online, incl. equation by equation, so line by line
pasting the many equations into Word to see whether there is a difference in the tabs/new lines etc. between the equations for which the pasting interrupts between equations appropriately versus not (no both are the same)
past into text editor before moving to R, incl. equation by equation, so line by line
using my local version of R studio rather than the R studio workbench I was using previously
would help but they did not.
I have tried for a long time now and would be super grateful for any insight!
R is built with a maximum line length of 4096 characters as shown in this thread. Lines that are longer than that will need to be broken.

unexpected input in R

I am trying to add columns to my df for woba, an advanced baseball stat, but when I try to mutate the column it gives an unexpected input.
This is my code
library(baseballr)
output <- bref_daily_batter("2015-05-10", "2015-05-30")
output <- mutate(output, wOBA = (0.687*uBB + 0.718*HBP + 0.881*X1B + 1.256*X2B + 1.594*X3B + 2.065*HR) / (AB + BB – IBB + SF + HBP))
Error: unexpected input in "output<- mutate(output, wOBA = (0.687uBB + 0.718HBP + 0.881X1B + 1.256X2B + 1.594X3B + 2.065HR) / (AB + BB –"
The problem is in whatever negative symbol you are using.
This does not work:
output <- mutate(output, wOBA = (0.687*uBB + 0.718*HBP + 0.881*X1B + 1.256*X2B + 1.594*X3B + 2.065*HR) / (AB + BB – IBB + SF + HBP))
but this does:
output <- mutate(output, wOBA = (0.687*uBB + 0.718*HBP + 0.881*X1B + 1.256*X2B + 1.594*X3B + 2.065*HR) / (AB + BB - IBB + SF + HBP))
I just replaced the minus sign with a new minus sign, which looks slightly smaller on my screen

Bandwidth Selection on Semi parametric Regression: npplregbw error

I am trying to find the bandwidth of a semiparametric panel regression of the form:
x1it = a1 + a2 x2it + a3 x3it + a4 x4it + fei + fet + g(x5it) + uit
where fei and fet are the country and time fixed effects. For that I am using the code:
bw <- npplregbw(x1 ~ x2+ x3+ x4+ effect1 + effect2 + effect3 + effect4 + effect5 + effect6 + effect7 + effect8 + effect9 + effect10 + effect11 + effect12 + effect13 + effect14 + effect15 + effect16 + effect17 + effect18 + effect19|x5, data = mydata, na.action = na.omit)
But when I am running that I am getting the following error:
Error in npregbw.rbandwidth(xdat = xdat, ydat = ydat, bws = tbw, bandwidth.compute = bandwidth.compute) :
number of regression data and response data do not match
I cannot understand what is the problem.
Any help would be appreciated.
Thanks a lot

Recurrence relation with not constant coefficients

I have this recurrence relation
L^2 G[p]= 2(p-1)(2p-1)G[p-1] + ((p-1)(p-2)+a^2) G[p-2], where L and a are parameters.
Does anyone could help me to find the solution? Thanks
This looks like quite a complicated calculation, especially when no start values are given.
To get some more insight, one could use sympy, Python's symbolic math library to print the formulas for small values of p:
from sympy import symbols
def func_G(p):
if p == 0:
return G0
elif p == 1:
return G1
else:
return (2 * (p - 1) * (2 * p - 1) * func_G(p - 1) + ((p - 1) * (p - 2) + a ** 2) * func_G(p - 2)) / L ** 2
a, L, G0, G1 = symbols('a L G0 G1')
for p in range(8):
print(p, ':', func_G(p).simplify())
Prints out:
0 : G0
1 : G1
2 : (G0*a**2 + 6*G1)/L**2
3 : (20*G0*a**2 + G1*L**2*(a**2 + 2) + 120*G1)/L**4
4 : (840*G0*a**2 + 42*G1*L**2*(a**2 + 2) + 5040*G1 + L**2*(a**2 + 6)*(G0*a**2 + 6*G1))/L**6
5 : (60480*G0*a**2 + 3024*G1*L**2*(a**2 + 2) + 362880*G1 + 72*L**2*(a**2 + 6)*(G0*a**2 + 6*G1) + L**2*(a**2 + 12)*(20*G0*a**2 + G1*L**2*(a**2 + 2) + 120*G1))/L**8
6 : (G0*L**4*a**6 + 26*G0*L**4*a**4 + 120*G0*L**4*a**2 + 10960*G0*L**2*a**4 + 90720*G0*L**2*a**2 + 6652800*G0*a**2 + 158*G1*L**4*a**4 + 2620*G1*L**4*a**2 + 5040*G1*L**4 + 398400*G1*L**2*a**2 + 1209600*G1*L**2 + 39916800*G1)/L**10
7 : (248*G0*L**4*a**6 + 7488*G0*L**4*a**4 + 38880*G0*L**4*a**2 + 1770240*G0*L**2*a**4 + 15966720*G0*L**2*a**2 + 1037836800*G0*a**2 + G1*L**6*a**6 + 44*G1*L**6*a**4 + 444*G1*L**6*a**2 + 720*G1*L**6 + 28224*G1*L**4*a**4 + 526080*G1*L**4*a**2 + 1088640*G1*L**4 + 62513280*G1*L**2*a**2 + 199584000*G1*L**2 + 6227020800*G1)/L**12

Constraining a covariate-path in lavaan

I have the following lavaan model:
model <- ' i =~ 1*t1 + 1*t2 + 1*t3 + 1*t4 + 1*t5 + 1*t6 + 1*t7 + 1*t8 + 1*t9 + 1*t10 + 1*t11 + 1*t12 + 1*t13+ 1*t14 + 1*t15 + 1*t16 + 1*t17 + 1*t18 + 1*t19 + 1*t20
s =~ 0*t1 + 1*t2 + 2*t3 + 3*t4 + 4*t5 + 5*t6 + 6*t7 + 7*t8 + 8*t9 + 9*t10 + 10*t11 + 11*t12 + 12*t13 + 13*t14 + 14*t15 + 15*t16 + 16*t17 + 17*t18 + 18*t19 + 19*t20
t8 ~~ 0.01*t8
t17 ~~ 0.01*t17
t18 ~~ 0.01*t18
# regressions
s ~ h_index
i ~ h_index'
fit_UNconstrained <- growth(model, data=growth_data, group = "type")
summary(fit_UNconstrained)
Now, I would like to create a model that constraints the paths s ~ h_index and i ~ h_index to be equal across all groups ("type"). How can I accomplish this?
I believe this works in the same way as it would for adding group-wise constraints to the indicators of a latent factor. And if that's the case, then all you need to do is to add a vector of labels next to the predictor you want to constrain across groups. In your case, you have two parameter estimates you want to constrain, so you'd add two vectors.
The length of the vector is going to depend on the number of groups you have, and the label will be the same for all groups.
Let's suppose you have three groups; then your code would look something like the following.
model <- "
i =~ 1*t1 + 1*t2 + 1*t3 + 1*t4 + 1*t5 + 1*t6 + 1*t7 + 1*t8 + 1*t9 + 1*t10 + 1*t11 + 1*t12 + 1*t13+ 1*t14 + 1*t15 + 1*t16 + 1*t17 + 1*t18 + 1*t19 + 1*t20
s =~ 0*t1 + 1*t2 + 2*t3 + 3*t4 + 4*t5 + 5*t6 + 6*t7 + 7*t8 + 8*t9 + 9*t10 + 10*t11 + 11*t12 + 12*t13 + 13*t14 + 14*t15 + 15*t16 + 16*t17 + 17*t18 + 18*t19 + 19*t20
t8 ~~ 0.01*t8
t17 ~~ 0.01*t17
t18 ~~ 0.01*t18
# regressions
s ~ c(v1, v1, v1)*h_index
i ~ c(v2, v2, v2)*h_index
"
fit_UNconstrained <- growth(model, data=growth_data, group = "type")
summary(fit_UNconstrained)
Here the vectors c(v1, v1, v1) and c(v2, v2, v2) are telling lavaan to constrain these parameter estimates to be equal across groups.
I believe this should do what you have in mind.

Resources