Displaying 16 results from an estimated 16 matches for "nmatch".
Did you mean:
match
2011 Sep 29
3
grep and PCRE fun
...ot allowed
As described above, this error occurs on ubuntu 10.04 when R is
compiled without optimizations ( I typically use CFLAGS="-ggdb"
CXXFLAGS="-ggdb" FFLAGS="-ggdb" ./configure --enable-R-shlib), and the
pcre_exec call executed from do_get overwrites the integer nmatches
and sets it to -1. This has the effect of making do_grep try and
allocate a results vector of length -1, which of course causes the
error message above.
I'd be interested to know if this bug happens on other platforms.
Below is my simple fix for R-2-13-branch (a similar fix works for
trunk...
2009 Aug 30
0
[LLVMdev] Regular Expression lib support
..., Daniel Dunbar wrote:
> Nice!
>
> This looks good to me but probably Chris or someone else should sign
> off on it.
This seems ok to me, please commit. One minor comment:
+++ b/lib/Support/Regex.cpp
+ // Allocate pmatch with at least one element.
+ pmatch = new llvm_regmatch_t[nmatch > 0 ? nmatch : 1];
+ pmatch[0].rm_so = 0;
+ pmatch[0].rm_eo = String.size();
Can this be a smallvector to avoid a heap allocation on every match?
-Chris
2009 Aug 28
3
[LLVMdev] Regular Expression lib support
...ess regex was compiled with NEWLINE flag.
>>>>> +
>>>>> + bool matches(const char *string, bool notbol=false, bool noteol=false);
>>>>> + bool match_sub(const char *string, llvm_regmatch_t pmatch[],
>>>>> + unsigned nmatch, bool notbol=false, bool noteol=false);
>>>>>
>>>>>
>>>> These should be doxymented, and I don't understand the flags. Does this mean
>>>> that if I *don't* compile with NEWLINE, but *do* want ^/$ support, then
>>>> notbol/no...
2003 Jul 17
3
how to divide a string into characters? - for comparing strings that is
Hi
I am searching for a way to do something like "ABC" -> c("A","B","C"). How can this be accomplished?
I tried cut() and split(), but they do something else, it seems.
The purpose for doing this is to find the number of common (and uncommon) characters, i.e. ultimately I want something like this:
> foo("ABD","ADE")
c(2,1) # 2
2009 Aug 30
1
[LLVMdev] Regular Expression lib support
...:
G:\public\zorg\buildbot\osuosl\slave\clang-i686-xp-msvc9\llvm\include\llvm/Support/IRBuilder.h(133) : error C3861: 'InsertHelper': identifier not found
>
> +++ b/lib/Support/Regex.cpp
>
> + // Allocate pmatch with at least one element.
> + pmatch = new llvm_regmatch_t[nmatch > 0 ? nmatch : 1];
> + pmatch[0].rm_so = 0;
> + pmatch[0].rm_eo = String.size();
>
> Can this be a smallvector to avoid a heap allocation on every match?
Yes, I changed it to use SmallVector.
Best regards,
--Edwin
2009 Aug 25
6
[LLVMdev] Regular Expression lib support
...-end-of-line operator always fails to match.
> + // unless regex was compiled with NEWLINE flag.
> +
> + bool matches(const char *string, bool notbol=false, bool noteol=false);
> + bool match_sub(const char *string, llvm_regmatch_t pmatch[],
> + unsigned nmatch, bool notbol=false, bool noteol=false);
These should be doxymented, and I don't understand the flags. Does this mean
that if I *don't* compile with NEWLINE, but *do* want ^/$ support, then
notbol/noteol need to be false? Do we care about use cases that care about this?
Could we just always...
2009 Aug 25
0
[LLVMdev] Regular Expression lib support
...r always fails to match.
>> + // unless regex was compiled with NEWLINE flag.
>> +
>> + bool matches(const char *string, bool notbol=false, bool noteol=false);
>> + bool match_sub(const char *string, llvm_regmatch_t pmatch[],
>> + unsigned nmatch, bool notbol=false, bool noteol=false);
>>
>
> These should be doxymented, and I don't understand the flags. Does this mean
> that if I *don't* compile with NEWLINE, but *do* want ^/$ support, then
> notbol/noteol need to be false? Do we care about use cases that care...
2009 Aug 27
2
[LLVMdev] Regular Expression lib support
...tch.
>>> + // unless regex was compiled with NEWLINE flag.
>>> +
>>> + bool matches(const char *string, bool notbol=false, bool noteol=false);
>>> + bool match_sub(const char *string, llvm_regmatch_t pmatch[],
>>> + unsigned nmatch, bool notbol=false, bool noteol=false);
>>>
>>
>> These should be doxymented, and I don't understand the flags. Does this mean
>> that if I *don't* compile with NEWLINE, but *do* want ^/$ support, then
>> notbol/noteol need to be false? Do we care about use...
2010 Jan 09
4
parsing pdf files
I have a pdf file that I would like to parse into R:
http://www.williams.edu/Registrar/geninfo/faculty.pdf
For now, I open the file in Acrobat by hand, then save it "as text"
and then use readLines(). That works fine but a) I am concerned that
some information may be lost and b) I may be doing this a lot, so I
would rather have R grab the information from the pdf file directly.
So: is
2009 Aug 25
0
[LLVMdev] Regular Expression lib support
On 2009-08-24 20:14, Chris Lattner wrote:
> On Aug 23, 2009, at 11:59 PM, Török Edwin wrote:
>> If LLVM is going to have an integrated regex library I suggest using it
>> regardless if the platform has one.
>> The LLVM integrated regex library will provide consistent behaviour and
>> execution time, the system one will not.
>
> Hi Edwin,
>
> Can you propose
2009 Aug 27
0
[LLVMdev] Regular Expression lib support
...; + // unless regex was compiled with NEWLINE flag.
>>>> +
>>>> + bool matches(const char *string, bool notbol=false, bool noteol=false);
>>>> + bool match_sub(const char *string, llvm_regmatch_t pmatch[],
>>>> + unsigned nmatch, bool notbol=false, bool noteol=false);
>>>>
>>>>
>>> These should be doxymented, and I don't understand the flags. Does this mean
>>> that if I *don't* compile with NEWLINE, but *do* want ^/$ support, then
>>> notbol/noteol need t...
2009 Aug 24
3
[LLVMdev] Regular Expression lib support
On Aug 23, 2009, at 11:59 PM, Török Edwin wrote:
> If LLVM is going to have an integrated regex library I suggest using
> it
> regardless if the platform has one.
> The LLVM integrated regex library will provide consistent behaviour
> and
> execution time, the system one will not.
Hi Edwin,
Can you propose the openbsd implementation as a patch to lib/support?
-Chris
1998 Jan 11
0
R-beta: New version 0.61.1
...with named components.
o Parsing of nested "if" statments was broken. This is fixed now.
(Reported by Paul Gilbert).
o Wrong declaration of ConsoleBufCnt in src/main/scan.c caused crash
in Irix (George White <gwhite at bodnext.bio.dfo.ca>)
o if(nmatch = 0) bug in src/main/character.c fixed (Doug Bates)
o R_alloc/S_alloc fixes. The former allocated 4 times more than
needed, the latter zeroed half of what it got, sizeof() mistakes
in both cases.
o c(ordered factor) caused segfault (uninitalised pointer), now
f...
1998 Jan 11
0
R-beta: New version 0.61.1
...with named components.
o Parsing of nested "if" statments was broken. This is fixed now.
(Reported by Paul Gilbert).
o Wrong declaration of ConsoleBufCnt in src/main/scan.c caused crash
in Irix (George White <gwhite at bodnext.bio.dfo.ca>)
o if(nmatch = 0) bug in src/main/character.c fixed (Doug Bates)
o R_alloc/S_alloc fixes. The former allocated 4 times more than
needed, the latter zeroed half of what it got, sizeof() mistakes
in both cases.
o c(ordered factor) caused segfault (uninitalised pointer), now
f...
2005 Aug 15
4
Vector comparison to matrix
I am looking for a fast way to count the number of rows in a matrix are
identical to a pattern vector. For example, if I am interested in counting
the number of row vectors in a matrix that are identical to (1,2,3) what
would I do? I have tried the identical statement in a loop but this is far
too slow. I have a very large matrix and need to avoid loops at all costs.
Thanks for any help.
2004 Feb 19
1
Process R segmentation with strsplit() (PR#6601)
...difications: Carbamidomethyl (C)\nVariable modifications: Oxidation (M)\nCleavage by Trypsin: cuts C-term side of KR unless next residue is P\nNumber of mass value!
s searched: <B>6</B>\nNumber of mass values matched: <B>1</B>\!
nSequenc
e Coverage: <B>8%</B>\n\nMatched peptides shown in <B><FONT COLOR=#FF0000>Bold Red</FONT></B>\n\n <B>1</B> MVCDKCEKKL SKVIVPDKWK DGARNVTEGG GRKINENKLL SKKNRWSPYS <B>\n 51</B> TCTTKCMICK QQVHQDGKYC HTCAYSK<B><FONT COLOR=#FF0000>GVC AMCGK</FONT></B>QVLD...