Loading ...
Sorry, an error occurred while loading the content.

Re: BUG: Output sheet or internal code...not sure which.

Expand Messages
  • Kevin Colagio
    ... Jonas, I looked into the code (gui/Utility.java) and BigDecimal is an import from java.math.BigDecimal. Digging out my Java 2 books (ack!) and visiting
    Message 1 of 8 , Dec 1, 2002
    • 0 Attachment
      --- In pcgen@y..., "pjak" wrote:
      > --- In pcgen@y..., "Kevin Colagio" wrote:
      >
      > > The HTML info hinted at above is this....Belt Pouch -1- holds the
      > > coins (1 pp, 58 gp, 1 sp, and 1 cp). The weight is reported as:
      > > 1.2199999 lbs. Is this right? As per the PHB (page 96), a
      > > monetary piece about 1/3 ounce, and there would be 50 to a
      > > lb....if I have 61
      > > pieces, then I'd have 1.22 lbs.....not 1.219999...that's probably
      > > where the error is being introduced, the math isn't being performed
      > > properly or rounded to 2 digits.
      >
      > Odds are that some calculations are being done as doubles or floats,
      > who do not handle fractions properly. The way I solved part of that
      > problem way back when was to use BigDecimal instead, but obviously
      > it's not being done everywhere (or maybe I simply didn't do
      > everything right. :)
      >
      > Post it as a bug report (if you want to dig into the code it's most
      > likely in either core/Equipment.java or gui/InfoEquipment.java that
      > the problems appear.)

      Jonas,

      I looked into the code (gui/Utility.java) and BigDecimal is an import
      from java.math.BigDecimal. Digging out my Java 2 books (ack!) and
      visiting the docs site, I see that BigDecimal is a native class. In
      the same file, there is a "trimZeros" call that is used....but that
      appears to not be part of the standard class.

      The BigDecimal class DOES have a "setScale" method that has two
      different implementations. Perhaps the "setScale" should be used
      instead of "trimZeros"? That would eliminate some extra code along
      the way too....

      I guess I don't quite understand why there is work with this type of
      number. Once the cost is set and once a count is determined, the cost
      would never have a variation farther from 0.00 than 0.01 (meaning, no
      0.0001 types of values) so anything else should never be used.

      Alternatively, a new data type can be defined that has a limit on the
      number of decimal places. I know that this would be the more complex
      way to do it, but it's one idea and it would be consistant across the
      application.

      I'll go out and file a bug report and refer to this post within the
      report... Let me know if there is anything else I can dig up or do to
      help.

      Kevin Colagio
    • Emily Smirle
      ... why would we never have a variation farther than two decimal places? I can define a unit of currency, call it the haypenny, and assign it the value 0.005
      Message 2 of 8 , Dec 1, 2002
      • 0 Attachment
        Kevin Colagio wrote:

        > I guess I don't quite understand why there is work with this type of
        > number. Once the cost is set and once a count is determined, the cost
        > would never have a variation farther from 0.00 than 0.01 (meaning, no
        > 0.0001 types of values) so anything else should never be used.

        why would we never have a variation farther than two decimal places? I
        can define a unit of currency, call it the haypenny, and assign it the
        value 0.005 if I wish. In some settings, especially those based around
        1800's britain or america, that kind of fraction is desireable.

        --
        "Alternately, you could check the list archives ... rather than
        rehashing a topic which has been rehashed into hash browns, and corned
        beef hash, eaten, excreted, composted, and sent in support of restoring
        central american rainforests." -- Rob Hines Jr.
      • pjak
        ... Seems likely. (Though I think I remember that there was some kind of problem with setScale.) ... cost ... no ... Actually, that s not neccessarily true.
        Message 3 of 8 , Dec 2, 2002
        • 0 Attachment
          --- In pcgen@y..., "Kevin Colagio" <kcolagio@y...> wrote:
          > The BigDecimal class DOES have a "setScale" method that has two
          > different implementations. Perhaps the "setScale" should be used
          > instead of "trimZeros"? That would eliminate some extra code along
          > the way too....

          Seems likely. (Though I think I remember that there was some kind of
          problem with setScale.)

          > I guess I don't quite understand why there is work with this type of
          > number. Once the cost is set and once a count is determined, the
          cost
          > would never have a variation farther from 0.00 than 0.01 (meaning,
          no
          > 0.0001 types of values) so anything else should never be used.

          Actually, that's not neccessarily true. Consider the old english
          system for instance (see
          http://www.deadline.demon.co.uk/wilkie/coins.htm for the horrid
          details.)

          > Alternatively, a new data type can be defined that has a limit on
          the
          > number of decimal places. I know that this would be the more
          complex
          > way to do it, but it's one idea and it would be consistant across
          the
          > application.

          Whoever it was who was writing this has recently returned to work (at
          least he asked for where his old Coin class had gone to) so hopefully
          this will be taken care of soon.

          /Jonas
        • Brass Tilde
          ... I don t know about soon, but he *is* making progress. Unfortunately, some things, such as the location of various code pieces, have changed rather
          Message 4 of 8 , Dec 2, 2002
          • 0 Attachment
            > Whoever it was who was writing this has recently returned to work (at
            > least he asked for where his old Coin class had gone to) so hopefully
            > this will be taken care of soon.

            I don't know about soon, but he *is* making progress. Unfortunately, some
            things, such as the location of various code pieces, have changed rather
            significantly since he was last able to work on it, so much of his time so
            far has been taken up by finding where all those pieces are now located.

            Now he has to figure out where the equipment objects are actually
            instantiated, and have their costs set, so he can test out whether or not
            the values are being set properly.

            Brass
          • Kevin Colagio
            I need to do a major rewind on this thread..... At the start of it, I was talking about the monetary values not adding up. Basically, all the equipment came
            Message 5 of 8 , Dec 2, 2002
            • 0 Attachment
              I need to do a major rewind on this thread.....

              At the start of it, I was talking about the monetary values not adding
              up. Basically, all the equipment came to X.YZ gp and it was showing
              up on the character sheets as x.yzabc gp in value.

              Later in the same post, I thought it may have to do with
              rounding...but what I was looking at (in that post) was the
              WEIGHT...which has nothing to do with the monetary values....

              I introduced a major point of confusion there and I wanted to 1)
              apoligize for the mix up and 2) reiterate that it is the TOTAL VALUE
              on the character sheets that is a flakey number (not that the weight
              always adds up nicely either). I'm not sure where the problem may be
              at this point....but if I knew where the Total Value is calculated, I
              could start there and do some back tracking....

              If I need to clarify, please let me know.

              Again, I'm sorry for the confusion.

              Kevin Colagio, wondering how he could have messed up something like
              weight and value.
            • gsbingl
              The total value should now be rounding properly with the next alpha build. The weight is still funky as it involves a lot of floating point conversions. Byngl
              Message 6 of 8 , Dec 2, 2002
              • 0 Attachment
                The total value should now be rounding properly with the next alpha
                build. The weight is still funky as it involves a lot of floating
                point conversions.

                Byngl

                --- In pcgen@y..., "Kevin Colagio" <kcolagio@y...> wrote:
                >
                > I need to do a major rewind on this thread.....
                >
                > At the start of it, I was talking about the monetary values not
                adding
                > up. Basically, all the equipment came to X.YZ gp and it was showing
                > up on the character sheets as x.yzabc gp in value.
                >
                > Later in the same post, I thought it may have to do with
                > rounding...but what I was looking at (in that post) was the
                > WEIGHT...which has nothing to do with the monetary values....
                >
                > I introduced a major point of confusion there and I wanted to 1)
                > apoligize for the mix up and 2) reiterate that it is the TOTAL VALUE
                > on the character sheets that is a flakey number (not that the weight
                > always adds up nicely either). I'm not sure where the problem may
                be
                > at this point....but if I knew where the Total Value is calculated,
                I
                > could start there and do some back tracking....
                >
                > If I need to clarify, please let me know.
                >
                > Again, I'm sorry for the confusion.
                >
                > Kevin Colagio, wondering how he could have messed up something like
                > weight and value.
              Your message has been successfully submitted and would be delivered to recipients shortly.