search for: memoization

My goal is simple: calcuate GC content of each sequence in a list of nucleotide sequences. I have figured out how to vectorize, but all my attempts at memoization failed. Can you show me how to properly memoize my function? There is a StackOverflow post on the subject of memoization, but it does not help me: http://stackoverflow.com/questions/7262485/options-for-caching-memoization-hashing-in-r I haven't been able to find any other discussions on this...

Hi, That''s a bit off topic but since I use Spork + Rspec... Well, my classes are reloaded between each test wave so Rails'' "memoize" method raises an error (which is expected, see code: http://rubydoc.info/docs/rails/3.0.0/ActiveSupport/Memoizable:memoize) Anyone resolved this issue with an elegant solution?

...+static int test_qemu (guestfs_h *g, struct qemu_data *data); static void parse_qemu_version (guestfs_h *g, struct qemu_data *data); static void read_all (guestfs_h *g, void *retv, const char *buf, size_t len); +/* This is saved in the qemu.stat file, so if we decide to change the + * test_qemu memoization format/data in future, we should increment + * this to discard any memoized data cached by previous versions of + * libguestfs. + */ +#define MEMO_GENERATION 1 + /** * Test qemu binary (or wrapper) runs, and do C<qemu -help> so we know * the version of qemu what options this qemu support...

This patch fixes an issue with protected methods becoming public if they are memoized. Looking for +1''s and/or a commit by core... https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/5695 Thanks. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to

Maybe this is because I''m missing something but it seems to me that asking users of a memoized method to know when the method needs to be reloaded is a bit backwards. To me it seems like whoever is messing with something that affects the results of the memoized function should be the one that after doing its work should call something like memoized_method(:reset). Thoughts? -- You

I was wondering what was the reasoning behind freezing the Memoizable return values? Thanks -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to

I''m using the One-click 1.8.7rc2 Ruby Windows installer, everything has been working fine up till now, when i want to start getting into testing, i got this error, any reason why? C:/Ruby/bin/ruby -Ilib;test "C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/ lib/rake/rake_test_loader.rb" "test/unit/word_test.rb" C:/Ruby/lib/ruby/1.8/erb.rb:469:in `scan'': You have a

...9;R CMD check'. Is there a mechanism in 'R CMD check' that makes this possible? If not, is there a way to detect that you are running via 'R CMD check', e.g. an R or an environment variable being set? The background for this is that some of my packages' examples are using memoization to cache computational expensive results (via the 'R.cache' package). These are cached to files which are by default stored under ~/.Rcache/. It turns out that these files live beyond the check cycle of the CRAN check servers, meaning that the next time the package is checked memoized re...

On Wed, Sep 26, 2018 at 06:36:47PM +0200, Pino Toscano wrote: > On Friday, 21 September 2018 11:53:52 CEST Richard W.M. Jones wrote: > > +/** > > + * Test if the qemu-img info command supports the C<-U> option to > > + * disable locking. The result is memoized in the handle. > > + * > > + * Note this option was added in qemu 2.11. We can remove this test

Hi, In my llvm code I want to create some function calls. The function prototype is as follows: int memoize ( char *function_name, int *int_params, unsigned num_ints, double *double_params, unsigned num_doubles) In order to create these calls I do the following for example: %88 = alloca [7 x i8] store volatile [7 x i8] c"ORACLE\00", [7 x i8]*

...remely unlikely (*) that they would generate a file that would pass as valid by readRDS()? (*) extremely unlikely = if all of us would run this toy example we would not end up with a non-detect but still corrupt "foo.rds" file in, say, 10000 years. Background: The R.cache package allows memoization (caching of results) to file such that the cache is persistent across R sessions. The persistent part is achieved by writing cache files to the same file directory. This is safe when you run a single process, and even if readRDS() would fail to read a cache file it is no big deal; the memoization...

Instead of save every time there's a new element in the cache, batch the saving to disk every 100 changes, saving the unsaved remainder at the exit. While not a big optimization, this reduces a bit the disk usage during generator run. --- generator/utils.ml | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/generator/utils.ml b/generator/utils.ml index

https://bugs.launchpad.net/qemu/+bug/1740364 --- lib/guestfs-internal.h | 3 +++ lib/handle.c | 2 ++ lib/info.c | 39 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 44 insertions(+) diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h index adeb9478a..c66c55e70 100644 --- a/lib/guestfs-internal.h +++ b/lib/guestfs-internal.h @@ -510,6 +510,9 @@ struct

...lts for SCEVComplexityCompare appears to help significantly but that is much harder to do with things like properlyDominates. Is anyone actively looking at LSR compile time issues? LLVM 2.7 is taking on the order of 30 minutes to optimize some very simple test cases and that's after doing the memoization work for SCEVComplexityCompare. TOT has the same problem. -Dave

On Thursday, 4 October 2018 14:50:07 CEST Richard W.M. Jones wrote: > On Thu, Oct 04, 2018 at 01:34:59PM +0100, Richard W.M. Jones wrote: > > On Wed, Sep 26, 2018 at 06:36:47PM +0200, Pino Toscano wrote: > > > On Friday, 21 September 2018 11:53:52 CEST Richard W.M. Jones wrote: > > > > +/** > > > > + * Test if the qemu-img info command supports the

Hi I have mailed about this previously, but back then it was not really confirmed, so I have let it be at that. Anyhow, problem is that for some reason 2.5/2.6 ext3 with HTREE support do not like what perl-5.8.0 does during installation. It *seems* like one of the temporary files created during manpage installation do not get unlinked properly, or gets into the hash (this possible?) and cause

Stack colouring should be able to reuse the same stack space, if the live ranges of the pointers don't overlap. But I don't think anyone has built a general solution for alloca'd space. On Mon, Nov 4, 2013 at 6:30 AM, Ali Javadi <aj14889 at yahoo.com> wrote: > Hi, > > In my llvm code I want to create some function calls. The function > prototype is as follows: >

On Friday, 21 September 2018 11:53:52 CEST Richard W.M. Jones wrote: > +/** > + * Test if the qemu-img info command supports the C<-U> option to > + * disable locking. The result is memoized in the handle. > + * > + * Note this option was added in qemu 2.11. We can remove this test > + * when we can assume everyone is using qemu >= 2.11. > + */ > +static int >

...we don’t stop the traversal in a header-phi, then we’d have a situation where we haven’t memoized the result of AddUsersImpl(%1) yet when calling AddUsersImpl(%1) for the second time — because we’re still trying to determine what AddUsersImpl(%1) will return in the first call. Depending on how the memoization is implemented, the result is either an infinite loop, or a potentially inconsistent result. I can’t really comment on whether there’s value in having the SCEVs of %iv2 and %0 in the IVUsers list for this example. I genuinely don’t know whether there is or is not. As a point that indicates to me,...

On Thu, Oct 04, 2018 at 01:34:59PM +0100, Richard W.M. Jones wrote: > On Wed, Sep 26, 2018 at 06:36:47PM +0200, Pino Toscano wrote: > > On Friday, 21 September 2018 11:53:52 CEST Richard W.M. Jones wrote: > > > +/** > > > + * Test if the qemu-img info command supports the C<-U> option to > > > + * disable locking. The result is memoized in the handle.