#163 an odd differencing error?

closed-works-for-me
6
2012-01-07
2012-01-07
No

priority:6?
hi,
After the differencing of variables by add menu, i control them by "display values" or "edit values". but i've realized, recently, that the values of same variables in "display values" table are different from the values in "edit values" table. it seems some values in "edit values" table are wrong.

it doesn't occurs always or with every dataset, but sumtimes, some dataset (this is what makes it odd), i enclosed a sample (seaon file) which you may wanna consider.

i don't know if it effects the model estimation process.

Discussion

  • Anonymous - 2012-01-07

    season file

     
  • Anonymous - 2012-01-07
    • priority: 5 --> 6
     
  • Anonymous - 2012-01-07
     
  • Anonymous - 2012-01-07
     
  • Allin Cottrell

    Allin Cottrell - 2012-01-07

    Thanks for the report, but in fact there is no real problem here.
    The thing is that in the data editor window the values are displayed
    to full precision, and so can look different from the "nicely formatted"
    values under display data. Also it is sometimes necessary to widen
    the data editor window in order to see all the values fully -- that is
    something I've tried to improve in CVS.

     
  • Allin Cottrell

    Allin Cottrell - 2012-01-07
    • assigned_to: nobody --> allin
    • labels: --> data storage/retrieval
    • status: open --> closed-works-for-me
     
  • Anonymous - 2012-01-07

    please excuse me to insist, but i import this values with full precise already (the data has already its whole digits, no more), so an ordinary differencing is
    <78.151-78.150=0.001>
    however in "edit values" table it is
    <78.151-78.150=0.000999999999990564>
    it's not precise value, these are not equal mathematically.

     
  • Allin Cottrell

    Allin Cottrell - 2012-01-07

    When I said "full precision" I meant that what you're seeing in Edit Values
    is the actual computer representation of the numbers in question. These
    values are not "fully precise" in the mathematical sense: they cannot be, in
    digital computer arithmetic. For example, the number 78.165 (implicitly
    followed by an infinite number of zeros) cannot be represented in a standard
    double-precision value (of 64 bits). The following gretl script illustrates the
    point:

    scalar x1 = 78.165
    scalar x2 = 78.164
    scalar d = x2 - x1
    printf "%g - %g = %g\n", x2, x1, d
    printf "%.16g - %.16g = %.16g\n", x2, x1, d

    One may wish that the result of the subtraction above were exactly 0.001
    but it's not, in computer arithmetic. The values shown in gretl's Display
    Values (as in most other mathematical software) are cosmetically improved
    by showing something less than the full number of digits.

     
  • Anonymous - 2012-01-07

    it makes sense now. thank you very much for your answer.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks