backtracking line search in R - algorithm

why backtracking(step halving) line serach get fail? actually sometimes in my R code i have an ascent direction and step size $t = 1e-21$ which means that Error: Line search failed (tol=1e-10) and i chose alpha=0.3 and beta=0.5.

I'm going to make a wild guess and say that thanks to floating point round off, you can't reliably make steps that small.
But really I don't know. Nor will anyone else until you follow the suggestion to actually show us what is not working.

Related

How to represent one variable in terms of others in an equation set in Mathematicas?

I have an pretty complex equation set enter image description here
I want to solve Vo in terms of Vin.
But when I clicked Ctrl+Enter (a.k.a Evaluate Cell), nothing happened.
How to fix it? Thanks for your help
Simplify[Reduce[eqn, Vo]]
works.
If you can include any assumptions (as a second argument to Simplify or by giving those along with your equations to Reduce) that you have about some variables not being zero then the result might be simpler. In any case, you look through each of the terms returned from Simplify to try to find the case that matches your real world problem.

What is this prolog output trying to say?

Years ago in college,I tinkered with some prolog, but that's long forgotten, so I count as a complete beginnner again (humbling!)
Anyway, I was playing with some of Bruce Tate's code, and came up with what I thought was a sudoku solver for the full (9x9) game. But, when I run it, it generates some very odd output:
Solution = [_#3(2..3),_#24(2:7),_#45(2..3:5:7),_#66(2..3:8),_#87(2..3:5..6:8),4,_#121(2:5..6),1,9,6,8,_#194(2..5:7:9),_#215(1..3:9),_#236(2..3:5:9),_#257(1..2:5:9),_#278(2:4..5),_#299(4:7),_#320(5:7),_#341(1..2),_#362(2:4),_#383(2:4..5:9),_#404(1..2:9),_#425(2:5..6:9),7,3,_#472(4:6),8,4,1,_#532(2:8),_#553(2:8),7,3,9,5,6,7,5,_#689(6:8),_#710(4:8..9),_#731(4:6:8..9),_#752(6:8..9),1,2,3,_#828(2..3),9,_#862(2..3:6),5,1,_#909(2:6),7,8,4,8,_#990(2:4:7),1,6,_#1037(2..5:9),_#1058(2:5:9),_#1079(4..5),_#1100(3..4:7),_#1121(5:7),5,_#1163(4:6..7),_#1184(4:6..7),_#1205(1:3..4:8),_#1226(3..4:8),_#1247(1:8),_#1268(4:6:8),9,2,9,3,_#1341(2:4:6),7,_#1375(2:4..5:8),_#1396(1..2:5:8),_#1417(4..6:8),_#1438(4:6),_#1459(1:5)]
yes
I was expecting ... well, frankly I was half expecting total failure :) but I thought that only numbers could show up in this output. What's it trying to tell me with those #-tagged things, and stuff in parens that looks like ranges? Is it trying to say there are many possible solutions and it's telling me all at once (seems unlikely as it's very unhelpful if it is) or is this some kind of error state (in which case, why does it compile my code and say "yes" to this query?)
Any insight gratefully received!
I think it's the result of a set of constraints not sufficiently strong to determine a solution without search. For instance, _#3(2..3) could means that a variable named _#3 could assume values in range 2..3. You could try to label the variables, something like
..., labeling([], Solution).
Syntax details depend on your solver, of course...

MATLAB: A specific line of a .m file slows down the speed (potential bottleneck?)

I have encountered an unexpected problem, while i am trying to implement an AC-3 algorithm in MATLAB. It's an AI algorithm, to achieve local consistency for networks of binary constraints.
Well, firstly, let me explain this to you. In general, what i am trying to do here, is check whether an "arc" (xi,xj) of variables already exists or not in a FIFO queue called Q. If yes, i do nothing. If it does not already exists, i have to insert the arc into the Q(into the back, FIFO-style) and use break to exit the if statement. I hope that it is pretty much clear until now.
To add this arc (xi,xj) to the Q, i use a replicated matrix Q2, just like Q, which holds all the arcs of type (xi,xj) the whole time, while the initial Q is making some deletions of arcs through the iterations of a for loop, following the theory of the AC-3 algorithm.
There is the code the problem is located:
for m=1:length(Q2)
alreadyExists = any(cellfun(#(x) isequal(x, Q2{m}), Q));
if alreadyExists==0;
fprintf('\nRe-entering in Q arc(x%d,x%d)...\n',Q2{m}(1),Q2{m}(2));
Q{end+1}=[Q2{m}];
re_enteringQ_cntr=re_enteringQ_cntr+1;
break;
end
end
So what i am doing in line:
alreadyExists = any(cellfun(#(x) isequal(x, Q2{m}), Q));
Is just to compare every arc (xi,xj) stored in Q2 with x, a variable returned by another function, which is also another arc.
And here is the problem, using profile viewer on MATLAB:
It is really weird. About ~70 million calls this specific code in nearly 12 minutes of "real" time?! I did Ctrl+C to stop the program, as it seemed it would be executed for a really long time.This cannot be right of course, it is a kind of bottleneck and I can not find any solution until now.
To catch you up guys, in every function and .m file of my whole algorithm i do preallocations for all the matrices, cell arrays and vectors i use, in order to boost up the speed.
Any ideas, any thoughts and/or feedback would be really appreciated.
Thank you in advance for your time.

LightsOut game solving method "reduced echolean ".Does it always gives correct result?

I am studing the algorithm given here, and
somewhere it is claimed that it is efficent and always give correct result.
But, I try to run the algorithm and it is not giving me correct or efficent output for the following patterns.
For 5 x 5 grid, where (n) is light number and 0/1 state whethere the light is on/off, 1 ON and 0 OFF.
(1)1 (2)0 (3)0 (4)0 (5)0 the output should be 1,7,13,19,25(Pressing this light will make the full grid OFF. But what I am getting is this
(6)0 (7)1 (8)0 (9)0 (10)0 3,5,6,7,8,10,13,16,18,19,20,21,23.
(11)0 (12)0 (13)1 (14)0 (15)0
(16)0 (17)0 (18)0 (19)1 (20)0
(21)0 (22)0 (23)0 (24)0 (25)1
While for some pattern it is giving me correct output as below.
(1)0 (2)0 (3)0 (4)0 (5)1 the output should be 5,9,13,17,21, and the algorithm is giving me correct result.
(6)0 (7)0 (8)0 (9)1 (10)0
(11)0 (12)0 (13)1 (14)0 (15)0
(16)0 (17)1 (18)0 (19)0 (20)0
(21)1 (22)0 (23)0 (24)0 (25)0
If somebody need a code let me know I can post it.
Can please somebody let me know if this methods will always give correct as well as efficient result or not ?
(I'm the author of the code you linked to.) To the best of my knowledge, the code is correct (and I'm sure that the high-level algorithm of using Gaussian elimination over GF(2) is correct). The solution it produces is guaranteed to solve the puzzle, though it's not necessarily the minimal number of button presses. The "efficiency" I was referring to in the writeup refers to the time complexity of solving the puzzle overall (it can solve a Lights Out grid in polynomial time, as opposed to the exponential-time brute-force solution of trying all possible combinations) rather than to the "efficiency" of the generated solution.
I actually don't know any efficient algorithms for finding a solution requiring the minimum number of button presses. Let me know if you find one!
Hope this helps!

Befunge RNG -- Why am I getting so many 2s?

Befunge isn't used much outside of code golf, but I wanted to try to learn it. I got a random number generator from Wikipedia and decided to modify it so that it ended. Here's what I have:
v>>>>.v>
?^
12345#
^ ^
> ? ?^
v?v
v6789>
And I was wondering why it has a tendency to generate the number 2 a lot, usually repeated. Is it just the interpreter?
You are missing a question mark on line 4, underneath "2".
Your code starts by going to line 5 and then hit the question mark there. If the question mark goes "up" in your sample, it will allways hit "2", so that will happen 25% of the time.
If you add the missing question mark underneath the number 2 you should start seeing more random results.

Resources