[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Calculation issue with octave (data unexpectedly go to zero at some
From: |
Juan Pablo Carbajal |
Subject: |
Re: Calculation issue with octave (data unexpectedly go to zero at some point) |
Date: |
Fri, 28 Feb 2014 17:08:08 +0100 |
On Fri, Feb 28, 2014 at 5:07 PM, Juan Pablo Carbajal
<address@hidden> wrote:
> On Fri, Feb 28, 2014 at 4:51 PM, Ozzy Lash <address@hidden> wrote:
>>
>>
>>
>> On Fri, Feb 28, 2014 at 3:16 AM, Juan Pablo Carbajal <address@hidden>
>> wrote:
>>>
>>> On Fri, Feb 28, 2014 at 3:11 AM, Dmitri A. Sergatskov
>>> <address@hidden> wrote:
>>> >
>>> > Back to the original problem.
>>> > I think if we pre-scale argument such that X is about MAXINT, we get the
>>> > max
>>> > possible accuracy in this situation. In this particular case
>>> >
>>> >
>>> >
>>> > Gamma = 1.62e7;
>>> > duration = 10/Gamma;
>>> > dt = 0.0025/Gamma;
>>> > t = 0:dt:duration;
>>> > sc = 2^31 / duration ;
>>> > y = mod (sc*t, sc*0.2/Gamma)/sc;
>>> >
>>> > [a,b] = find(abs(y) < eps);
>>> >
>>> > sum(a)
>>> > ans = 51
>>> >
>>> > b =
>>> >
>>> > Columns 1 through 11:
>>> >
>>> > 1 81 161 241 321 401 481 561 641 721
>>> > 801
>>> >
>>> > Columns 12 through 22:
>>> >
>>> > 881 961 1041 1121 1201 1281 1361 1441 1521 1601
>>> > 1681
>>> >
>>> > Columns 23 through 33:
>>> >
>>> > 1761 1841 1921 2001 2081 2161 2241 2321 2401 2481
>>> > 2561
>>> >
>>> > Columns 34 through 44:
>>> >
>>> > 2641 2721 2801 2881 2961 3041 3121 3201 3281 3361
>>> > 3441
>>> >
>>> > Columns 45 through 51:
>>> >
>>> > 3521 3601 3681 3761 3841 3921 4001
>>> >
>>> >
>>> > Perhaps we should include such pre-scaling in the code of rem and mod
>>> > if we try for matlab compatibility...
>>> >
>>> > Dmitri.
>>> > --
>>> >
>>> >
>>> > _______________________________________________
>>> > Help-octave mailing list
>>> > address@hidden
>>> > https://mailman.cae.wisc.edu/listinfo/help-octave
>>> >
>>>
>>> Hi I am opening a bug for mod, flagged as incompatible result. I get
>>> the following comaring betwene octave 3.8.1 and matlab2008b
>>> Gamma = 1.62e7;
>>> duration = 10/Gamma;
>>> dt = 0.0025/Gamma;
>>> t = 0:dt:duration;
>>> y = mod (t, 0.2/Gamma);
>>> find (y==0,3,'first')
>>>
>>> octave
>>> 1 241 401
>>>
>>> r2008b
>>> 1 81 161
>>>
>>> Reading the help of mod in matlab it says
>>> MOD(x,y) is x - n.*y where n = floor(x./y) if y ~= 0. If y is not an
>>> integer and the quotient x./y is within roundoff error of an integer,
>>> then n is that integer.
>>>
>>> So indeed matlab is giving a result considerig roundoff error, I
>>> assume they do something like
>>> function m = mod_ml(x,y)
>>> if fix(y) != y
>>> err = abs (x./y - round(x./y)) < sqrt (eps);
>>> m = mod (x,y);
>>> m(err) = 0;
>>> endif
>>> endfunction
>>>
>>> Shall I fix our mod function?
>>>
>>> @Renaud: you can use mod_ml for the moment and tell us if it fixes our
>>> issues
>>> _______________________________________________
>>> Help-octave mailing list
>>> address@hidden
>>> https://mailman.cae.wisc.edu/listinfo/help-octave
>>
>>
>> Juan,
>>
>> What is the line:
>>
>> m(err) = 0;
>>
>> in your mod_ml function trying to do. I tried it in an ancient version of
>> octave (3.0.5) and it didn't increment n at all, but if I changed the line
>> to:
>>
>> m=0;
>>
>> It gave 4001 increments.
>>
>> Bill
>
> The function mod_ml returns a zero when the relation when x is
> divisible y, i.e. x is congruent modulo y with zero.
> m(err) =0
> replaces all answers of mod that weren't zero but should have been if
> one accepts the matlab behavior of defining a tolerance interval of
> length 2*eps around each integer.
sorry, the interval has 2*sqrt(eps)
- Re: Calculation issue with octave (data unexpectedly go to zero at some point), (continued)
- Re: Calculation issue with octave (data unexpectedly go to zero at some point), Dmitri A. Sergatskov, 2014/02/27
- Re: Calculation issue with octave (data unexpectedly go to zero at some point), Brian Kaczynski, 2014/02/27
- Re: Calculation issue with octave (data unexpectedly go to zero at some point), Dmitri A. Sergatskov, 2014/02/27
- Re: Calculation issue with octave (data unexpectedly go to zero at some point), Ben Abbott, 2014/02/27
- Re: Calculation issue with octave (data unexpectedly go to zero at some point), Dmitri A. Sergatskov, 2014/02/27
- Re: Calculation issue with octave (data unexpectedly go to zero at some point), Ben Abbott, 2014/02/27
- Re: Calculation issue with octave (data unexpectedly go to zero at some point), Dmitri A. Sergatskov, 2014/02/27
- Re: Calculation issue with octave (data unexpectedly go to zero at some point), Juan Pablo Carbajal, 2014/02/28
- Re: Calculation issue with octave (data unexpectedly go to zero at some point), Ozzy Lash, 2014/02/28
- Re: Calculation issue with octave (data unexpectedly go to zero at some point), Juan Pablo Carbajal, 2014/02/28
- Re: Calculation issue with octave (data unexpectedly go to zero at some point),
Juan Pablo Carbajal <=
- Re: Calculation issue with octave (data unexpectedly go to zero at some point), Ozzy Lash, 2014/02/28