Re: exp() / expl() on Linux and OpenBSD (expl() bug?)
On Fri, Feb 7, 2014 at 8:07 AM, Martynas Venckus marty...@venck.us wrote:
Yup.Does this diff fix it for you?
Yeah! It works.
And R-3's testsuite is also happy now.
Thanks a lot! And thanks to Daniel too...
ok dcoppa@ to commit it, obviously
Ciao,
David
On 2/6/14, Daniel Dickman didick...@gmail.com wrote:
I think I recently ran into a similar issue but I suspect the root cause
might be the same. I think the floorl function is wrong for numbers slightly
larger than -1 to numbers slightly below 0. In this range floorl returns -0
instead of -1.
On Feb 5, 2014, at 3:57 AM, David Coppa dco...@openbsd.org wrote:
Hi!
I hit this problem while working on updating math/R from version
2.15.3 to the latest version (3.0.2).
It started happening since upstream switched from double functions
to C99 long double functions (expl, fabsl, ...), during the R-3
development cycle.
Take the following reduced test-case, adapted from what R's code
does:
---8---
#include stdio.h
#include stdlib.h
#include math.h
int main(void) {
double theta = 1;
long double lambda, pr, pr2;
lambda = (0.5*theta);
pr = exp(-lambda);
pr2 = expl(-lambda);
printf(theta == %g, pr == %Lg, pr2 == %Lg\n, theta, pr, pr2);
exit(0);
}
---8---
This produces the following output on Linux (x86_64):
theta == 1, pr == 0.606531, pr2 == 0.606531
While on OpenBSD -current amd64:
theta == 1, pr == 0.606531, pr2 == nan
And indeed R-3's testsuite fails with the error message
NaNs produced:
Warning in pchisq(1e-300, df = 0, ncp = lam) : NaNs produced
stopifnot(all.equal(p00, exp(-lam/2)),
+ all.equal(p.0, exp(-lam/2)))
Error: all.equal(p.0, exp(-lam/2)) is not TRUE
Execution halted
Is this a bug in our expl() ?
Ciao,
David
Re: ip6opt.c
On 06/02/14(Thu) 19:43, Eitan Adler wrote: On Tue, Feb 4, 2014 at 8:54 PM, Alexander Bluhm alexander.bl...@gmx.net wrote: On Tue, Feb 04, 2014 at 08:35:02PM -0500, Eitan Adler wrote: Hi all, The following bug was recently fixed in DragonFlyBSD and FreeBSD: libc/net: Fix issue in inet6_opt_init() (from RFC 3542): * The RFC says (in section 10.1) that only when extbuf is not NULL, extlen shall be checked, so don't perform this check when NULL is passed. I understand the RFC and the man page the same way, OK bluhm@ Is anyone willing to commit this? It's in now, thanks!
Re: em(4): Don't count RX overruns and missed packets as input errros
On Tue, Jan 28, 2014 at 02:08:09AM -0500, Brad Smith wrote:
On Tue, Jan 28, 2014 at 01:21:46PM +1000, David Gwynne wrote:
On 26 Jan 2014, at 11:31 am, Brad Smith b...@comstyle.com wrote:
On 31/12/13 5:50 AM, Mike Belopuhov wrote:
On 31 December 2013 09:46, Brad Smith b...@comstyle.com wrote:
On 31/12/13 3:14 AM, Mark Kettenis wrote:
Date: Tue, 31 Dec 2013 01:28:04 -0500
From: Brad Smith b...@comstyle.com
Don't count RX overruns and missed packets as inputs errors. They're
expected to increment when using MCLGETI.
OK?
These may be expected, but they're still packets that were not
received. And it is useful to know about these, for example when
debugging TCP performance issues.
Well do we want to keep just the missed packets or both? Part of the
diff was inspired by this commit when I was looking at what counters
were incrementing..
for bge(4)..
revision 1.334
date: 2013/06/06 00:05:30; author: dlg; state: Exp; lines: +2 -4;
dont count rx ring overruns as input errors. with MCLGETI controlling
the
ring we expect to run out of rx descriptors as a matter of course, its
not
an error.
ok mikeb@
it does screws up statistics big time. does mpc counter follow
rx_overruns?
why did we add them up both previously?
Yes, it does. I can't say why exactly but before MCLGETI for most
environments
it was unlikely to have RX overruns.
its not obvious?
rx rings are usually massively over provisioned. eg, my myx has 512 entries
in its
rx ring. however, its interrupt mitigation is currently configured for
approximately
16k interrupts a second. if you're sustaining 1m pps, then you can divide
that by the
interrupt rate to figure out the average usage of the rx ring. so 1000 / 16
is about
60-65 descriptors per interrupt. 512 is roughly an order of magnitude more
than what
you need for that workload.
if you were hitting the ring limits before MCLGETI, then that means you
dont have
enough cpu to process the pps. increasing the ring size would make it worse
cos you'd
spend more time freeing mbufs because you were too far behind on the pps
you could
deal with.
Ya, I don't know why I ultimately said I can't say why exactly as I was
thinking about
what you said regaring having a lot of buffers allocated and that's why I
said it was
unlikely to have RX overruns.
Since this was changed for bge(4) then the other drivers using MCLGETI should
be changed
as well if there is consensus about not adding the RX overruns to the
interfaces input
errors counter. But I think kettenis has a point as well that this
information is useful
its just we don't have any way of exposing that info to userland.
Ok, so I looked at the other drivers using MCLGETI and there are a few others
also
counting FIFO overruns towards input errors.
Index: arch/socppc/dev/if_tsec.c
===
RCS file: /home/cvs/src/sys/arch/socppc/dev/if_tsec.c,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 if_tsec.c
--- arch/socppc/dev/if_tsec.c 29 Nov 2012 21:10:31 - 1.29
+++ arch/socppc/dev/if_tsec.c 28 Jan 2014 05:16:24 -
@@ -779,7 +779,6 @@ tsec_errintr(void *arg)
*/
tsec_rx_proc(sc);
tsec_write(sc, TSEC_RSTAT, TSEC_RSTAT_QHLT);
- ifp-if_ierrors++;
}
return (1);
Index: dev/pci/if_se.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_se.c,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 if_se.c
--- dev/pci/if_se.c 28 Dec 2013 03:34:54 - 1.9
+++ dev/pci/if_se.c 28 Jan 2014 04:49:53 -
@@ -939,7 +939,8 @@ se_rxeof(struct se_softc *sc)
printf(%s: rx error %b\n,
ifp-if_xname, rxstat, RX_ERR_BITS);
se_discard_rxbuf(sc, i);
- ifp-if_ierrors++;
+ if ((rxstat RDS_OVRUN) == 0)
+ ifp-if_ierrors++;
continue;
}
Index: dev/pci/if_sis.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_sis.c,v
retrieving revision 1.115
diff -u -p -u -p -r1.115 if_sis.c
--- dev/pci/if_sis.c28 Dec 2013 03:34:54 - 1.115
+++ dev/pci/if_sis.c28 Jan 2014 04:51:53 -
@@ -1378,7 +1378,8 @@ sis_rxeof(struct sis_softc *sc)
total_len = (ETHER_MAX_DIX_LEN - ETHER_CRC_LEN))
rxstat = ~SIS_RXSTAT_GIANT;
if (SIS_RXSTAT_ERROR(rxstat)) {
- ifp-if_ierrors++;
+ if ((rxstat SIS_RXSTAT_OVERRUN) == 0)
+ ifp-if_ierrors++;
if (rxstat
Re: exp() / expl() on Linux and OpenBSD (expl() bug?)
Date: Thu, 6 Feb 2014 23:07:58 -0800
From: Martynas Venckus marty...@venck.us
Yup.Does this diff fix it for you?
Here's a diff that sticks a bit closer to the original code. It's
equivalent to your diff, and admittedly purely a matter of taste which
version to prefer.
Index: s_floorl.c
===
RCS file: /home/cvs/src/lib/libm/src/ld80/s_floorl.c,v
retrieving revision 1.2
diff -u -p -r1.2 s_floorl.c
--- s_floorl.c 25 Jul 2011 16:20:09 - 1.2
+++ s_floorl.c 7 Feb 2014 14:43:19 -
@@ -38,7 +38,7 @@ floorl(long double x)
if(huge+x0.0) {/* return 0*sign(x) if |x|1 */
if(sx==0) {se=0;i0=i1=0;}
else if(((se0x7fff)|i0|i1)!=0)
- { se=0xbfff;i0=i1=0;}
+ { se=0xbfff;i0=0x8000;i1=0;}
}
} else {
i = (0x7fff)jj0;
Re: exp() / expl() on Linux and OpenBSD (expl() bug?)
On Fri, Feb 7, 2014 at 3:49 PM, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Thu, 6 Feb 2014 23:07:58 -0800
From: Martynas Venckus marty...@venck.us
Yup.Does this diff fix it for you?
Here's a diff that sticks a bit closer to the original code. It's
equivalent to your diff, and admittedly purely a matter of taste which
version to prefer.
Index: s_floorl.c
===
RCS file: /home/cvs/src/lib/libm/src/ld80/s_floorl.c,v
retrieving revision 1.2
diff -u -p -r1.2 s_floorl.c
--- s_floorl.c 25 Jul 2011 16:20:09 - 1.2
+++ s_floorl.c 7 Feb 2014 14:43:19 -
@@ -38,7 +38,7 @@ floorl(long double x)
if(huge+x0.0) {/* return 0*sign(x) if |x|1 */
if(sx==0) {se=0;i0=i1=0;}
else if(((se0x7fff)|i0|i1)!=0)
- { se=0xbfff;i0=i1=0;}
+ { se=0xbfff;i0=0x8000;i1=0;}
}
} else {
i = (0x7fff)jj0;
Just tested, and this one works too, of course...
I'd be happy if this or the other one could be committed.
ciao,
David
C-j in tmux
Hello.
This patch by me and Alexander Hirsch makes tmux accept C-j everywhere
Enter/C-M is accepted, as seems customary in Unix:
--- src/usr.bin/tmux/mode-key.c
+++ src/usr.bin/tmux/mode-key.c
@@ -153,6 +153,7 @@
{ '\025' /* C-u */, 0, MODEKEYEDIT_DELETELINE },
{ '\027' /* C-w */, 0, MODEKEYEDIT_DELETEWORD },
{ '\033' /* Escape */, 0, MODEKEYEDIT_SWITCHMODE },
+ { '\n', 0, MODEKEYEDIT_ENTER },
{ '\r', 0, MODEKEYEDIT_ENTER },
{ KEYC_BSPACE, 0, MODEKEYEDIT_BACKSPACE },
{ KEYC_DC, 0, MODEKEYEDIT_DELETE },
@@ -176,6 +177,7 @@
{ 'X', 1, MODEKEYEDIT_BACKSPACE },
{ '\003' /* C-c */, 1, MODEKEYEDIT_CANCEL },
{ '\010' /* C-h */, 1, MODEKEYEDIT_BACKSPACE },
+ { '\n', 1, MODEKEYEDIT_ENTER },
{ '\r', 1, MODEKEYEDIT_ENTER },
{ '^', 1, MODEKEYEDIT_STARTOFLINE },
{ 'a', 1, MODEKEYEDIT_SWITCHMODEAPPEND },
@@ -219,6 +221,7 @@
{ '\005' /* C-e */, 0, MODEKEYCHOICE_SCROLLDOWN },
{ '\006' /* C-f */, 0, MODEKEYCHOICE_PAGEDOWN },
{ '\031' /* C-y */, 0, MODEKEYCHOICE_SCROLLUP },
+ { '\n', 0, MODEKEYCHOICE_CHOOSE },
{ '\r', 0, MODEKEYCHOICE_CHOOSE },
{ 'j', 0, MODEKEYCHOICE_DOWN },
{ 'k', 0, MODEKEYCHOICE_UP },
@@ -281,6 +284,7 @@
{ '\025' /* C-u */, 0, MODEKEYCOPY_HALFPAGEUP },
{ '\031' /* C-y */, 0, MODEKEYCOPY_SCROLLUP },
{ '\033' /* Escape */, 0, MODEKEYCOPY_CLEARSELECTION },
+ { '\n', 0, MODEKEYCOPY_COPYSELECTION },
{ '\r', 0, MODEKEYCOPY_COPYSELECTION },
{ '^', 0, MODEKEYCOPY_BACKTOINDENTATION },
{ 'b', 0, MODEKEYCOPY_PREVIOUSWORD },
@@ -329,6 +333,7 @@
{ '\027' /* C-w */, 0, MODEKEYEDIT_DELETEWORD },
{ '\031' /* C-y */, 0, MODEKEYEDIT_PASTE },
{ '\033' /* Escape */, 0, MODEKEYEDIT_CANCEL },
+ { '\n', 0, MODEKEYEDIT_ENTER },
{ '\r', 0, MODEKEYEDIT_ENTER },
{ 'b' | KEYC_ESCAPE,0, MODEKEYEDIT_PREVIOUSWORD },
{ 'f' | KEYC_ESCAPE,0, MODEKEYEDIT_NEXTWORDEND },
@@ -363,6 +368,7 @@
{ '\020' /* C-p */, 0, MODEKEYCHOICE_UP },
{ '\026' /* C-v */, 0, MODEKEYCHOICE_PAGEDOWN },
{ '\033' /* Escape */, 0, MODEKEYCHOICE_CANCEL },
+ { '\n', 0, MODEKEYCHOICE_CHOOSE },
{ '\r', 0, MODEKEYCHOICE_CHOOSE },
{ 'q', 0, MODEKEYCHOICE_CANCEL },
{ 'v' | KEYC_ESCAPE,0, MODEKEYCHOICE_PAGEUP },
--
Simon Nicolussi, si...@sinic.name
http://www.sinic.name/
