I implemented the tanh function as my activation function, but the result somehow is worse than with a sigmoid activation function. Moreover, while checking the error, it shows that the error goes up down and up again, over and over.
Here are example of error using tanh:
epoch:1823
current error:0.1383121756710299
epoch:1824
current error:0.13831547638188654
epoch:1825
current error:0.13831887880040633
epoch:1826
current error:0.13832238240031222
epoch:1827
current error:0.13832598673034413
epoch:1828
current error:0.1383296914155071
epoch:1829
current error:0.13833349615821078
epoch:1830
current error:0.13833740073931955
epoch:1831
current error:0.1383414050191362
epoch:1832
current error:0.13834550893832906
epoch:1833
current error:0.1383497125188264
epoch:1834
current error:0.13835401586468998
epoch:1835
current error:0.1383584191629793
epoch:1836
current error:0.13836292268462677
epoch:1837
current error:0.1383675267853283
epoch:1838
current error:0.13837223190646183
epoch:1839
current error:0.13837703857605013
epoch:1840
current error:0.138381947409767
epoch:1841
current error:0.1383869591120036
epoch:1842
current error:0.13839207447699467
epoch:1843
current error:0.13839729439001985
epoch:1844
current error:0.1384026198286766
epoch:1845
current error:0.1384080518642369
Meanwhile, sigmoid activation function does not show this. Does anybody have an idea why this is happening?
Related
I'm using a BPF kprobe to find out when a task's UIDs, GIDs and namespaces change outside the syscalls that have the ability to change these values. For this, I update values[pid] when returning from execve(), execveat(), setns(), unshare(), set*uid(). And on entry to begin_new_exec(), I check whether the current task's values match values[pid].
In some cases the probes incorrectly report that the UID or nsproxy for a process has changed, indicating I've missed a place where I need to update the task's values.
Looking at begin_new_exec(), it replaces the task's credentials and wipes out the old executable. But after begin_new_exec() returns, load_elf_binary() can still return errors while trying to set up the new process image.
Do these late errors reach usermode ? Is there a scenario where sys_execve can fail after begin_new_exec returns, and the PID is not terminated ?
folks!
I am trying to display the Simulink current simulation time. I have to notice that, in my case, the system is not viewable, once I use load_system, and it would be very useful to know how progress the simulation.
For that, I have read that I should use the function 'ssGetT'. To implement it, I am using S-function builder block and I succeeded. I mean, I was able to get the current simulation time.
However, I am caught at this point, because I do not know how display it either a progress bar or a message box or any other way. Important, display from an C environment in S-function builder.
If there is any other way to do it, please me. =)
If anybody could help me, I would really appreciate it.
A couple of things to note:
There is no need to use load_system prior to using sim.
As with any MATLAB command, sim blocks further execution of m-code after that line in your m-code (or the command line) until it has finished executing (which in this case means that the simulation has stopped).
But any m-code within the model will definitely get excuted during model execution.
For instance, create a model where you feed the Clock block into a MATLAB Function block. Within the MATLAB Function block have the following code
function fcn(t)
%#codegen
coder.extrinsic('fprintf');
persistent firstTime
if isempty(firstTime)
firstTime = false;
fprintf('Starting Now\n');
end
fprintf('time = %.4f\n',t);
This will print the simulation time, at every time step, to the MATLAB Command Window, while the simulation is running (irrespective of how the model is started).
Updating...
To display a progress status in the commad view, I took Phil's suggestion.
I implemented this system in symulink in which the fcn inputs are the simulation time from a clock and the final simulation time.
I define SampleTime in the Digital Clock block as Final simulation time/steps, where steps is the number of time you want to update the progress. In my case, I update it at each 5% untill 100%, so steps is 20.
The fnc block is:
function fcn(t,tsim)
coder.extrinsic('fprintf');
persistent firstTime
if isempty(firstTime)
firstTime = false;
fprintf('\nSimulating...\n\n');
end
prog = 100*t/tsim;
fprintf(' %1.0f%%',prog);
I am currently writing a debugger for a script virtual machine.
The compiler for the scripts generates debug information, such as function entry points, variable scopes, names, instruction to line mappings, etc.
However, and have run into an issue with step-over.
Right now, I have the following:
1. Look up the current IP
2. Get the source line from that
3. Get the next (valid) source line
4. Get the IP where the next valid source line starts
5. Set a temporary breakpoint at that instruction
or: if the next source line no longer belongs to the same function, set the temp breakpoint at the next valid source line after return address.
So far this works well. However, I seem to be having problems with jumps.
For example, take the following code:
n = 5; // Line A
if(n == 5) // Line B
{
foo(); // Line C
}
else
{
bar(); // Line D
--n;
}
Given this code, if I'm on line B and choose to step-over, the IP determined for the breakpoint will be on line C. If, however, the conditional jump evaluates to false, it should be placed on line D. Because of this, the step-over wouldn't halt at the expected location (or rather, it wouldn't halt at all).
There seems to be little information on debugger implementation of this specific issue out there. However, I found this. While this is for a native debugger on Windows, the theory still holds true.
It seems though that the author has not considered this issue, either, in section "Implementing Step-Over" as he says:
1. The UI-threads calls CDebuggerCore::ResumeDebugging with EResumeFlag set to StepOver.
This tells the debugger thread (having the debugger-loop) to put IBP on next line.
2. The debugger-thread locates next executable line and address (0x41141e), it places an IBP on that location.
3. It calls then ContinueDebugEvent, which tells the OS to continue running debuggee.
4. The BP is now hit, it passes through EXCEPTION_BREAKPOINT and reaches at EXCEPTION_SINGLE_STEP. Both these steps are same, including instruction reversal, EIP reduction etc.
5. It again calls HaltDebugging, which in turn, awaits user input.
Again:
The debugger-thread locates next executable line and address (0x41141e), it places an IBP on that location.
This statement does not seem to hold true in cases where jumps are involved, though.
Has anyone encountered this problem before? If so, do you have any tips on how to tackle this?
Since this thread comes in Google first when searching for "debugger implement step over". I'll share my experiences regarding the x86 architecture.
You start first by implementing step into: This is basically single stepping on the instructions and checking whether the line corresponding to the current EIP changes. (You use either the DIA SDK or the read the dwarf debug data to find out the current line for an EIP).
In the case of step over: before single stepping to the next instruction, you'll need to check if the current instruction is a CALL instuction. If it's a CALL instruction then put a temporary breakpoint on the instruction following it and continue execution till the execution stops (then remove it). In this case you effectively stepped over function calls literally in the assembly level and so in the source too.
No need to manage stack frames (unless you'll need to deal with single line recursive functions). This analogy can be applied to other architectures as well.
Ok, so since this seems to be a bit of black magic, in this particular case the most intelligent thing was to enumerate the instruction where the next line starts (or the instruction stream ends + 1), and then run that many instructions before halting again.
The only gotcha was that I have to keep track of the stack frame in case CALL is executed; those instructions should run without counting in case of step-over.
I have a personal elisp function that performs an multi-directory grep. It uses compilation-start, which creates a compilation-mode buffer with the results, in which I can press RET (bound to compile-goto-error) to jump to the corresponding location.
However, compile-goto-error always visits the location in another window, leaving the compilation buffer up. Half the time I am just searching for one particular location, so what I would like to do is bind some other key (say C-RET) to also visit the corresponding location in a buffer, but stay in the current window, replacing the compilation buffer with the location's buffer.
I've traced the relevant execution from compile-goto-error to next-error-internal to next-error-function to compilation-next-error-function to compilation-find-file, but can't find a nice place to hook in my differing behavior. Is there a simple way (or, failing that, a complicated one) to create a compile-goto-error variant that switches to the new buffer in-place in the window that held the compilation buffer?
I suggest just advising the compile-goto-error function to do the right thing, rather than creating a custom function and keybinding. The following does the right thing for me (following Stefan's suggestion):
(defadvice compile-goto-error (around my-compile-goto-error activate)
(let ((display-buffer-overriding-action '(display-buffer-reuse-window (inhibit-same-window . nil))))
ad-do-it))
I think you should be able to get what you want by let-binding display-buffer-overriding-action, something like:
(defun my-next-error ()
(interactive)
(let ((display-buffer-overriding-action '(display-buffer-same-window)))
(next-error)))
Im working on a source level debugger. The debug info available in elf
format. How could be 'step over' implemented?
The problem is at 'Point1', anyway I can wait for the
next source line (reading it from the .debug_line table).
Thanks
if (a == 1)
x = 1; //Point1
else if (a == 2)
x = 1;
z = 1;
I'm not sure I understand the question entirely, but I can tell you how GDB implements its step command.
Once control has entered a particular compilation unit, GDB reads that CU's debugging information; in particular, it reads the CU's portion of the .debug_line section and builds a table that maps instruction addresses to source code positions.
When the step begins, GDB looks up the source location for the current PC. Then it steps by machine instruction, looking up the source location of the new PC each time, until the source location changes. When the source location changes, the step is complete.
It also computes the frame ID—the base address of the stack frame, and the start address of the function—after each step, and checks if that has changed. If it has, that means that we've stepped into or returned from a recursive call, and the step is complete.
To see why it's necessary to check the frame ID as well as the source location, consider stepping through a call to the following function:
int fact(n) { if (n > 0) { return n * fact(n-1); } else return 1; }
Since this function is defined entirely on the same source line, stepping by instruction until the source line changes would step you through all the recursive calls without stopping. However, when we enter a new call to fact, the stack frame base address will have changed, indicating that we should stop. This gives us the following behavior:
fact (n=10) at recurse.c:4
(gdb) step
fact (n=9) at recurse.c:4
(gdb) step
fact (n=8) at recurse.c:4
GDB's next command combines this general behavior with appropriate logic for recognizing function calls and letting them return to completion. As before, one must use frame IDs in deciding when calls have truly returned to the original frame; and there are other complications.
It's worth thinking a bit about how to treat inlined instances of functions (which DWARF does describe). But that's a bit much for this question.
Not to discourage experimentation, but if I were beginning a debugger project, I would want to look at Apple's work-in-progress debugger, lldb, which is open source.