Closed Arcovion closed 9 years ago
Thanks for your feedback! It seems to be caused by for
loop style. I guess replacing for(int i = 0; ... )
by int i; for(i = 0; ...)
in distance.c
should solve this issue. But I have to say sorry that this gem does not support Windows currently since I don't have a Windows environment right now :cry:. (It runs on Mac and Unix, and fallback to pure Ruby version in JRuby.)
I need some time to get a windows, and I also appreciate you can send a pull request :).
I added $CFLAGS << ' -std=gnu99'
to the 2nd line of extconf.rb
and the gem installed successfully.
Requiring the gem shows this error though:
C:/Ruby200/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- jaro_winkler/jaro_winkler.so (LoadError)
The .so
file is actually there, but isn't found. This might be my fault compiling the gem incorrectly, in any case $CFLAGS << ' -std=gnu99'
is worth adding, probably with an if statement so it's only applied for Ruby on Windows.
I'll keep using AMatch for now, maybe you should add hotwater
and amatch
benchmark comparisons in future too. =]
Edit: This line shows you may have encountered that problem already, if you can apply that fix to Windows and add the C flag it should work just like JRuby. Didn't test that yet though.
I didn't knowhotwater
and amatch
before, thanks for noticing. I've added them to benchmark.
user | system | total | real | |
---|---|---|---|---|
jaro_winkler | 0.370000 | 0.000000 | 0.370000 | ( 0.370106) |
fuzzystringmatch | 0.140000 | 0.000000 | 0.140000 | ( 0.147716) |
hotwater | 0.280000 | 0.000000 | 0.280000 | ( 0.284125) |
amatch | 0.950000 | 0.000000 | 0.950000 | ( 0.958045) |
As the table shown, my work is slower than native version of fuzzaystringmatch
and hotwater
. After roughly reading their source code, it seems that they doesn't support UTF-8 string, in my submission, there is something to do with it because I spend more time to compute UTF-8 byte length. I'll try to enhance my project to be faster and still support UTF-8 string in the future.
Finally, I've made a patch to fallback to pure Ruby on windows, it supposed to solve this issue temporarily.
@Arcovion I wonder if you can help me trying this branch?
Tested that branch and all I had to change was if RUBY_PLATFORM['win']
→ if Gem.win_platform?
Seems to work well!
Rehearsal --------------------------------------------------
jaro_winkler_r 14.570000 0.000000 14.570000 ( 14.756844)
jaro_winkler_c 0.374000 0.000000 0.374000 ( 0.376021)
---------------------------------------- total: 14.944000sec
user system total real
jaro_winkler_r 14.446000 0.000000 14.446000 ( 14.510830)
jaro_winkler_c 0.374000 0.000000 0.374000 ( 0.378022)
version 1.2.7 released. Thanks for your help! @Arcovion :beer:
Great, 1.2.7
installs fine.
One more thing: maybe change :case_match
to :ignore_case?
. I think case match is a bit ambiguous and ignore case is more commonly used with regex etc.
You are right, :ignore_case
is better naming. I've fixed in 1.2.8
.
Thanks, good luck with this gem. :thumbsup:
BTW I found that these:
s1, s2 = 'henka', 'henkan'
p Amatch::JaroWinkler.new(s1).tap{ |m| m.scaling_factor = 0.1 }.match s2
p JaroWinkler.distance s1, s2, ignore_case: true, threshold: 0.5, weight: 0.1
are the same, AMatch (seems to) use 0.5
threshold and doesn't compare case by default.
@Arcovion I have no idea how amatch was implemented on account of its lack of readability of source code. In my opinion there is no threshold in amatch: ref.
Sheer coincidence that this gem was released just hours before I needed a Jaro-Winkler implementation! I had the same thought process about other gems (
s1.split //
->s1.chars
etc) and this looks excellent.However it doesn't install for me, seems like you need to add a flag (
-std=gnu99
) for GCC.