search for: fct2

...ample1$OBS2),fixed=TRUE) > levels(Sample1$OBS2) <- sub('3+',5,levels(Sample1$OBS2), fixed=TRUE) > levels(Sample1$OBS2) <- sub('3',4,levels(Sample1$OBS2),fixed=TRUE) > levels(Sample1$OBS2) <- sub('4-',3,levels(Sample1$OBS2),fixed=TRUE) > Sample1 FCT OBS FCT2 OBS2 1 1 5 1 7 2 2 4 2 6 3 3- 3+ 3 5 4 3 3 4 4 5 3+ 3- 5 3 6 4 2 6 2 7 5 1 7 1 All looks good, but as I do the following, I encounter an error. > Sample1$OBS2- Sample1$FCT2 [1] NA NA NA NA NA NA NA Warning message: - not meaningf...

...project? In other words, what do you mean by full and accurate stack frame? Without this definition, this is difficult to give you any feedback. In particular, I do not see what it means when we use inlining. E.g., what do you expect from code like this: static void fct1(…) { ... } static void fct2(…) { … fct1(…) ... } void fct3(…) { fct1(...) … fct2(…) … } Assuming everything is inlined in fct3, you get: void fct3(…) { …. 1. fct1_inst1… fct1_instN …. 2. fct2_inst1… fct2_instK 3. fct1_inst1… fct1_instN 4. fct2_instzK+1… fct2_instN ... } Does it mean you what...

...vileged one. There can also be virtual (or other runtime dispatch) calls in that path which prevent static analysis. Does that help clarify what we're looking for? Philip > E.g., what do you expect from code like this: > static void fct1(…) { > ... > } > > static void fct2(…) { > … > fct1(…) > ... > } > > void fct3(…) { > fct1(...) > … > fct2(…) > … > } > > Assuming everything is inlined in fct3, you get: > void fct3(…) { > …. > 1. fct1_inst1… fct1_instN > …. > 2. fct2_inst1… fct2_instK &gt...

...time dispatch) calls in that path which prevent static analysis. > > Does that help clarify what we're looking for? > > Philip > > >> E.g., what do you expect from code like this: >> static void fct1(…) { >> ... >> } >> >> static void fct2(…) { >> … >> fct1(…) >> ... >> } >> >> void fct3(…) { >> fct1(...) >> … >> fct2(…) >> … >> } >> >> Assuming everything is inlined in fct3, you get: >> void fct3(…) { >> …. >> 1. fct1...

Is there a known way to preserve a full and accurate stack trace while utilizing most of LLVM's optimization abilities? We are investigating using LLVM as a JIT for a language which requires the ability to generate an accurate stack trace from any arbitrary point(1) during the execution. I know that we can make this work by doing inlining externally, manually recording virtual frames,

...virtual (or other runtime dispatch) calls in that path > which prevent static analysis. > > Does that help clarify what we're looking for? > > Philip > > > E.g., what do you expect from code like this: > static void fct1(…) { > ... > } > > static void fct2(…) { > … > fct1(…) > ... > } > > void fct3(…) { > fct1(...) > … > fct2(…) > … > } > > Assuming everything is inlined in fct3, you get: > void fct3(…) { > …. > 1. fct1_inst1… fct1_instN > …. > 2. fct2_inst1… fct2_instK &...

...t; >> Does that help clarify what we're looking for? >> >> Philip >> >> >>> E.g., what do you expect from code like this: >>> static void fct1(…) { >>> ... >>> } >>> >>> static void fct2(…) { >>> … >>> fct1(…) >>> ... >>> } >>> >>> void fct3(…) { >>> fct1(...) >>> … >>> fct2(…) >>> … >>> } >>> >>> Assuming eve...

Hi, Here is a small C++ program: vec.cc: #include <cmath> using v4f32 = float __attribute__((__vector_size__(16))); v4f32 fct1(v4f32 x) { return 1.0 / x; } v4f32 fct2(v4f32 x) { return __builtin_ia32_rcpps(x); } Which is compiled to: vec.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <_Z4fct1Dv4_f>: 0: c4 e2 79 18 0d 00 00 vbroadcastss 0x0(%rip),%xmm1 # 9 <_Z4fct1Dv4_f+0x9> 7: 00 00 9: c5 f0 5e c...

...> Here is a small C++ program: > > > > vec.cc: > > > > #include <cmath> > > > > using v4f32 = float __attribute__((__vector_size__(16))); > > > > v4f32 fct1(v4f32 x) > > { > > return 1.0 / x; > > } > > > > v4f32 fct2(v4f32 x) > > { > > return __builtin_ia32_rcpps(x); > > } > > > > Which is compiled to: > > > > vec.o: file format elf64-x86-64 > > > > > > Disassembly of section .text: > > > > 0000000000000000 <_Z4fct1Dv4_f>: > &...

...-function-calls I decided to write the following C++ program: #include <cmath> using v4f32 = float __attribute__((__vector_size__(16))); v4f32 fct1(v4f32 x) { v4f32 y; y[0] = std::sin(x[0]); y[1] = std::sin(x[1]); y[2] = std::sin(x[2]); y[3] = std::sin(x[3]); return y; } v4f32 fct2(v4f32 x) { v4f32 y; for (int i = 0; i < 4; ++i) y[i] = std::sin(x[i]); return y; } void fct3(float *x) { #pragma clang loop vectorize(enable) for (int i = 0; i < 16; ++i) x[i] = sinf(x[i]); } Which I compiled with: clang++ -O3 -march=native -mtune=native -c -o vec.o vec.cc -...

...because he wanted to do exactly what Hadley is describing (i.e., concatenation as character with levels as a union of the levels), and he was surprised because... well, the behaviour of c.factor is quite surprising if you don't read the manual. BTW, the solution proposed was unlist(list(fct1, fct2)). [1] https://www.mail-archive.com/r-help at r-project.org/msg38360.html I?aki > > Best, > ~G > > On Wed, Aug 8, 2018 at 8:54 AM, Martin Maechler <maechler at stat.math.ethz.ch> > wrote: > > > >>>>> Hadley Wickham > > >>>>>...

I have the data similar to the following in a data frame: LastName Department Salary 1 Johnson IT 56000 2 James HR 54223 3 Howe Finance 80000 4 Jones Finance 82000 5 Norwood IT 67000 6 Benson Sales 76000 7 Smith Sales 65778 8 Baker HR 56778 9 Dempsey HR 78999 10 Nolan

>>>>> Hadley Wickham >>>>> on Wed, 8 Aug 2018 09:34:42 -0500 writes: >>>> Method dispatch for `vec_c()` is quite simple because >>>> associativity and commutativity mean that we can >>>> determine the output type only by considering a pair of >>>> inputs at a time. To this end, vctrs provides