search for: coef0

Dear list, In some places (for example, http://en.wikipedia.org/wiki/Support_vector_machine) , the polynomail kernel in SVM is written as (u'*v + 1)^d, while in the document of svm() in e1071 package, the polynomial kernel is written as (gamma*u'*v + coef0)^d. I am a little confused here: When doing parameter optimization (grid search or so) for polynomial kernel, does it need to tune four parameters, gamma, coef0, C and degree, or just two of them, C and degree (and fixing gamma to 1 and coef0 = 1)? Thanks, Wuming

...solve the problem and haven't been able yet to do it. So I'm doing this: > dados<-read.table("b.txt",sep="",nrows=30000) > model<-svm(x=dados[,-1],y=dados[,1],scale=TRUE,type="C-classification",kernel="radial",cost=1,degree=3,gamma=0.083,coef0=0,nu=0.5,epsilon=0.1) Warning message: In svm.default(x = dados[, -1], y = dados[, 1], scale = TRUE, type = "C-classification", : Variable(s) ?V12? and ?V13? constant. Cannot scale data. > summary(model) Call: svm.default(x = dados[, -1], y = dados[, 1], scale = TRUE, type = &quot...

Jonathan Lennox wrote: > +opus_int32 silk_noise_shape_quantizer_short_prediction_neon(const opus_int32 *buf32, const opus_int32 *coef32) > +{ > + int32x4_t coef0 = vld1q_s32(coef32); > + int32x4_t coef1 = vld1q_s32(coef32 + 4); > + int32x4_t coef2 = vld1q_s32(coef32 + 8); > + int32x4_t coef3 = vld1q_s32(coef32 + 12); > + > + int32x4_t a0 = vld1q_s32(buf32 - 15); > + int32x4_t a1 = vld1q_s32(buf32 - 11); > + int32x4_t a...

> On Nov 19, 2015, at 5:47 PM, John Ridges <jridges at masque.com> wrote: > > Any speedup from the intrinsics may just be swamped by the rest of the encode/decode process. But I think you really want SIG2WORD16 to be (vqmovns_s32(PSHR32((x), SIG_SHIFT))) Yes, you?re right. I forgot to run the vectors under qemu with my previous version (oh, the embarrassment!) Fixed forthcoming

I am trying to understand what is the difference between linear and polynomial kernel: linear: u'*v polynomial: (gamma*u'*v + coef0)^degree It would seem that polynomial kernel with gamma = 1; coef0 = 0 and degree = 1 should be identical to linear kernel, however it gives me significantly different results for very simple data set, with linear kernel significantly outperforming polynomial kernel. *** mse, r2 = 0.5, 0.9 fo...

Hi I am trying to tune an svm by doing the following: tune(svm, similarity ~., data = training, degree = 2^(1:2), gamma = 2^(-1:1), coef0 = 2^(-1:1), cost = 2^(2:4), type = "polynomial") but I am getting Error in svm.default(x, y, scale = scale, ...) : wrong type specification! > I have to admit I am not sure what I am doing wrong. Could anyone tell me why the parameters I am using are wrong? Plus cou...

...iced that your NEON code doesn't use any of the "high" intrinsics for ARM64, e.g. instead of: int32x4_t coef1 = vmovl_s16(vget_high_s16(coef16)); you could use: int32x4_t coef1 = vmovl_high_s16(coef16); and instead of: int64x2_t b1 = vmlal_s32(b0, vget_high_s32(a0), vget_high_s32(coef0)); you could use: int64x2_t b1 = vmlal_high_s32(b0, a0, coef0); and instead of: int64x1_t c = vadd_s64(vget_low_s64(b3), vget_high_s64(b3)); int64x1_t cS = vshr_n_s64(c, 16); int32x2_t d = vreinterpret_s32_s64(cS); out = vget_lane_s32(d, 0); you could use: out = (opus_int32)(vaddvq_s64(b3) &g...

> On Dec 19, 2015, at 10:07 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > > Jonathan Lennox wrote: >> +opus_int32 silk_noise_shape_quantizer_short_prediction_neon(const opus_int32 *buf32, const opus_int32 *coef32) >> +{ >> + int32x4_t coef0 = vld1q_s32(coef32); >> + int32x4_t coef1 = vld1q_s32(coef32 + 4); >> + int32x4_t coef2 = vld1q_s32(coef32 + 8); >> + int32x4_t coef3 = vld1q_s32(coef32 + 12); >> + >> + int32x4_t a0 = vld1q_s32(buf32 - 15); >> + int32x4_t a1 = vld1q_s32(buf32 - 11...

...vdupq_n_s32(data0[0]); + int32x4_t a01 = vld1q_s32(data1); // data1[0] ... [3] + + int32x4_t a0 = vextq_s32 (a00, a01, 3); // data0[0] data1[0] ...[2] + int32x4_t a1 = vld1q_s32(data1 + 3); // data1[3] ... [6] + + int16x8_t coef16 = vld1q_s16(coef); + int32x4_t coef0 = vmovl_s16(vget_low_s16(coef16)); + int32x4_t coef1 = vmovl_s16(vget_high_s16(coef16)); + + int64x2_t b0 = vmull_s32(vget_low_s32(a0), vget_low_s32(coef0)); + int64x2_t b1 = vmlal_s32(b0, vget_high_s32(a0), vget_high_s32(coef0)); + int64x2_t b2 = vmlal_s32(b1, vget_low_...

...vdupq_n_s32(data0[0]); + int32x4_t a01 = vld1q_s32(data1); // data1[0] ... [3] + + int32x4_t a0 = vextq_s32 (a00, a01, 3); // data0[0] data1[0] ...[2] + int32x4_t a1 = vld1q_s32(data1 + 3); // data1[3] ... [6] + + int16x8_t coef16 = vld1q_s16(coef); + int32x4_t coef0 = vmovl_s16(vget_low_s16(coef16)); + int32x4_t coef1 = vmovl_s16(vget_high_s16(coef16)); + + int64x2_t b0 = vmull_s32(vget_low_s32(a0), vget_low_s32(coef0)); + int64x2_t b1 = vmlal_s32(b0, vget_high_s32(a0), vget_high_s32(coef0)); + int64x2_t b2 = vmlal_s32(b1, vget_low_...

...;m having trouble. I should be very grateful if someone could help me on this.. > dados<-read.table("b.txt",sep="",nrows=30000) > model<-svm(x=dados[,-1],y=dados[,1],scale=TRUE,type="C-classification",kernel="radial",cost=1,degree=3,gamma=0.083,coef0=0,nu=0.5,epsilon=0.1) Warning message: In svm.default(x = dados[, -1], y = dados[, 1], scale = TRUE, type = "C-classification", : Variable(s) ?V12? and ?V13? constant. Cannot scale data. > summary(model) Call: svm.default(x = dados[, -1], y = dados[, 1], scale = TRUE, type = &quot...

...ced that your NEON code doesn't use any of the "high" intrinsics for ARM64, e.g. instead of: int32x4_t coef1 = vmovl_s16(vget_high_s16(coef16)); you could use: int32x4_t coef1 = vmovl_high_s16(coef16); and instead of: int64x2_t b1 = vmlal_s32(b0, vget_high_s32(a0), vget_high_s32(coef0)); you could use: int64x2_t b1 = vmlal_high_s32(b0, a0, coef0); and instead of: int64x1_t c = vadd_s64(vget_low_s64(b3), vget_high_s64(b3)); int64x1_t cS = vshr_n_s64(c, 16); int32x2_t d = vreinterpret_s32_s64(cS); out = vget_lane_s32(d, 0); you could use: out = (opus_int32)(vaddvq_s64(b3) &g...

In e1071 package/svm default epsilon value is set to 0.1 and not 0.5 as documentation says. R

As promised, here's a re-send of all my Aarch64 patches, following comments by John Ridges. Note that they actually affect more than just Aarch64 -- other than the ones specifically guarded by AARCH64_NEON defines, the Neon intrinsics all also apply on armv7; and the OPUS_FAST_INT64 patches apply on any 64-bit machine. The patches should largely be independent and independently useful, other

...ude "main.h" +#include "stack_alloc.h" +#include "NSQ.h" +#include "celt/cpu_support.h" +#include "celt/arm/armcpu.h" + +opus_int32 silk_noise_shape_quantizer_short_prediction_neon(const opus_int32 *buf32, const opus_int32 *coef32) +{ + int32x4_t coef0 = vld1q_s32(coef32); + int32x4_t coef1 = vld1q_s32(coef32 + 4); + int32x4_t coef2 = vld1q_s32(coef32 + 8); + int32x4_t coef3 = vld1q_s32(coef32 + 12); + + int32x4_t a0 = vld1q_s32(buf32 - 15); + int32x4_t a1 = vld1q_s32(buf32 - 11); + int32x4_t a2 = vld1q_s32(buf32 - 7); + int3...

...ude "main.h" +#include "stack_alloc.h" +#include "NSQ.h" +#include "celt/cpu_support.h" +#include "celt/arm/armcpu.h" + +opus_int32 silk_noise_shape_quantizer_short_prediction_neon(const opus_int32 *buf32, const opus_int32 *coef32) +{ + int32x4_t coef0 = vld1q_s32(coef32); + int32x4_t coef1 = vld1q_s32(coef32 + 4); + int32x4_t coef2 = vld1q_s32(coef32 + 8); + int32x4_t coef3 = vld1q_s32(coef32 + 12); + + int32x4_t a0 = vld1q_s32(buf32 - 15); + int32x4_t a1 = vld1q_s32(buf32 - 11); + int32x4_t a2 = vld1q_s32(buf32 - 7); + int3...

Following Tim's comments, here are my reworked patches for the Neon intrinsic function patches of of my Aarch64 patchset, i.e. replacing patches 5-8 of the v2 series. Patches 1-4 and 9-18 of the old series still apply unmodified. The one new (as opposed to changed) patch is the first one in this series, to add named constants for the ARM architecture variants. There are also some minor code

This sequence of patches provides arm64 support for Opus. Tested on iOS, Android, and Ubuntu 14.04. The patch sequence was written on top of Viswanath Puttagunta's Ne10 patches, but all but the second ("Reorganize pitch_arm.h") should, I think, apply independently of it. It does depends on my previous intrinsics configury reorganization, however. Comments welcome. With this and

Here are my aarch64 patches rebased to the current tip of Opus master. They're largely the same as my previous patch set, with the addition of the final one (the Neon fixed-point implementation of xcorr_kernel). This replaces Viswanath's Neon fixed-point celt_pitch_xcorr, since xcorr_kernel is used in celt_fir and celt_iir as well. These have been tested for correctness under qemu

...29, 29, 29, 29, 29, 29, 29, 29, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30)), scale = c(TRUE, TRUE, FALSE, FALSE, TRUE), type = "nu-regression", kernel = "polynomial", cost = 1, nu = 0, degree = 2, gamma = 0.0009765625, coef0 = -1) debug: UseMethod("svm") Browse[1]> Error in predict.svm(ret, xhold) : NA/NaN/Inf in foreign function call (arg 9) > [[alternative HTML version deleted]]