Numerical imprecision stdp #924

suku248 · 2018-04-09T13:28:58Z

This PR is a temporary fix for issue #894

…sion_stdp

heplesser

@suku248 Looks good, I have mostly comments on code formatting and one comment that confuses me. How difficult would it be to create a test for this issue?

heplesser · 2018-04-09T13:59:45Z

models/stdp_dopa_connection.h

@@ -452,7 +452,8 @@ STDPDopaConnection< targetidentifierT >::process_dopa_spikes_(
  // process dopa spikes in (t0, t1]
  // propagate weight from t0 to t1
  if ( ( dopa_spikes.size() > dopa_spikes_idx_ + 1 )
-    && ( dopa_spikes[ dopa_spikes_idx_ + 1 ].spike_time_ <= t1 ) )
+    && ( t1 - dopa_spikes[ dopa_spikes_idx_ + 1 ].spike_time_ > -1.0
+           * kernel().connection_manager.get_stdp_eps() ) )


Could you try to get the -1.0 on the same line as kernel()....? I think that would be good for legibility.

I am afraid the coding style guidelines do not permit this.

heplesser · 2018-04-09T13:59:55Z

models/stdp_dopa_connection.h

@@ -468,7 +469,8 @@ STDPDopaConnection< targetidentifierT >::process_dopa_spikes_(
    // process remaining dopa spikes in (t0, t1]
    double cd;
    while ( ( dopa_spikes.size() > dopa_spikes_idx_ + 1 )
-      && ( dopa_spikes[ dopa_spikes_idx_ + 1 ].spike_time_ <= t1 ) )
+      && ( t1 - dopa_spikes[ dopa_spikes_idx_ + 1 ].spike_time_ > -1.0
+                * kernel().connection_manager.get_stdp_eps() ) )


Could you try to get the -1.0 on the same line as kernel()....? I think that would be good for legibility.

Again, not possible due to coding style guidelines.

heplesser · 2018-04-09T14:03:21Z

models/stdp_dopa_connection.h

-                               // occur at the same time
+    // only depression if pre- and postsyn. spike occur at the same time
+    if ( t_spike - start->t_ > 1.0
+        * kernel().connection_manager.get_stdp_eps() )


I would drop the multiplication with 1.0. I also don't understand the comment: the comment talks about pre- and post-spike being at the same time, but then you facilitate only if there is a non-zero time difference. Your code does the same thing as the original code, so my confusion also applies to the comment in the original code.

I agree and have removed the 1.0.

The comment is misleading as it's about synaptic depression. I have adjusted it such that it explains that facilitation is skipped in case of 0 temporal difference between pre- and post spike.

heplesser · 2018-04-09T14:04:00Z

nestkernel/archiving_node.cpp

-        runner != history_.end() && runner->t_ <= t_first_read;
+        runner != history_.end()
+          && ( t_first_read - runner->t_ > -1.0
+                 * kernel().connection_manager.get_stdp_eps() );


Could you try to get the -1.0 on the same line as kernel()....? I think that would be good for legibility.

Again, not possible due to coding style guidelines.

heplesser · 2018-04-09T14:04:09Z

nestkernel/archiving_node.cpp

@@ -100,7 +109,8 @@ nest::Archiving_Node::get_K_value( double t )
  int i = history_.size() - 1;
  while ( i >= 0 )
  {
-    if ( t > history_[ i ].t_ )
+    if ( t - history_[ i ].t_ > 1.0
+        * kernel().connection_manager.get_stdp_eps() )


Could you try to get the -1.0 on the same line as kernel()....? I think that would be good for legibility.

It's a +1.0 and I have removed it.

heplesser · 2018-04-09T14:04:32Z

nestkernel/archiving_node.cpp

-    while ( ( runner != history_.end() ) && ( runner->t_ <= t2 ) )
+    while ( ( runner != history_.end() )
+      && ( t2 - runner->t_ > -1.0
+                * kernel().connection_manager.get_stdp_eps() ) )


Could you try to get the -1.0 on the same line as kernel()....? I think that would be good for legibility.

Again, not possible due to coding style guidelines.

heplesser · 2018-04-09T14:04:51Z

nestkernel/archiving_node.cpp

@@ -126,7 +136,8 @@ nest::Archiving_Node::get_K_values( double t,
  int i = history_.size() - 1;
  while ( i >= 0 )
  {
-    if ( t > history_[ i ].t_ )
+    if ( t - history_[ i ].t_ > 1.0
+        * kernel().connection_manager.get_stdp_eps() )


Drop multiplication by 1.0?

Yes, thanks, done.

heplesser · 2018-04-09T14:05:32Z

nestkernel/connection_manager.h

@@ -419,6 +423,10 @@ class ConnectionManager : public ManagerInterface

  //! Capacity growth factor to use beyond the limit
  double large_connector_growth_factor_;
+
+  //! Maximum distance between (double) spike times in STDP that is
+  //! still considered 0


I think it would be useful to refer to the issue here.

Yes, you are right. Done.

heplesser · 2018-04-09T14:06:11Z

nestkernel/nestmodule.cpp

+ * Set epsilon that is used for comparing spike times in STDP.
+ * Spike times in STDP synapses are currently represented as double
+ * values. The epsilon defines the maximum distance between spike
+ * times that is still considered 0.


Maybe add a Note: See issue ...?

Yes, good point. Done.

heplesser · 2018-04-09T14:07:58Z

nestkernel/nestmodule.cpp

@@ -1794,6 +1812,9 @@ NestModule::init( SLIInterpreter* i )
    "GetStructuralPlasticityStatus", &getstructuralplasticitystatus_function );
  i->createcommand( "Disconnect", &disconnect_i_i_lfunction );
  i->createcommand( "Disconnect_g_g_D_D", &disconnect_g_g_D_Dfunction );
+
+  i->createcommand( "SetStdpEps", &setstdpeps_dfunction );


Should we have a GetStdpEps function, too? Or maybe "hide" this in the kernel status dict after all?

No, I don't think that we want a GetStdpEps. As this is a temporary fix, I would not like to make the variable visible in the kernel dict. I have added an info message to SetStdpEps though, which states the new value of stdp_eps and I have added two checks.

- Remove unnecessary multiplications with 1.0 - Add checks and info output for SetStdpEps - Refer to issue nest#894 in comments

suku248 · 2018-04-11T08:19:13Z

Thank you @heplesser for the review!
Please have a look at the new commit.

hakonsbm

@suku248 Looks pretty good to me. I just have a couple comments.

hakonsbm · 2018-04-11T09:12:41Z

models/stdp_dopa_connection.h

@@ -565,8 +567,9 @@ STDPDopaConnection< targetidentifierT >::send( Event& e,
    process_dopa_spikes_( dopa_spikes, t0, start->t_ + dendritic_delay, cp );
    t0 = start->t_ + dendritic_delay;
    minus_dt = t_last_update_ - t0;
-    if ( start->t_ < t_spike ) // only depression if pre- and postsyn. spike
-                               // occur at the same time
+    // faciltate only in case of post- after presyn. spike


Should be "facilitate".

Thanks, fixed!

hakonsbm · 2018-04-11T09:13:23Z

models/stdp_pl_connection_hom.h

@@ -58,6 +58,8 @@

 // C++ includes:
 #include <cmath>
+#include <iomanip>
+#include <limits>


As far as I can see these aren't needed anywhere.

That's correct. I have removed them.

hakonsbm · 2018-04-11T09:14:17Z

nestkernel/archiving_node.cpp

@@ -29,6 +29,13 @@

 #include "archiving_node.h"

+// C++ includes:
+#include <iomanip>
+#include <limits>


As far as I can see these aren't needed anywhere.

That's correct. I have removed them.

suku248 · 2018-04-11T09:36:14Z

Thank you @hakonsbm for the comments!

aserenko · 2018-04-26T11:31:08Z

@suku248, could you possibly be so kind to have a look at

nest-simulator/models/stdp_connection_facetshw_hom.h

Line 507 in 79bbbb0

if ( minus_dt != 0 )

?

Firstly, there is also a direct comparison to zero that should be corrected in the same way.

The second question is a bit deeper. As far as I understand, now that you have changed nestkernel/archiving_node.cpp, the Archiving_Node::get_history() does not return events with time equal to its start time argument t1. And so, events that would lead to accounting coinciding (zero-delta-t) spike pairs can never be returned by get_history.
That way, the behaviour of this very model that I was wanting to discuss in issue #861 seem to have been changed to the way I argued for in that issue. Do you too think it has?

suku248 · 2018-04-30T13:01:29Z

Yes, you are right. I have simply overlooked stdp_connection_facetshw_hom.h.

I am not really familiar with this model. Do you have some experience with the model and do you think you could correct the comparisons of double values for this model and then generate a PR? That would be great.

I think, it's possible that this will solve #861

PR nest#924 fixed direct comparison of delta_t to zero in STDP. Among other things, that PR added the assertion minus_dt < 1.0 * stdp_numerical_imprecision to all spike-timing-dependent plasticity models. Except stdp_facetshw synapse, which is fixed in this commit. In stdp_facetshw synapse the direct comparison to zero was acceptable, because of the initialization double minus_dt = 0; double plus_dt = 0; So, the direct comparison to zero here just checks if `minus_dt` or `plus_dt` retain their initial values, which basically means the same as checking `if ( start != finish )`. Still, I remove the comparison to zero for clarity, since it is redundant.

aserenko · 2018-05-04T14:38:05Z

Sorry, mostly a false alarm. There was an initialization a few lines higher:

  double minus_dt = 0;
  double plus_dt = 0;

So, now (as soon as the current PR has been merged) the direct comparison to zero here just checks if minus_dt or plus_dt retain their initial values, which basically means the same as checking if ( start != finish ).

Still, I could not resist the temptation to mess with the code and opened a PR (#952) anyway. However, it is not that necessary, and I won't mind if it is rejected.

PR nest#924 fixed direct comparison of delta_t to zero in STDP. Among other things, that PR added the assertion minus_dt < 1.0 * stdp_numerical_imprecision to all spike-timing-dependent plasticity models. Except stdp_facetshw synapse, which is fixed in this commit. In stdp_facetshw synapse the direct comparison to zero was acceptable, because of the initialization double minus_dt = 0; double plus_dt = 0; So, the direct comparison to zero here just checks if `minus_dt` or `plus_dt` retain their initial values, which basically means the same as checking `if ( start != finish )`. Still, I remove the comparison to zero for clarity, since it is redundant.

Susanne Kunkel added 4 commits February 22, 2018 10:31

Expose numerical imprescision in synaptic plasticity

76f7f82

Temporary fix for imprecision in synaptic plasticity

c0d8869

Merge remote-tracking branch 'upstream/master' into numerical_impreci…

3727de3

…sion_stdp

Use kernel variable for epsilon needed in STDP

005e957

heplesser requested review from hakonsbm and heplesser April 9, 2018 13:57

heplesser requested changes Apr 9, 2018

View reviewed changes

heplesser added this to the NEST 2.16 milestone Apr 10, 2018

Clean up for SetStdpEps

8604e22

- Remove unnecessary multiplications with 1.0 - Add checks and info output for SetStdpEps - Refer to issue nest#894 in comments

heplesser approved these changes Apr 11, 2018

View reviewed changes

hakonsbm suggested changes Apr 11, 2018

View reviewed changes

Remove unnecessary includes and fix typo

85fdbea

hakonsbm approved these changes Apr 11, 2018

View reviewed changes

abigailm merged commit e5a9cad into nest:master Apr 11, 2018

heplesser mentioned this pull request Apr 13, 2018

Direct comparison of floating point numbers in STDP #894

Closed

aserenko mentioned this pull request Apr 26, 2018

Add STDP synapses with nearest-neighbor spike pairing schemes #865

Merged

suku248 mentioned this pull request May 4, 2018

Strange handling of zero-delta-t spike pairs in STDP in stdp_facetshw - innocent spikes get thrown away #861

Closed

aserenko mentioned this pull request May 4, 2018

Make stdp_facetshw synapse consistent with the temporal fix for STDP numerical imprecision #952

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Numerical imprecision stdp #924

Numerical imprecision stdp #924

suku248 commented Apr 9, 2018

heplesser left a comment

heplesser Apr 9, 2018

suku248 Apr 11, 2018

heplesser Apr 9, 2018

suku248 Apr 11, 2018

heplesser Apr 9, 2018

suku248 Apr 11, 2018

heplesser Apr 9, 2018

suku248 Apr 11, 2018

heplesser Apr 9, 2018

suku248 Apr 11, 2018

heplesser Apr 9, 2018

suku248 Apr 11, 2018

heplesser Apr 9, 2018

suku248 Apr 11, 2018

heplesser Apr 9, 2018

suku248 Apr 11, 2018

heplesser Apr 9, 2018

suku248 Apr 11, 2018

heplesser Apr 9, 2018

suku248 Apr 11, 2018

suku248 commented Apr 11, 2018

hakonsbm left a comment

hakonsbm Apr 11, 2018

suku248 Apr 11, 2018

hakonsbm Apr 11, 2018

suku248 Apr 11, 2018

hakonsbm Apr 11, 2018

suku248 Apr 11, 2018

suku248 commented Apr 11, 2018

aserenko commented Apr 26, 2018

suku248 commented Apr 30, 2018 •

edited

Loading

aserenko commented May 4, 2018

Numerical imprecision stdp #924

Numerical imprecision stdp #924

Conversation

suku248 commented Apr 9, 2018

heplesser left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

suku248 commented Apr 11, 2018

hakonsbm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

suku248 commented Apr 11, 2018

aserenko commented Apr 26, 2018

suku248 commented Apr 30, 2018 • edited Loading

aserenko commented May 4, 2018

suku248 commented Apr 30, 2018 •

edited

Loading