On 10 Oct 2012, at 20:14, Ed Meyer wrote:
>
>
> On Wed, Oct 10, 2012 at 10:10 AM, c. <
address@hidden> wrote:
>
> On 10 Oct 2012, at 19:00,
address@hidden wrote:
>
> > Message: 2
> > Date: Wed, 10 Oct 2012 09:52:54 -0700
> > From: Ed Meyer <
address@hidden>
> > To: "c." <
address@hidden>
> > Cc:
address@hidden, octave maintainers mailing list
> > <
address@hidden>
> > Subject: Re: [OctDev] Test failures due to tolerance in fftfilt.m
> > Message-ID:
> > <
address@hidden>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > On Wed, Oct 10, 2012 at 1:11 AM, c. <
address@hidden> wrote:
> >
> >>
> >> On 10 Oct 2012, at 09:16, Daniel J Sebald wrote:
> >>
> >>>> I propose fixing this test by replacing the tolerance eps with something
> >>>> like 2*eps*norm(z)
> >>
> >> FYI this could be expressed as
> >>
> >> 2 * eps (z)
> >>
> >> from the help text for eps () :
> >>
> >> "Given a single argument X, return the distance between X and the next
> >> largest value"
> >>
> >> c.
> >
> >
> > Thanks, Carlos, I wasn't aware of this capability. I thought it was just
> > what I needed until I
> > tried it on a vector, expecting something like eps(z) = eps*norm(z) but
> > what I get is eps(z(1)).
> > Is that the intended behavior?
>
> I don't think so, it is not compatible with Matlab:
>
> >> z = [1 2 3]
> z =
> 1 2 3
> >> eps (z)
> ans =
> 1.0e-15 *
> 0.2220 0.4441 0.4441
> >>
>
>
> I think this is a bug, could you please post a report?
> It should be quite easy to fix, but I am in a hurry now, I'll look at it tomorrow if no one does before ...
>
> > --
> > Ed Meyer
> c.
>
> I posted a bug report (37539) - I've looked at fixing it but it may be beyond my knowledge of octave. It seems like
> the easiest way would be to recurse on each element.