New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
user and item biases in WRMF and explicit feedback #44
Comments
With biases plus mean centering:
With rnorm init + biases + mean centering:
Although, the loss function is taking the regularization incorrectly so these aren't final numbers yet. |
Could you please elaborate more on that? |
It had a bug in which it was taking the squared sum of X twice instead of taking Y. Also I think it's adding a row of all-ones into the calculation. |
Ok, this fixed now
|
|
I think the more correct way of adding the regularization with biases to the loss would be to exclude only the row that has ones while still adding the row that has biases, as the regularization is also applied to the user/item biases. |
I'm pretty sure there is still some unintended data copying going on with the current approach. I tried timing it with the ML10M data, got these results:
Adding the biases made it take 49% longer to fit the model. For comparison purposes, these are the same times using the package cmfrec, which has a less efficient approach for the biases (uses rank+1 matrices and copies/replaces bias/constant component at each iteration):
It took only 26% longer with the biases added. |
@david-cortes should be fixed now, can you try? I'm surprised cmfrec is almost 2x faster! I would expect arma to be translated into effecient blas calls. |
Now it's producing a segmentation fault. |
Actually, the segmentation fault was not from 3731ca0, but from the commits that follow. However, this commit actually makes it slower:
|
Ran it again after using "clean and rebuild" from the current commit at the master branch, now it didn't segfault anymore, and took the same time as before with the biases (~16s). Perhaps I had some issue with the package calling the wrong shared object functions. |
Another interesting thing however: using |
I test it with following code library(Matrix)
set.seed(1)
m = rsparsematrix(100000, 10000, 0.01)
m@x = sample(5, size = length(m@x), replace = T)
rank = 8
n_user = nrow(m)
n_item = ncol(m)
user_factors = matrix(rnorm(n_user * rank, 0, 0.01), nrow = rank, ncol = n_user)
item_factors = matrix(rnorm(n_item * rank, 0, 0.01), nrow = rank, ncol = n_item)
library(rsparse)
system.time({
res = rsparse:::als_explicit_double(
m_csc_r = m,
X = user_factors,
Y = item_factors,
cnt_X = numeric(ncol(user_factors)),
lambda = 0,
dynamic_lambda = FALSE,
n_threads = 1,
solver = 0L,
cg_steps = 1L,
with_biases = FALSE,
is_x_bias_last_row = TRUE)
})
rank = 10
n_user = nrow(m)
n_item = ncol(m)
user_factors = matrix(rnorm(n_user * rank, 0, 0.01), nrow = rank, ncol = n_user)
user_factors[1, ] = rep(1.0, n_user)
item_factors = matrix(rnorm(n_item * rank, 0, 0.01), nrow = rank, ncol = n_item)
item_factors[rank, ] = rep(1.0, n_item)
system.time({
res = rsparse:::als_explicit_double(
m_csc_r = m,
X = user_factors,
Y = item_factors,
lambda = 0,
cnt_X = numeric(ncol(user_factors)),
dynamic_lambda = 0,
n_threads = 1,
solver = 0L,
cg_steps = 1L,
with_biases = T,
is_x_bias_last_row = TRUE)
})
The later used to be ~0.9-1 |
@david-cortes check 7fcb1d3 - I've remove
I will take a look |
This seems related to LAPACK which is used by the system. If you only use LAPACK which is shipped with R (which only works with
Haven't noticed that. Reproducible example will help. |
I'm using openblas. Tried
|
Here's an example: library(rsparse)
library(lgr)
lg = get_logger('rsparse')
lg$set_threshold('debug')
data('movielens100k')
options("rsparse_omp_threads" = 16)
X = movielens100k
set.seed(1)
model = WRMF$new(rank = 100, lambda = 0.05, dynamic_lambda = TRUE,
feedback = 'explicit', solver = 'conjugate_gradient',
with_user_item_bias = TRUE, with_global_bias=TRUE,
precision = "float")
user_emb = model$fit_transform(X, n_iter = 10, convergence_tol = -1)
|
Yes, that looks correct - it should not link to float if there is
system-wide BLAS and LAPACK with float support. Not sure about more than
linear speed-up. Maybe cache-efficiency due to lower memory footprint...
…On Mon, Dec 7, 2020 at 11:29 PM david-cortes ***@***.***> wrote:
I'm using openblas. Tried ldd on the generated .so and it doesn't look
like it's linking to anything from float:
ldd rsparse.so
linux-vdso.so.1 (0x00007ffc1bdf0000)
liblapack.so.3 => /lib/x86_64-linux-gnu/liblapack.so.3 (0x00007fbafff81000)
libblas.so.3 => /lib/x86_64-linux-gnu/libblas.so.3 (0x00007fbafff1c000)
libR.so => /lib/libR.so (0x00007fbaffa6c000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fbaff89f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbaff75b000)
libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1 (0x00007fbaff71b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fbaff6ff000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbaff53a000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbb006e1000)
libopenblas.so.0 => /lib/x86_64-linux-gnu/libopenblas.so.0 (0x00007fbafd235000)
libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007fbafcf7f000)
libreadline.so.8 => /lib/x86_64-linux-gnu/libreadline.so.8 (0x00007fbafcf28000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fbafce98000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fbafce6d000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007fbafce5a000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fbafce3d000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbafce37000)
libicuuc.so.67 => /lib/x86_64-linux-gnu/libicuuc.so.67 (0x00007fbafcc4f000)
libicui18n.so.67 => /lib/x86_64-linux-gnu/libicui18n.so.67 (0x00007fbafc94a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbafc926000)
libquadmath.so.0 => /lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fbafc8dd000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007fbafc8ae000)
libicudata.so.67 => /lib/x86_64-linux-gnu/libicudata.so.67 (0x00007fbafad95000)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#44 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABHC5XMD624ENNT4JVTKMQDSTUULNANCNFSM4UGWPJ5A>
.
--
Regards
Dmitriy Selivanov
|
On my machine it works fine... Numerical issues on a particular setup? DEBUG [23:39:40.707] initializing biases
INFO [23:39:40.748] starting factorization with 16 threads
INFO [23:39:40.787] iter 1 loss = 0.8346
INFO [23:39:40.804] iter 2 loss = 0.6115
INFO [23:39:40.821] iter 3 loss = 0.5629
INFO [23:39:40.837] iter 4 loss = 0.5554
INFO [23:39:40.855] iter 5 loss = 0.5514
INFO [23:39:40.873] iter 6 loss = 0.5494
INFO [23:39:40.888] iter 7 loss = 0.5483
INFO [23:39:40.908] iter 8 loss = 0.5477
INFO [23:39:40.924] iter 9 loss = 0.5474
INFO [23:39:40.941] iter 10 loss = 0.5473
>
>
>
> user_emb
# A float32 matrix: 943x102
# [,1] [,2] [,3] [,4] [,5]
# 1 1 0.310238 -0.187435 0.0070898 0.3378164
# 2 1 0.318511 -0.032087 0.0918757 0.3566173
# 3 1 -0.061583 -0.164409 0.0510152 0.1838035
# 4 1 0.216120 -0.049797 -0.0742759 -0.0062153
# 5 1 0.246393 0.013174 0.0510887 -0.1232737
# 6 1 0.418677 -0.090236 -0.4091501 -0.2156503
# 7 1 0.185473 0.050313 -0.1264562 -0.1054751
# 8 1 0.044565 -0.153883 -0.1510867 -0.0126681
# 9 1 0.240177 -0.168154 -0.3026042 -0.2351764
# 10 1 -0.033645 -0.017147 0.0695353 -0.0026545
# ... |
I don't think it's an issue with numerical precision, because it works fine under commit a7860f1 and the same problem seems to occur with MKL. By the way, the current commit on master doesn't compile on windows, something to do with unsigned integer types being undefined. |
I'm not sure what is wrong in your case. I've tried latest commit on my ubuntu workstation with openblas and it works normally, not throws NaN. |
I'm using the default flags:
|
By the way, the non-negative CD algorithm still works fine when the data is mean centered. |
How product of two non negative vectors can give potentially negative value (after centering) |
Thing is, if the data is non-negative, the mean will also be non-negative. Sorry, misunderstood - it won't give a negative value, but the algorithm still works by outputting something close to zero. |
Yes, it is kind of working, but loss is huge and model is not that useful. |
I think this has to do with AVX instructions and array padding. If I disable newer instructions by setting
Perhaps something to do with the EDIT: hmm, actually now it's working correctly with EDIT2: ok, I actually realize now that commit |
Yes, I had segfaults this subviews as well... |
I think we are done here. There will a separate thread for a model with biases with At the moment I'm little bit short in time. @david-cortes feel free to make a shot for a biases on |
@dselivanov I’m not so sure it’s something desirable to have actually. I tried playing with centering and biases with implicit-feedback data, and I see that adding user biases usually gives a very small lift in metrics like HR@5, but item biases makes them much worse. You can play with library(cmfrec)
Xvalues <- Xcoo@x
Xcoo@x <- rep(1, length(Xcoo@x))
model <- CMF(Xcoo, weight=Xvalues, NA_as_zero=TRUE,
center=TRUE, user_bias=TRUE, item_bias=TRUE) |
As of 35247b4
without biases
with biases
cc @david-cortes
The text was updated successfully, but these errors were encountered: