What causes the SML error: Exception- InternalError: asGenReg raised while compiling - sml

I am learning SML, and couldn't figure out why the following textbook code generates an error:
fun recip (x,y) = let val t = x *x + y *y in (x /t, ~y/t) end;
The error is:
Exception- InternalError: asGenReg raised while compiling
This is with Poly/ML 5.7.1.
The code computes the reciprocal of a complex number (x,y). I tried adding ; and parentheses at places to no avail.
Strangely, the following changed (incorrect) definition works without any error.
fun recip (x,y) = let val t = x *x + y *y in (x, ~y/t) end;
The error message is not very informational.
Can someone help explain where the error is and how to fix it?

As the comments #qouify and #mobdnilo pointed out, this error seems to be a bug of the particular version of PolyML in Ubuntu. I reinstalled the PolyML by compiling from source to the latest version (5.9), and the error is gone.

Related

Problems solving 3 equations dependency variables in c++

The equations are here
Hi! I tried to solve 3 pde equations by using the FD method in C++, but I do not know why I got half of the exact answer at all time. These equations are dependency variable. I have problem with g(x,y) and g(y,x). When I delete g(y,x) in eq 3, the result does not change. But when I delete g(x,y), I got zero, so I think we need to do something for dependency variables. I do not know. I hope to get help
if(g[i][k][j]!=g[k][i][j] && i!=k)
u[i][k][j+1]=u[i][k][j]*(1.0 - 2.0*dt)
+(dt/(dx*dx))*(g[i+1][k][j]- 2.0*g[i][k][j]+g[i-1][k][j])
+(dt/(dx*dx))*(g[k+1][i][j]- 2.0*g[k][i][j]+g[k-1][i][j])
+(dt/(dy*dy))*(g[i][k+1][j]-2.0*g[i][k][j]+g[i][k-1][j])
+(dt/(dy*dy))*(g[k][i+1][j]-2.0*g[k][i][j]+g[k][i-1][j]); //(eq 1)
g[i][k][j+1]=g[i][k][j]*(1 - dt)
+dt*u[i][k][j]
+(dt/(dy*dy))*(v[i][k+1][j]-2*v[i][k][j]+v[i][k-1][j])
+(dt/(dx*dx))*(v[i+1][k][j]-2*v[i][k][j]+v[i-1][k][j]); //(eq 2)
v[i][k][j+1]=v[i][k][j]+(g[k][i][j] + g[i][k][j])*dt; //(eq 3)
Guessing from your picture and code, I think you may be missing a pair of braces
if(i!=k && g[i][k][j]!=g[k][i][j]) {
u[i][k][j+1] = ...;
g[i][k][j+1] = ...;
v[i][k][j+1] = ...;
}
Note also that the comparison g[i][k][j]!=g[k][i][j] is likely to fail if the type is float or double (or complext<float>, complex<double> etc), see this post.

What could cause this pyomo error: "ERROR: evaluating object as numeric value"?

Very occasionally I get this error when running pyomo: "ERROR: evaluating object as numeric value: 0.0". It looks a little like the error that results when some solvers return, for example, 0.0 instead of 0 and this then leads to an error when re-using the results with the, for example, within=Binary keyword argument of the Var function. I don't believe this is the case here. Can anyone give me some ideas as to what may cause this error? I was using glpk at the time.
Here's some more info. I'm solving an optimisation problem sequentially, a day at a time. So the solution from yesterday becomes an input to today's problem. Here are some simplified code spinets:
results = manager.solve(instance, kwargs...)
instance.solutions.load_from(results)
states_dict = get_next_states(instance, time, args...)
def get_next_states(instance, time, args...):
states_dict = {}
for state in states:
var = getattr(instance, state)
for a in a_list:
value = var[a, time].value
states_dict[state, a] = force_domain(value, integer, tolerance)
return states_dict
force_domain forces value to be integer and/or nonnegative, depending on the integer and tolerance arguments. The code fails when evaluating force_domain; sometimes with the above error, and sometimes with a TypeError exception: TypeError: unorderable types: NoneType() < int(). Here's force_domain:
def force_domain(x, integer, nonnegative):
y = x
if x < 0 and nonnegative:
y = chop_tiny(y, nonnegative)
if integer:
y = round_if_int(y)
return y
def chop_tiny(x, tol):
if abs(x) > tol or isinstance(x, int):
return x
else:
return 0.0
def round_if_int(x):
if isinstance(x, float) and (x).is_integer():
return int(x)
else:
return x
These errors occur in less than 1 in 2000 runs.
Does this extra info help you to answer my question?
I've managed to isolate and reproduce the error. It turns out to be due to numerical instability in GLPK v4.57 that resulted in a crash. This numerical instability appears to have been fixed in GLPK v4.60. See https://lists.gnu.org/archive/html/info-gnu/2016-04/msg00000.html.

TypeError: In a simple loop of code

I've tried to solve my problem by googling, but every time someone has the same problem also has complicated code. I a noob and I have no idea why It keeps having an error called "TypeError: not all arguments converted during string formatting" Even though I tried converting some of the variables to int. (I'm probably solving it the wrong way). Can someone give a heads up without giving me the answer?
x = range(2, 20)
number = 0
y = raw_input()
flag = True
while flag == True:
for elem in x:
if y % elem == 0:
print elem
else:
flag = False
All you need to do is convert the raw_input() into integer using int() function. That's will solve the program. You can do this by:
y = int(raw_input())
The problem is that, when you read an input with raw_input(), you receive a string, and you are treating the variable y later on your code as an integer (at if y % elem == 0:). You need to cast the input to an integer, which can be done substituting this line
y = raw_input()
for this line:
y = int(raw_input())

Receiving error "no matching function for call to pow(double)"

I'm making a code that will calculate interest on a savings account. I listed all my variables as Double. I compiled it before writing the cout prompts at the bottom, and now that my code is finished, it won't compile. It gives me an error. I tried messing with the amount of parentheses, but nothing helped. Here is my code
FinalBalanceDaily = StartingPrinciple*(pow(1+((SimpInt/100)/365),(365*T)));
FinalBalanceMonthly = StartingPrinciple*(pow(1+((SimpInt/100)/12),(12*T)));
This is the error message.
:55: error: no matching function for call to âpow(double)â
and then it gives notes. The thing is, those two lines are on lines 53 and 54, 55 uses the exp function.
FinalBalanceCont = StartingPrinciple*(exp((SimpInt/100)*T));
EffectiveSimpInt1=(exp(SimpInt*T)-1)/T;
EffectiveSimpInt2=((pow(1+(SimpInt/365),(365*T)))-1)/T;
EffectiveSimpInt3=(pow(1+(SimpInt/12),(12*T))-1)/T;
These are the lines that use the pow() function
std::pow() need two parameters, but you just give one
I suggest that you can make your code more readable:
double x = 1 + (SimpInt / 100) / 12;
double y = 12 * T;
FinalBalanceMonthly = StartingPrinciple * pow(x, y);
By the way, I think that you put your "()" on the wrong place

This expression has type unit but an expression was expected of type int

I have a bug in my program in OCaml and I am looking for help.
the error:
This expression has type unit but an expression was expected of type int
The line error with the error contains soma = soma
let soma = 0;;
let rec nBell n =
if n == 0 then 1
else
for k=0 to n-1 do
soma = soma + ((fact(n-1)/(fact(k)*fact((n-1)-k))) * nBell(k));
done;;`
Can anyone help me?
As has recently been mentioned here quite a few times, OCaml has no statements. It only has expressions. For an if expression to make sense, the then and else parts have to be the same type. In your code the then part is 1. I.e., it has type int. In the else part you have a for expression. The type of a for expression is unit. So that's what the compiler is complaining about.
However, fixing this problem will be just the first step, as your code is based on a misunderstanding of how OCaml variables work. OCaml variables like soma are immutable. You can't change their value. So the expression soma = soma + 1 is actually a comparison that tells whether the two values are equal:
# let soma = 0;;
val soma : int = 0
# soma = soma + 1;;
- : bool = false
Generally speaking, you need to find a way to solve your problem without assigning to variables; i.e., without changing their values.
If you're just starting with functional programming, this seems absurd. However it turns out just to be another way to look at things.