search for: normatively

Hello, I am new to R and hope I will not seem ignorant in this post. I am currently using the plspm package by Gaston Sanchez accompanied by his text book. I have attempted to create a square matrix, which has seemed successful. I used the following code: > "Attitude" = c(1, 0, 0, 0, 0, 0, 0, 0) > "Normative Beliefs" = c(1, 0, 0, 0, 0, 0, 0, 0) > "Subjective

Hello, Please allways cc the list, don't answer just to me. Now I'm getting a different error. I had noticed that you have no reference to 'TPBDATA' before the call to plspm but I forgot to mention it in my first e-mail. TPB_pls1 = plspm(TPBDATA, TPB_path, TPB_blocks, modes = TPB_modes) Error in is_tabular(x) : object 'TPBDATA' not found So we need to know what

Yes, I would hate for some library implementer to either interpret the standard differently or simply not consider the issue of recursive parallelism at all and end up with an implementation that doesn't support it (not that unlikely considering it went 1.5 years through committee as you said and the topic never came up). On Wed, May 17, 2017 at 7:25 AM Bryce Lelbach <balelbach at

Hello all, I''m new to prototype and javascript isn''t my strong point. I''m trying to get a simple test script to work, which is turning out to be a little harder than I thought. I have a bunch of fields that I need to be able to switch on and off using one of a few hashes. In the example below I''m trying to get one to work. The problem occurs when I try to

> On Jul 23, 2018, at 3:40 PM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 23 July 2018 at 11:56, Arsenault, Matthew via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> Hi, >> >> >> The specification for the llvm.minnum/llvm.maxnum intrinsics is too unclear >> right

Hi, The specification for the llvm.minnum/llvm.maxnum intrinsics is too unclear right now to usefully optimize. There are two problems. First the expected behavior for signaling NaNs needs to be clarified. Second, whether the returned value is expected to be canonicalized (as if by llvm.canonicalize). Currently according to the LangRef: Follows the IEEE-754 semantics for minNum, which also

Hi, While investigating the situation of visibility annotations and linkage in libc++ with the goal of removing uses of `__always_inline__`, Eric Fiselier and I stumbled upon the attached test case, which I don't think Clang compiles properly. Here's the gist of the test case, reduced to the important parts (see the attachment if you want to repro): // RUN: %cxx -shared -o

On 24/11/2012, at 10:21 PM, Nick Lewycky wrote: > > Passing an uninitialized value as a function argument is undefined behaviour on the spot, regardless of what the callee does (even if it never references that argument). Cite reference? No? Then you're guessing ;) > > That aside, there is no way that 'i' has the same value, since it has no value. This is definitely

On Fri, Mar 2, 2012 at 11:32 AM, Evandro Menezes <emenezes at codeaurora.org> wrote: ... > Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not > normative. See foot note 7 in the same page. Figure 3.4 on page 21 > confirms that the use of a frame-pointer is optional. > > So, if one doesn't use ENTER in the prologue and uses RSP to access local >

...t; wrote: > > This won’t happen with volatile load/store This is mostly true today, but AFAICT the LLVM memory model doesn’t actually offer this guarantee. It merely says that LLVM treats volatile like C / C++ treats volatile… which isn’t much of a guarantee because C / C++ volatile doesn’t normatively mean anything. Specifically, we cannot really honor this when volatile bitfields are used for which memory operations don’t exist: struct { volatile int a : 12; volatile int b : 4; } s; As things stand, we haven’t promised that we won’t combine adjacent volatile stores, and C / C++ certainly...

On 11/24/2012 04:14 AM, john skaller wrote: > > On 24/11/2012, at 10:21 PM, Nick Lewycky wrote: > >> >> Passing an uninitialized value as a function argument is undefined behaviour on the spot, regardless of what the callee does (even if it never references that argument). > > Cite reference? No? Then you're guessing ;) This is a rule in C++ that I'm not sure

Dear Experts, I am new to the mailing list. I have an experience of 4 years working on MPEG Audios - MP3, AAC, AAC+. I was interested with Ogg Vorbis because of its unique way of encoding. I want to get documentation on Ogg Vorbis Encoding and Decoding procedures ( step by step as for a developer). Thanks in advance, Rgds Datta __________________________________________________ Do You

Hi, I'm working on porting libopus and I'd like to get information how to test Opus Encoder properly. There is information in RFC6716, that Opus Decoder's test files (http://opus-codec.org/testvectors/opus_testvectors.tar.gz) were created specifically to exercise all aspects of the decoder. Using these files, a custom implementation of libopus can be verified to be sure the Opus

...t;> ??Is there any test files created specifically to exercise all aspects >> ??of the encoder? If not, can you recommend some steps to verify a >> ??custom implementation of libopus in encoding mode ? > ?There is no test for the encoder because unlike the decoder, it is not > ?normatively specified and it keeps improving over time. The best way to > ?check your encoder for non-bit-exact numerical issues is to use a tool > ?like PQevalAudio: > ?http://www-mmsp.ece.mcgill.ca/documents/Downloads/PQevalAudio/ > > ?Cheers, > > ?????????Jean-Marc > ?_______________...

Cameron, Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not normative. See foot note 7 in the same page. Figure 3.4 on page 21 confirms that the use of a frame-pointer is optional. So, if one doesn't use ENTER in the prologue and uses RSP to access local variables, RBP may be used as a calee-saved GPR. -- Evandro Menezes Austin, TX emenezes at

On Fri, Mar 02, 2012 at 11:58:29AM -0500, Cameron McInally wrote: > On Fri, Mar 2, 2012 at 11:32 AM, Evandro Menezes <emenezes at codeaurora.org> > wrote: > ... > > Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not > > normative. See foot note 7 in the same page. Figure 3.4 on page 21 > > confirms that the use of a frame-pointer is optional.

> > At least for 32bit x86 reserving another register as alternative frame > pointer is very heavy. The above would allow normal spill logic to > decide when to keep a reference in register and when not. It also reuses > existing functionality as much as possible. > Hi Joerg, Yes, this was a problem in my implementation also. Empirically, for the chips I work on, reserving the

On 11/24/2012 02:08 AM, Jakub Staszak wrote: > Hello, > > I was wondering about the case below. I tried to find any information in C standard, but I found nothing. > In this case, variable "i" is uninitialized, but it is the _same_ value passed as an argument, so only of "a" or "b" should be printed. > > What I found is that with -O2: > LLVM

Hi List; Where I determine the codec to be used for the SIP Trunk (between Asterik and another SIP softswitch)? Regards Bilal ____________________________________________________________________________________ Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433

Hello, I was wondering about the case below. I tried to find any information in C standard, but I found nothing. In this case, variable "i" is uninitialized, but it is the _same_ value passed as an argument, so only of "a" or "b" should be printed. What I found is that with -O2: LLVM (trunk) prints both "a" and "b" GCC (4.2) prints both