search for: precomputed

I see there are still some floating point operations left in the codec init(ialization) code. Changing that code to fixed point is not only difficult (due to the trigonometric functions etc) but may also degrade the precision. Here is an idea whereby we can easily precompute (record) all those values on a powerful processor and then use (replay) them on an embedded processor / DSP. The only

Firstly, running for more channels will not break my hack. All that's needed is to call RECOPLAY_MARK with different identifiers (say nb, wb or uwb) before doing the appropriate initialization. Secondly, my attempts to do the Gaussian in fixed point went like this : Define a new constant lag_factor_gauss that is manually set equal to exp(sqr(2*M_PI*lag_factor)/-2) by whoever changes the

On 5/30/2008 11:40 AM, rocket at google.com wrote: > I've run into a scoping problem in R. No, in your use of it. > I'm calling a function that > * creates a formula ... incorrectly. > * calculates a weight vector > * calls lm with that formula and weights > This fails. > > Here's a simplified reproduce example: > # f works, g doesn't, h is

I've run into a scoping problem in R. I'm calling a function that * creates a formula * calculates a weight vector * calls lm with that formula and weights This fails. Here's a simplified reproduce example: # f works, g doesn't, h is a workaround rm(w) data <- data.frame(y=runif(20), x=runif(20), z=runif(20)) f <- function(k){ w <- data$z^k coef(lm(y~x, data

Am Donnerstag, den 03.04.2008, 19:29 -0700 schrieb Chris Lattner: > On Apr 2, 2008, at 9:54 AM, Dominic Hamon wrote: > > > Would it be reasonable for me to submit a patch whereby [...] the > > LLVMFoldingBuilder methods become virtual overrides of the base > > class methods? > > No, please don't do this. The idea of llvmbuilder is that it is a >

Aki Tuomi wrote: > The use of salt, today, is to prevent the attacker from directly seeing > who has same passwords. Of course it also will make a rainbow table > attack less useful, Not just less useful, but almost infeasible. Given the use of random salts, you would have to generate (number of possible salts) rainbow tables. This drastically changes the CPU/storage tradeoffs. >

On Thu, 28 May 2015, Hubert Kario wrote: > > If this is the only attack you're trying to address, and you've > > already limited yourself to safe primes, then NUMS properties don't > > really add anything. The NUMS approach is there are to try to avoid > > the possibility of other, unknown cryptanalytic attacks against some > > infrequent type of group,

Aside from the replay attacks discussed, there are some other attack vectors on the cookie_session store. I appreciate (and admire!) Jeremy''s good humor on all of this: > Planting the seed here led to quick ripening and plenty of pesticide. > Thanks for the fish, all. > > jeremy Anyway, here''s what we came up with: 1. Brute Force SHA512 can be computed _very_ fast.

...r("foo"): SEXP getFoo() { return mkChar("foo"); } The above implementation doesn't take advantage of the fact that mkChar("foo") could be pre-computed only once, and then the function would return the pre-computed value. So the question is how to create this precomputed value. The closest thing I could find in the sources is R_NaString, but I was not able to trace down how it comes about. Thanks, Vadim P.S. I was able to solve a similar problem with symbols. If I need a symbol "foo", I do static SEXP FooSymbol = install("foo");...

On 10/17/2012 9:04 AM, Duncan Sands wrote: > Unfortunately I have no idea how to implement this in a reasonable way. It should be possible to precompute the layout of the .ll file from the IR itself and then add self-annotations. It may require a special form of dumping the IR into a .ll file to make sure that empty lines, etc. are properly synchronized with the annotations. Wouldn't

A. Schulze writes: > precomputing ssl-params is also possible without patching but it's a > little bit tricky > ... > Long version in german: https://andreasschulze.de/dovecot/ssl-params Nice. (You should probably point out to ensure ssl_parameters_regenerate is zero, otherwise all this work will get wiped out!) Joseph Tam <jtam.home at gmail.com>

On Fri, 4 Apr 2008, Joachim Durchholz wrote: >> No, please don't do this. The idea of llvmbuilder is that it is a >> "free" wrapper around the other existing API calls. Making the >> methods virtual would make them much more expensive. > > Wouldn't the class of the objects be known at compile time in most > cases? This is essentially just a case of

On Tue, October 7, 2008 9:02 am, David Greene wrote: > On Tuesday 07 October 2008 00:32, Nicolas Capens wrote: > >> Anyway, this can definitely also be done with an analysis pass that >> provides information about ordering between loads and stores. It's just > > Actually, no it can't. See the thread about analysis passes depending on > other analysis passes and

Hello Matthias, On 28 July 2017 at 04:13, Matthias Braun <mbraun at apple.com> wrote: > It's not that hard in principle: > - A register class is a set of registers. > - Virtual Registers have a register class assigned. > - If you have register constraints (like x86 8bit operations only work on > al,ah,etc.) then you have to create a new register class to express that.

Also, how are default moduli shipped with OpenSSH for use in diffie-hellman-group-exchange-sha1/sha256 chosen? Are they chosen randomly by developers or are they chosen for security properties? If they are random, why not use moduli from RFC 7919 instead, like Mozilla recommends? On Fri, Feb 15, 2019 at 3:48 AM Mark D. Baushke <mdb at juniper.net> wrote: > > Yegor Ievlev <koops1997

HotSlots Webmaster <webmaster at hotslots132.com> writes: > I have had Dovecot working fine with SSL for nearly two years now. It's > time to renew the SSL certificate, so I did (same CA). The new > certificate works fine in Apache and Postfix. But when I update Dovecot > to use the same certificate, and restart the server, Dovecot stops > responding to connects. > ...

On Tuesday 07 October 2008 00:32, Nicolas Capens wrote: > Anyway, this can definitely also be done with an analysis pass that > provides information about ordering between loads and stores. It's just Actually, no it can't. See the thread about analysis passes depending on other analysis passes and when things do and don't get updated by PassManager.

Hi, Can anybody briefly explain the significance of the updated moduli file? Is this a critical update? Should all existing installations update their moduli file? Thanks in advance, -- Dan

On Wed, Sep 6, 2017 at 4:20 PM, Karol Herbst <karolherbst at gmail.com> wrote: >> In this instance, I think using multiplication is more intuitive >> than '&&', so I'm adding a comparison to zero instead to shut up >> the warning. To further improve readability, I also make the >> error case indented and leave the normal case as the final

...use some help explaining. The point of interest is between 'unreachableblockelim' and 'codegenprepare' passes. Here is the paste of IR after each pass http://pastebin.com/42xLT4ZN I've annotated 3 spots in the code with stars. In (1), after unreachableblockelim, addr89 is precomputed outside the loop once and is used in store in (2). However, in (3), after codegenprepare, there is now a bunch of math being done every loop iteration to get the address for the same store. Additionally, looks like the same thing is happening for several addresses above as well. Does this look rig...