Calculation issue with octave (data unexpectedly go to zero at some point)

28 messages
12
Open this post in threaded view
|

Re: Calculation issue with octave (data unexpectedly go to zero at some point)

 On Fri, Feb 28, 2014 at 4:51 PM, Ozzy Lash <[hidden email]> wrote: > > > > On Fri, Feb 28, 2014 at 3:16 AM, Juan Pablo Carbajal <[hidden email]> > wrote: >> >> On Fri, Feb 28, 2014 at 3:11 AM, Dmitri A. Sergatskov >> <[hidden email]> 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 >> > [hidden email] >> > 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 >> [hidden email] >> 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. _______________________________________________ Help-octave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/help-octave
Open this post in threaded view
|

Re: Calculation issue with octave (data unexpectedly go to zero at some point)

 On Fri, Feb 28, 2014 at 5:07 PM, Juan Pablo Carbajal <[hidden email]> wrote: > On Fri, Feb 28, 2014 at 4:51 PM, Ozzy Lash <[hidden email]> wrote: >> >> >> >> On Fri, Feb 28, 2014 at 3:16 AM, Juan Pablo Carbajal <[hidden email]> >> wrote: >>> >>> On Fri, Feb 28, 2014 at 3:11 AM, Dmitri A. Sergatskov >>> <[hidden email]> 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 >>> > [hidden email] >>> > 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 >>> [hidden email] >>> 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) _______________________________________________ Help-octave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/help-octave
Open this post in threaded view
|

Re: Calculation issue with octave (data unexpectedly go to zero at some point)

 Regarding the m(err) =0;  I must have cut and pasted wrong the first time.  I see what you are trying to do.  I was just thinking of m as a scalar (I was passing x and y as scalars as in the original script). It works now.  Sorry about that.  _______________________________________________ Help-octave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/help-octave
Open this post in threaded view
|

Re: Calculation issue with octave (data unexpectedly go to zero at some point)

Open this post in threaded view
|

Re: Calculation issue with octave (data unexpectedly go to zero at some point)

 In reply to this post by Gordon Haverland On 02/27/2014 05:57 PM, ghaverla wrote: ```From what I read, Octave is supposed to make use of a Mersenne-Twister for its core 0-1 RNG. And I am guessing you are drawing random numbers from somewhere in your calculations. If somehow you are getting random numbers from /dev/random instead of the Mersenne-Twister, you could be depleting your system of entropy, and hence every random you generate ends up being 0. /proc/sys/kernel/random/entropy_avail can help. My description assumes Linux, I don't know how this might translate to other hardware/OS. But I have seen entirely too many project descriptions, such as a playing card game, where they are drawing random numbers from /dev/random (directly or indirectly). ``` That could be a possible explanation, and if so, a simple solution would be to use /dev/urandom instead.  /dev/urandom does not exhaust the entropy because it just runs a PRNG off the /dev/random seed. _______________________________________________ Help-octave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/help-octave
Open this post in threaded view
|

Re: Calculation issue with octave (data unexpectedly go to zero at some point)

Open this post in threaded view
|

Re: Calculation issue with octave (data unexpectedly go to zero at some point)

 In reply to this post by Przemek Klosowski-7 On Fri, 28 Feb 2014 13:46:57 -0500 Przemek Klosowski <[hidden email]> wrote: > On 02/27/2014 05:57 PM, ghaverla wrote: > >  From what I read, Octave is supposed to make use of a > > Mersenne-Twister for its core 0-1 RNG.  And I am guessing you are > > drawing random numbers from somewhere in your calculations.  If > > somehow you are getting random numbers from /dev/random instead of > > the Mersenne-Twister, you could be depleting your system of > > entropy, and hence every random you generate ends up being > > 0.  /proc/sys/kernel/random/entropy_avail can help.  My description > > assumes Linux, I don't know how this might translate to other > > hardware/OS. > > > > But I have seen entirely too many project descriptions, such as a > > playing card game, where they are drawing random numbers > > from /dev/random (directly or indirectly). > That could be a possible explanation, and if so, a simple solution > would be to use /dev/urandom instead.  /dev/urandom does not exhaust > the entropy because it just runs a PRNG off the /dev/random seed. I think what Octave does by default, is what Perl can do optionally, and that is replace the rand() in libc, with a Mersenne-Twister. I would disagree with using /dev/urandom.  Switching to a long period RNG is a better solution. But, the OP now knows how to query the system for how much entropy it has stored up. Gord _______________________________________________ Help-octave mailing list [hidden email] https://mailman.cae.wisc.edu/listinfo/help-octave