similar to: Arithmetic bug? (found when use POSIXct) (PR#10776)

Hi Can anyone tell me how to convert an image file (a jpg file for instance) into a matrix file? The command image(blabla) transforms a matrix into an image file, I am searching exactly the inverse. Thanks... [[alternative HTML version deleted]]

I have a data frame called "pose": DESCRIPTION QUANITY CLOSING.PRICE 1 WHEAT May/10 1 467.75 2 WHEAT May/10 2 467.75 3 WHEAT May/10 1 467.75 4 WHEAT May/10 1 467.75 5 COTTON NO.2 May/10 1 78.13 6 COTTON NO.2 May/10 3 78.13 7 COTTON NO.2 May/10 1 78.13

Full_Name: Barry Rowlingson Version: 1.6.0 OS: RH8 i386 Submission from: (NULL) (148.88.136.205) Strange things happen if I premultiply a difftime() object with a number. Example: > d1 <- difftime(Sys.time(),Sys.time()) > d2 <- 1 * difftime(Sys.time(),Sys.time()) > d3 <- difftime(Sys.time(),Sys.time()) * 1 > d1 Time difference of 0 secs - thats fine > d2 [1] 0

https://bugzilla.samba.org/show_bug.cgi?id=10776 Summary: SIGSEGV in utf8_internal_loop() Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: mluscon at redhat.com

Dear list, Consider the following, library(grid) w = unit.c(unit(1, "in"), unit(2, "in")) w2 = w + unit(1, "mm") w[2] <- 0 w2[2] <- 0 convertUnit(w, "mm") #[1] 25.4mm 0mm convertUnit(w2, "mm") #Error in grid.Call("L_convert", x, as.integer(whatfrom), as.integer(whatto), : # INTEGER() can only be applied to a

Mike Silbersack wrote: > On Tue, 16 Sep 2003, Scott Long wrote: > > >>Patches have been floated on the mailing list that revert PAE in its >>various stages. Maybe those need to be brought back up. Silby? Tor? >> >>Scott > > > I believe that Tor's commit on August 30th resolved the PAE-related > problems, so there is no need for a reversion.

Could someone please tell me how to escape the ''division'' arithmetic symbol in a model or controller? I''ve searched around and cannot find a solution. I''ve got the following in my model: def avg_risk t = 0 self.audits.each{|key| t = t + key.control_rating } t = t / self.audits.count #this line doesn''t work... I''ve even

I'm an old APL fossil and I got used to work with nested arrays there. In APL(2) you can write 1+(1 2 3)(4 5 6 7 8 9) and get (2 3 4)(5 6 7 8 9 10). A similar concept is R's lists. So it takes me by surprise to learn that 1+list(1:3,4:9) delivers an Error in 1 + list(1:3, 4:9) : non-numeric argument to binary operator Is there any particular reason why this doesn't work

Not sure if you guys want these patches, should I just turn off -Wpointer-arith in the PPC build or everyone else can turn it on? Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com> --- diff -r 66cd49a0e239 xen/drivers/video/vga.c --- a/xen/drivers/video/vga.c Fri Aug 18 13:30:01 2006 -0400 +++ b/xen/drivers/video/vga.c Fri Aug 18 13:43:30 2006 -0400 @@ -185,17 +185,17 @@ static inline

%foo1 = constant <4 x float> <float 1.0, float 2.0, float 3.0, float 4.0>; void %main() { %x = mul <4 x float> %foo1, %foo1 ret void } llvm-as complained " Reference to an invalid definition: 'foo1' of type '<4 x float>' ". I searched all test script in llvm/test, and I found the only way to use packed constant is: %foo1 = uninitialized

On Mar 25, 2008, at 8:25 PM, Jonathan S. Shapiro wrote: > In looking at the LLVM reference manual, it is conspicuous that (a) > the > IR does not define condition codes, and (b) the IR does not define > opcodes that return condition results in addition to their > computational > results. We currently don't have this because noone has implemented it yet. It would be

Hi, > There would appear to be three approaches: > > 1. Introduce a CC register class into the IR. This seems to be a > fairly major overhaul. > > 2. Introduce a set of scalar and fp computation quasi-instructions > that accept the same arguments as their computational counterparts, > but produce *only* the condition code. For example: > >

On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > I want to background process this for a bit, but it would be helpful to > discuss some approaches first. > > There would appear to be three approaches: > > 1. Introduce a CC register class into the IR. This seems to be a > fairly major overhaul. > > 2. Introduce a set of scalar and fp computation quasi-instructions

Hi Chris, > Why not define an "add with overflow" intrinsic that returns its value and > overflow bit as an i1? what's the point? We have this today with apint codegen (if you turn on LegalizeTypes). For example, this function define i1 @cc(i32 %x, i32 %y) { %xx = zext i32 %x to i33 %yy = zext i32 %y to i33 %s = add i33 %xx, %yy %tmp = lshr i33 %s, 32 %b = trunc

On Wed, 26 Mar 2008, Duncan Sands wrote: > Hi Chris, > >> Why not define an "add with overflow" intrinsic that returns its value and >> overflow bit as an i1? > > what's the point? We have this today with apint codegen (if you turn on > LegalizeTypes). For example, this function The desired code is something like: foo: addl %eax, %ecx jo

On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: >> Why not define an "add with overflow" intrinsic that returns its value and >> overflow bit as an i1? > > Chris: > > I understand several simple ways to implement add with carry. Your > suggestion is one of them. What I'm trying to understand is how to > handle the conditional code issue generally.

On Wed, 2008-03-26 at 14:11 -0700, Chris Lattner wrote: > On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > >> Why not define an "add with overflow" intrinsic that returns its value and > >> overflow bit as an i1? > > > > Chris: > > > > I understand several simple ways to implement add with carry. Your > > suggestion is one of them. What

On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > I guess my take is that when faced with an architectural question that > you eventually may have to address in full, quick fixes tend to accrete > that have to be undone when you get around to the general solution, and > these make implementing the general thing harder -- unless you have > thought it out in advance and the quick

> > Don't forget prover. :-) > > Say on that note here's something that I want to see: a formal > semantics > for LLVM in for example higher order logic. This would probably > not be > that difficult. > > The problem that this solves is that current verified compiler efforts > appear to be highly specific to both the language and the target. > >

> Also, I think that a verified compiler is not the right goal. I think > that what we want is a verifying compiler. We are not interested in > whether the compiler is correct in any general sense. We are interested > in whether the transformations performed by the compiler during some > particular compilation are correct. My intuition is the same: translation validation sounds far