Announcement

Collapse
No announcement yet.

mis-sum?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mis-sum?

    I have five numbers (shown below) that were determined elsewhere
    in the program.

    When these are added, it seems to be off by one. Is there any
    I can do to make the addtion more accurate?

    9
    1364
    0
    5243216
    14776336

    The sum is 20020925, but it returns 20020924 for some reason.

    I am using the statement:
    TotVal=0
    [snipped]
    If K > yeer, then
    TotVal = TotVal + K
    End if

    Print "I believe the number you are looking for is: ########";TotVal


    What can I do to make the values more accurate? Thank you.

    ------------------

  • #2
    The numbers added up fine on my compiler. There must be something,
    somewhere else in the program. How about posting everything between
    the IF/END IF and let's have a better look.

    ------------------

    Oops! I can see you already did that but we are going to have to
    have a little more to work with.



    [This message has been edited by Mel Bishop (edited April 02, 2002).]
    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.

    Comment


    • #3
      I can post it, but, it is confusing as I have no comments on
      it yet.

      I just did a debug and the value is showing in exponent format,
      which is +not+ what I planned. The values should be no higher
      than eight digits.

      What I have done is written two programs. The first one takes
      the date in format YYYYMMDD and converts it to a base 62 number
      system. Base 62 is 0-9 A-Z a-z, giving me 62 digts. I always
      get a 5 digit representation.

      The date of Mar 31st, 2002, for example is 20020331, and
      converts to 1M0Cb.
      The date of Sep 25th, 2002, for example is 20020925, and
      converts to 1M0M9.

      As far as I can tell, this one works fine according to my
      calculator and math by hand.

      The 2nd program takes the code and supposedly gives me back
      the original date number.

      My intention for this is to convert number from one base to
      another.

      Ok, with all that in mind, I did a debug of the 2nd program,
      the numbers are in exponential format, not fixed eight digit.
      Is that a clue?

      I will post the program if you still want me to, but it does
      look weird.

      Thanks.

      Robert

      ------------------

      Comment


      • #4
        Where is the value for K coming from ? The result of what ?

        What is the ultimate purpose of the stored converted dates ?
        ------------------


        [This message has been edited by OTTO WIPFEL (edited April 02, 2002).]

        Comment


        • #5
          Okay, I can see where you are coming from now. You are taking
          a date and compressing it, presumibly to save disk space. Have
          you considered the following example:

          20020925 <==> Sep 25, 2002

          Chop it up into:

          20 02 09 25

          and then convert the digits to CHR$()

          te$ = chr$(20) + chr$(02) + chr$(09) + chr$(25)

          Here you will have chopped the date string in half,
          (4-bytes vs. 5 vs. 8)

          Just a thought.
          Cheers


          ------------------


          [This message has been edited by Mel Bishop (edited April 02, 2002).]
          There are no atheists in a fox hole or the morning of a math test.
          If my flag offends you, I'll help you pack.

          Comment


          • #6
            Are all your variables declared as integer?
            Floating point arithmetic will get you every time!

            ------------------

            Comment


            • #7
              Originally posted by David J Walker:
              Are all your variables declared as integer?
              ummm, no. Would

              Integer K

              work?



              ------------------

              Comment


              • #8
                Originally posted by Mel Bishop:
                Okay, You are taking a date and compressing it, presumibly to
                save disk space.
                Exactly. I am a beta tester, and the files they are sending me
                have incredibly long names. Always one file per day, and I
                thought that would be a nifty way to do it.

                I am looking for my manual to read on declaring variables
                in Integer right now.

                Thanks.


                ------------------

                Comment


                • #9
                  Originally posted by David J Walker:
                  Are all your variables declared as integer?
                  Floating point arithmetic will get you every time!

                  If I'm wrong, please let me know, but I don't think this would
                  apply here. Let me give you an example:

                  I am typing this off-the-cuff so.....

                  To compress the string:

                  d$ = "20020925"
                  temp$ = ""

                  for x = 1 to len(d$) step 2
                  temp$ = temp$ + chr$(val(mid$(d$,x,2)))
                  next x

                  To expand the string:

                  d$ = ""
                  for x = 1 to len(temp$)
                  d$ = d$ + using$("##",asc(mid$(temp$,x,1)))
                  next x
                  replace " " with "0" in d$

                  ------------------
                  Okay, since you are taking a break, I took the opportunity to
                  actually test it. The mods have been made to the example above.
                  It now works, at least on my machine.


                  [This message has been edited by Mel Bishop (edited April 02, 2002).]
                  There are no atheists in a fox hole or the morning of a math test.
                  If my flag offends you, I'll help you pack.

                  Comment


                  • #10
                    Originally posted by Mel Bishop:
                    If I'm wrong, please let me know, but I don't think this would
                    apply here. Let me give you an example:
                    Hmm, I just got paged and have to go. At first overall glance,
                    it looks very workable. I will let you know tomorrow, ok?

                    Thanks.



                    ------------------

                    Comment


                    • #11
                      I think that message should probably read "integer class" rather than "integer"... you'll need at least a Long-integer to hold values of that size.

                      The comments about floating point are vaguely apt, but without seeing what your variable types actually are, what sort and how the values are assigned, and how/where else your arithmetic is using rounding or type-conversions, etc...

                      However, I suspect the problem is evident for two reasons:[list=1][*]If you are using single-precision your results are within the expected precision (6/7 digits of precision).
                      [*]Integer rounding in the PRINT USING statement. [/list=a]
                      In the post above, the PRINT statement appears most likely to be a PRINT USING statement. However, the format mask makes no allowance for floating point values... try the following code to see what I mean:
                      Code:
                      cls
                      for x# = 20020924# to 20020925# step .1#
                        print x#, using$("#########",x#)
                      next x#
                      Now, how would your variables that appear to contain only whole numbers end up with a total containing a fraction?

                      At a guess, most likely due to values that go beyond the precision of the chosen variable classes, and possibly numeric literals too. It could also be a tiny rounding error that becomes scaled up when multiplied by some other value. Basically, there are an infinite number of real-number values, but a limited number of floating-point values in any float-point numeric class... this fact alone is often the cause of very small rounding errors that can become very large when magnified/multiplied.

                      Bottom line is this: It is not really possible to be 100% sure of the cause of the programming error in your code unless we can see more of it, and possibly even run it.

                      I hope this helps!


                      ------------------
                      Lance
                      PowerBASIC Support
                      mailto:[email protected][email protected]</A>
                      Lance
                      mailto:[email protected]

                      Comment


                      • #12
                        Lance,

                        I think I have the problem solved. You are right, this
                        program uses PRINT USING a lot. The minimum possible value is
                        10000000 (It takes that many digits to fill a YYYYMMDD formated
                        date) and the maximum number I am allowing 99999999.

                        As a work-around, what I have done is check the value in both
                        directions (from Base 62 to Base 10 and then from Base 10 to
                        Base 62), and where the difference is -1, I just add the 1.

                        So far, that makes everything work. At least it does for the 30
                        or so dates I tested it with.

                        Thanks to everyone.

                        ------------------

                        Comment


                        • #13
                          Sounds like an old problem with "Rounding" which plagues Spreadsheet
                          calculations as well as older PB-DOS until the "@" variable arrived.

                          My solution was to add a "Fudge Factor" of 0.000005 to calculations
                          which did the trick.


                          ------------------

                          Comment


                          • #14
                            That is a "common trick" to defeat the IEEE standard of Bankers Rounding that PowerBASIC uses. Se the Users Guide documentation for more information.

                            ------------------
                            Lance
                            PowerBASIC Support
                            mailto:[email protected][email protected]</A>
                            Lance
                            mailto:[email protected]

                            Comment


                            • #15
                              Long integers.

                              MCM
                              Michael Mattias
                              Tal Systems Inc. (retired)
                              Racine WI USA
                              [email protected]
                              http://www.talsystems.com

                              Comment


                              • #16
                                That was suggested near the top of the thread, but thanks anyway.

                                ------------------
                                Lance
                                PowerBASIC Support
                                mailto:[email protected][email protected]</A>
                                Lance
                                mailto:[email protected]

                                Comment


                                • #17
                                  Originally posted by Robert Carneal:

                                  I am looking for my manual to read on declaring variables
                                  in Integer right now.

                                  [/B]
                                  If you're still interested, then you should look in your PB
                                  reference guide for the DIM statement. It's kind of long, but if
                                  you look for the sub-topic "Declaring nonarray variables" it will
                                  tell you all about declaring variables as integers, long integers
                                  and so on.

                                  Another good topic that's closely related is the DEFINT statement.
                                  You'll find it in the reference guide, bundled with DEFBCD and
                                  about half-a-dozen similar statements. I find it useful to start
                                  most of my programs with a statement like:

                                  DEFINT A-Z

                                  This will cause all undeclared variables that start with letters
                                  A-Z to default to integers, which is useful if you're not using a
                                  lot of floating point vars. PowerBasic Defaults to single precision
                                  floating point if I'm not mistaken.

                                  While you're there you might want to read the entire DIM statement
                                  description. Understanding the DIM statement is essential to mastering
                                  the basic language IMHO.

                                  Hope that helps


                                  ------------------

                                  Comment


                                  • #18
                                    That [use long integers instead of floats] was suggested near the top of the thread, but thanks anyway
                                    Yes, but it is the correct answer for storing dates as numbers, so I thought I would reinforce the suggestion.

                                    That, or maybe I am just getting bored reading the same post year after year; that post which reads, "I am using floating point numbers and experiencing rounding errors when I ask for more than the six digits of precision the manuals say I will get if I use single-precision floating point numbers."

                                    I often wonder how you folks in customer support can handle these kinds of questions so graciously. (I sure as hell can't).

                                    MCM


                                    Michael Mattias
                                    Tal Systems Inc. (retired)
                                    Racine WI USA
                                    [email protected]
                                    http://www.talsystems.com

                                    Comment


                                    • #19
                                      Lance
                                      mailto:[email protected]

                                      Comment


                                      • #20
                                        Might I suggest a section in the manual or the on-line help dealing with the accuracy of various types of variables, and the errors that can occur when using floating point?
                                        It seems to be an area that suffers from a serious lack of understanding, even by experienced programmers, and can produce some extremely undesirable effects if the wrong variable type is used.
                                        In iterative or recursive situations, the error can rapidly exceed the desired result!

                                        ------------------

                                        Comment

                                        Working...
                                        X