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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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.