Re: [OctDev] An improvement to ranks.m:

2012-05-02 Thread Dave Goel
[...] > > Hi Dave > > I'm forwarding your e-mail to the octave mailing list (this is the > mailing list for octave forge packages, but ranks is part of octave > core). Also, the best place to submit this would be the patch tracker > on savannah http://savannah.gnu.org/patch/?group=octave > > One

[OctDev] Resending: An improvement to ranks.m with no attachments:

2012-05-01 Thread Dave Goel
2007, 2008, 2009 Kurt Hornik +## 2007, 2008, 2009 Kurt Hornik +## Copyright (C) 2012 Dave Goel ## ## This file is part of Octave. ## ## Octave is free software; you can redistribute it and/or modify it -## under the terms of the GNU General Public License as published by -## the Free Software Found

[OctDev] An improvement to ranks.m:

2012-05-01 Thread Dave Goel
2000, 2002, 2004, 2005, 2006, -## 2007, 2008, 2009 Kurt Hornik +## 2007, 2008, 2009 Kurt Hornik +## Copyright (C) 2012 Dave Goel ## ## This file is part of Octave. ## ## Octave is free software; you can redistribute it and/or modify it -## under the terms of the GNU General P

Re: [OctDev] A plea for a built-in cummax

2009-02-17 Thread Dave Goel
> > Søren writes: >> There seems to be no easy way to achieve a cummax (a simple O(n) >> operation) while avoiding loops. There are some ways to achieve >> it[1], but they all end up being > O(n). > > It's been a while, but I thought I should write and say that the > excellent Jaroslav Ha

Re: [OctDev] Same problem in others: Mann Whitney: u_test Re: Kolmogorov smirnoff test for two samples: bug

2008-12-09 Thread Dave Goel
> Looks like code and docs are not in sync. I guess the only way to avoid touching the code in these examples is to swap "x" and "y" in the docs - that will make the p value consistent with the code, but then, of course, the meaning of the sign of the corresponding statistic gets flipped around.

[OctDev] Same problem in others: Mann Whitney: u_test Re: Kolmogorov smirnoff test for two samples: bug

2008-12-09 Thread Dave Goel
Dave Goel <[EMAIL PROTECTED]> writes: > Consider a=[1 2 3 4], and b=[5 6 7 8]. > > The null is a = b. The alt. is !=. > > We get > > octave:3> kolmogorov_smirnov_test_2 (a,b,"!=") > pval: 0.0366311 > > > > Now consider an even mo

Re: [OctDev] A plea for a built-in cummax

2008-10-31 Thread Dave Goel
"Jaroslav Hajek" <[EMAIL PROTECTED]> writes: [...] > > Just out of curiosity, what use is "cumulative p-norm" for? > Oh, was that to me? As in, why do I want a cummax? There have been several separate issues that all hinged on this recently. The most recent is when I wanted to take a functio

Re: [OctDev] A plea for a built-in cummax

2008-10-30 Thread Dave Goel
Dave Goel <[EMAIL PROTECTED]> writes: > Why re-implement the wheel? We should simply use the exact same > logic and facilities used by tmpcumsum. Sorry, I meant: cumsum. > > Nonetheless, here is a for loop that handles the n-dimensional case. > I am attaching the 3 files a

Re: [OctDev] A plea for a built-in cummax

2008-10-30 Thread Dave Goel
> > Yeah, I can't come up with anything of the top of my head. But I'll make > you a deal. If you write an m-file version using for-loops, that handle > the N-dimensional case, then I'll re-implement it in C++. I am including here an m-version, tested, and also attaching it. But, really, I sta

Re: [OctDev] A plea for a built-in cummax

2008-10-30 Thread Dave Goel
-Original Message- Søren Hauberg <[EMAIL PROTECTED]> writes: > tor, 30 10 2008 kl. 17:05 -0400, skrev Dave Goel: >> There seems to be no easy way to achieve a cummax (a simple O(n) >> operation) while avoiding loops. There are some ways to achieve >>

[OctDev] A plea for a built-in cummax

2008-10-30 Thread Dave Goel
There seems to be no easy way to achieve a cummax (a simple O(n) operation) while avoiding loops. There are some ways to achieve it[1], but they all end up being > O(n). Thinking about cummax, that is about the only thing in this category that one cannot achieve using cumsum (and/or cumprod). I

Re: [OctDev] Bug in 3.0.1's betainc function (was Re: More than just an inconvenience Re: But in t_cdf: sporadic zero's when "no need")

2008-05-13 Thread Dave Goel
I have looked up matlab (TM)'s answers at a friend's workstation: > >> betainc (.75, 2047, .5) > > 4.437e-258 matlab: 4.437e-258 > >> betainc (.85, 2047, .5) > > 0 matlab: 1.0659e-146 > ^^ If it returned a zero for .85, it should either do likewise for > .75, or it should return a better ans

[OctDev] Bug in 3.0.1's betainc function (was Re: More than just an inconvenience Re: But in t_cdf: sporadic zero's when "no need")

2008-05-13 Thread Dave Goel
>> [ tcdf bug reported] >> >> > > This is an octave core function and so issues should be reported to > [EMAIL PROTECTED] That being said you should upgrade from 2.1.73 as that > is a very old version of Octave. The latest stable release is 3.0.1. > Also the t_cdf function had its name changed

[OctDev] More than just an inconvenience Re: But in t_cdf: sporadic zero's when "no need"

2008-05-12 Thread Dave Goel
3.0609e-14 octave:25> t_cdf (-31.1,4094) ans = 1.2780e-14 -Original Message- Dave Goel <[EMAIL PROTECTED]> writes: > The 0, reported in line 10 below, is clearly not due to an "underflow" > somewhere, because, as you see below, the values go as far down as &g

[OctDev] But in t_cdf: sporadic zero's when "no need":

2008-05-12 Thread Dave Goel
The 0, reported in line 10 below, is clearly not due to an "underflow" somewhere, because, as you see below, the values go as far down as 10^-247. octave:9> t_cdf (-26.0,4094) ans = 5.2275e-14 octave:10> t_cdf (-26.534,4094) ans = 0 octave:11> t_cdf (-26.6,4094) ans = 2.6505e-15 octave:16>