[shifted_ptr] Neural networks

Greetings: I have made some changes into my sandbox and I am happy to say some tests send by Steven a while ago are now working correctly. The interface was previously supporting only allocations made by "new_sh". I was aware of this but now I am adding a solution to make shifted_ptr generic enough. The solution is still a non-portable one but will be corrected shortly; it consists of detecting the stack frame and I am using gcc's __builtin_frame_address(). I also replaced Nedmalloc for Boost.Pool because I temporarily wish to reduce problems I might face. The problem with Boost.Pool is that it doesn't handle arbitrary sized chunks and the complexity goes down to O(n) for array allocations. All in all shifted_ptr behaves differently when a pointer resides either on the: 1. stack & data segment 2. local heap 3. system heap Moreover the test file shifted_ptr_test3.cpp which uses BOOST_TEST macros is crashing on gcc for Windows. The same tests appears in shifted_ptr_test2.cpp and work correctly. Finally yes I definitely need to write documentation about this but I will basically need to write something similar to a book. For now I just want to present a working example and here it is. The ultimate objective of shifted_ptr is to handle neural networks for artificial intelligence testings so feel free using the pointer in your tests to help me finding flaws that might still exist. Regards, -Phil

"Phil Bouchard" <philippe@fornux.com> wrote in message news:g1jdel$fuj$1@ger.gmane.org... [...]
complexity goes down to O(n) for array allocations. All in all shifted_ptr behaves differently when a pointer resides either on the: 1. stack & data segment 2. local heap 3. system heap
[...] While thinking about it maybe I will reduce the distinction of all those segments down to local heap allocations only. This way there might be possible cyclicism when the pointer is used with standard containers using standard allocators we got more advantages because: - It doesn't uglyfies the code - shifted_ptr won't benefit from speedups - Wrapping containers using different allocator is easy: template <typename T> class sh_vector : public std::vector<T, boost::pool::sh_alloc> { ... }; I'll do that Sunday night. Thank you, -Phil
participants (1)
-
Phil Bouchard