Dear All, I have an issue with exhashmap, namely repeated erasing-insertion of elements eventually become trapped in an infinite loop in lines 487-491 of hash_map.h. Here is a sample code: #include <ginac/ginac.h> using namespace GiNaC; int main() { exhashmap<ex> M; M[realsymbol("x")] =1; int N= 30; for (int i =0; i < N; ++i ) { realsymbol a("a"); M[a]=numeric(i); M.erase(a); } return 0; } With this value of N the infinite loop appears on my computer with a probability around 40%. With larger values of N an infinite loop is almost certain. Did I miss something? Best wishes, Vladimir PS Also just to check that my patch for archiving empty lists from Sep 10 is not lost. -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/ Jupyter (Colab): https://github.com/vvkisil/MoebInv-notebooks Jupyter (CodeOcean): http://doi.org/10.24433/CO.9934595.v3
Dear Vladimir, On 19.09.19 17:06, Vladimir V. Kisil wrote:
I have an issue with exhashmap, namely repeated erasing-insertion of elements eventually become trapped in an infinite loop in lines 487-491 of hash_map.h. Here is a sample code:
#include <ginac/ginac.h> using namespace GiNaC;
int main() { exhashmap<ex> M;
M[realsymbol("x")] =1; int N= 30;
for (int i =0; i < N; ++i ) { realsymbol a("a"); M[a]=numeric(i); M.erase(a); } return 0; }
With this value of N the infinite loop appears on my computer with a probability around 40%. With larger values of N an infinite loop is almost certain.
Did I miss something?
Class exhashmap<T> was a workaround for missing std::hash_map<Key, T> in the original C++98 standard. It was put in GiNaC because map<Key, T> was deemed too slow. Since C++11 there is std::unorderd_map<Key, T>, which is hash-based. Don't use that exhashmap. It should have been replaced years ago when we switched to C++11! The attached prelimiary patch should solve all these problems. Can you, please, test it with whatever you're doing?
PS Also just to check that my patch for archiving empty lists from Sep 10 is not lost.
Worry not! -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
Dear Richard, Many thanks for the clarification. Your patch is working for me as the part of GiNaC. Thus I have copied it to my code to make it exhashmap-independent for systems with older versions of GiNaC. Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/ Jupyter (Colab): https://github.com/vvkisil/MoebInv-notebooks Jupyter (CodeOcean): http://doi.org/10.24433/CO.9934595.v3
On Sun, 22 Sep 2019 02:08:36 +0200, "Richard B. Kreckel" <kreckel@in.terlu.de> said:
RK> Dear Vladimir, On 19.09.19 17:06, Vladimir V. Kisil wrote: >> I have an issue with exhashmap, namely repeated erasing-insertion >> of elements eventually become trapped in an infinite loop in >> lines 487-491 of hash_map.h. Here is a sample code: >> >> #include <ginac/ginac.h> using namespace GiNaC; >> >> int main() { exhashmap<ex> M; >> >> M[realsymbol("x")] =1; int N= 30; >> >> for (int i =0; i < N; ++i ) { realsymbol a("a"); M[a]=numeric(i); >> M.erase(a); } return 0; } >> >> With this value of N the infinite loop appears on my computer >> with a probability around 40%. With larger values of N an >> infinite loop is almost certain. >> >> Did I miss something? RK> Class exhashmap<T> was a workaround for missing RK> std::hash_map<Key, T> in the original C++98 standard. It was put RK> in GiNaC because map<Key, T> was deemed too slow. Since C++11 RK> there is std::unorderd_map<Key, T>, which is hash-based. RK> Don't use that exhashmap. It should have been replaced years ago RK> when we switched to C++11! RK> The attached prelimiary patch should solve all these RK> problems. Can you, please, test it with whatever you're doing? >> PS Also just to check that my patch for archiving empty lists >> from Sep 10 is not lost. RK> Worry not! RK> -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/> RK> _______________________________________________ GiNaC-devel RK> mailing list GiNaC-devel@ginac.de RK> https://www.cebix.net/mailman/listinfo/ginac-devel
participants (2)
-
Richard B. Kreckel
-
Vladimir V. Kisil