search for: diddle

Full_Name: Stephan Schlueter Version: 1.9.0 OS: Submission from: (NULL) (217.184.109.24) During my studies, I found a fault in the hist()-function: If you have a vector x with values around zero and also bigger than 10,000,000 , there will be a shift of -max(x)/10,000,000 in the hist-datas. See my example: x<-runif(10000) hist(x,breaks=c(seq(-3,3,0.1)),prob=TRUE) #everything ok, but

I was using the hist() function to create a frequency table of some network traffic data. The range in values is rather large, from 0 till just under 10e12. Calling hist(x, breaks=c(0,1000,1e6,1e9,1e12),plot=F,freq=T) causes hist() to return : $breaks [1] -1.0000e+05 1.0100e+05 1.1000e+06 1.0001e+09 1.0000e+12 Is this recalculation of the breaks by hist() intended? Maarten van Gelder.

...(500, 2),breaks=0:10, freq=TRUE) Warning message: the AREAS in the plot are wrong -- rather use `freq=FALSE'! in: plot.histogram(r, freq = freq, col = col, border = border, main = main, The following excerpt from hist.default(...) (new in 1.2.2) might have caused this behaviour: ... diddle <- 1e-07 * max(abs(range(breaks))) fuzz <- if (right) c(if (include.lowest) -diddle else diddle, rep(diddle, length(breaks) - 1)) else c(rep(-diddle, length(breaks) - 1), if (include.lowest) diddle else -diddle) breaks <- breaks + fuzz ... The additio...

I came across this hack while looking through chan_zap.c. Is this still applicable for those w/ zplex cb's? Is it a maybe need or an absolutely need? Any background info would be appreciated. Sincerely, Andy Hester Consero (817)375-1244 (817)937-7977

Hi! I guess I just overread the part I need, I checked the FAQ and online-documentation, but could not find the solution for my problem: I have a server with 1 external IP and a LAN behind, where I need ports to be forwarded like this: external 1.2.3.4:81 forwarded to internal 192.168.1.1:80 external 1.2.3.4:82 forwarded to internal 192.168.1.2:80 and so on .. (for configuring/accessing the

I have put together a simple set of diffs that corrects the problem described by Steven Fishback <sfishback at interpath.net> on 10-30 on this list regarding incorrect information reported by last on Solaris. The patches merely pass along the username in the utmpx record for a logout. Is there any reason why this would be a problem with other OSes? If not, maybe this could be rolled into the

Hello, My platform is SuSE 8.1. After downloading and unpacking R version 1.7 I tried building with shared libs enabled. (./configure --enabl-R-shlib). My goal is to use RSPython but I am now in my own private segmentation fault hell. The R build worked fine: make, make check, make install cool. The RSPython build worked fine. Thinking I'm good to go, I run python. But when I import RS

Just been trying to get the polygon triangulation code from this package: http://www-2.cs.cmu.edu/~quake/triangle.html to dyn.load into R. Uh oh. Floating point exceptions. Track it down to some FPU diddling that the author deems is necessary. Here's my minimal code that breaks: flipme.c: #include <fpu_control.h> void flipme(){ int cword; cword=4210; _FPU_SETCW(cword);

I have a working sortable_list that is added to by AJAX. The problem is that when a new item is added, it''s not sortable. I found a post on scriptaculous using behaviour.js to refresh the DOM when an item is added, but I can''t figure out how to do it with Rails. To test the behaviour method, I used this: var myrules={ ''div#steps ul'' :

On 29 April 2020 at 11:22, peter dalgaard wrote: | Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is looping. Diddling optimization options can also sometimes provide a clue. (Missed this earlier as

Wow, I've never seen an FSF gcc crap out like this on a non-overheating system. When lib/envelope.c is compiled with -march=i686, gcc gets a signal 11, but not with -march=i586. I'm not sure whether to blame gcc or libvorbis. There are apparently three other files in libvorbis where this same behavior is seen. jeffrey@diddl:/usr/src/build/libvorbis-1.0/lib$ gcc

This is a new problem: Old versions of R worked fine. I am not sure when it got broken. I am posting here instead of bugs in case this is not a true bug. New vanilla plots (I mean I don't fool around with par() etc) are screwed up in several ways: - the tick marks are twice as long as they should be - the gap between the end of the tick and the top of the numerical labels is twice as big as

Is there a way to authenticate with an IP address? I''m using the LoginGenerator, but would like to bypass the "before_filter :login_required " if a user is in a correct IP range... Anyone know of a solution? Thanks! -- Posted via http://www.ruby-forum.com/.

I ran into an interesting error unserializing a file created with ascii=TRUE: R 3.5.1 (Windows or Linux): > unserialize(serialize(list(raw=as.raw(c(39,41))), NULL, version=2, ascii=TRUE)) Error in unserialize(serialize(list(raw = as.raw(c(39, 41))), NULL, version = 2, : ReadItem: unknown type 29, perhaps written by later version of R The same error happens when the

...cond assumption was interface between NEC and TDM was clipping, after changes to tx/rx gain the 'demo' speech sounds fine on the Dterm. (Does this remove the interface from the possible bad guys list?) HELP Needed: So given that latency is in the 70 - 100 ms round trip. Given that I've diddled rx/tx gain. Given that I've tried basic echo on/off settings. What's next? Is the 'common' 150 ms one way (150+ms round trip) value a bunch of crap? Do I need some other magic latency goal? Would a 729 codec help? Is there a test I missed? Some other values to twiddle?...

I have a simple perl script that every few hours pings the handful of machines on my LAN. Lately I've sometimes been getting ping of 192.168.0.1 succeeded ping of 192.168.0.7 succeeded ping of 192.168.0.5 FAILED ping of 192.168.0.6 succeeded ping of 192.168.0.9 succeeded This machine in question has been running Centos faithfully for about six years and no recent changes to it have been

The R 4.0.0 package migration on Debian is being held back by a failed build on ppc64el [1]. We can see from the history of builds logs [2] that it used to build, briefly failed, worked again and then failed leading to R 4.0.0's release. (And my bad for missing how the alpha1/alpha2/beta/rc builds failed.) I have however neither changed anything, nor did I ever have to accomodate ppc64el (as

We don't want vga16fb to mess with hardware initialized by other driver. Detect it and refuse to load. It fixes nouveau interrupt storm on some machines. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/video/vga16fb.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c index

On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org> wrote: > > > On 29 April 2020 at 11:22, peter dalgaard wrote: > | Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is

I am trying to create a topographic map of an island - the filled.contour function works fine except i am experiencing difficulty trying to represent the sea properly. Basically I want the default colour blue for any instance where z=0, if I simply use the default topo.color I get shades of blue for z values up to 220 metres. Is there a way in which I can specify terrain.color for all values of