6 Replies Latest reply: May 15, 2014 9:58 AM by Patrick 123 RSS

    Numeric Field Length in the Trillions

    Patrick 123

      Hello,

      My colleague created a model to read report in which a numeric number of  -35,342,090,241,019 existed. The trap she made covered enought characters. When she verified the traps, the verification stopped at this point stating "Text for field lcy cannot be converted into a valid number." without indicating why.

       

      I suspected it was due to Monarch 8 limitation below:

       

      Numeric field length 17 characters (15 significant digits, a negation sign and a decimal point, up to 9 decimals).

       

      However, if I counted the significant digits they were less than 15.

       

      Can anyone help on this? My solution for her for the time being was to trap this field as character and massaged it later down the track to convert it back into numeric. Not elegant, and I did not like it. Any other solution?

       

      We are using monarch pro 8 on win 2000

       

      Thanks in advance.

      Patrick

        • Numeric Field Length in the Trillions
          Grant Perkins

          Patrick,

           

          I just ran a quick check in V9 and and using a numeric runtime entry field (quickest thing I could set up) I could enter

          -35,342,090,241,019.00 as a value so long as I did not try to specify the field to have 2 decimal places. 1 d place was OK. If I tried to set 2 dp I got an error pretty much the same as you see for verify.

           

          Have you played with the number of dp set for the field? If so did it produce anything different to my V9 experience? I can check V8 tomorrow - right now here it is somewhat late (or early) and my machine has slowed due to virus checking activity so not a good time to be experimenting much.

           

           

          Grant

          • Numeric Field Length in the Trillions
            Data Kruncher

            I was able to trap the value, just as you posted, with v8 Pro without any problems. But it does error if you set two decimal places in the field definition.

             

            I even went so far as to export it to an Excel file. That file opened just fine, with the correct value.

            • Numeric Field Length in the Trillions
              Patrick 123

              Thanks for quick response folks,

              I changed to 0 and 1 decimals in the field definition and it verified well. I suppose with 2 decimals the character counts become more than 17. And this is more than Monarch 8 spec.

               

              Perhaps with the global use of MOnarch where in some countries monetary values are in the trillions, Datawatch should expand the numeric specification.

               

              Thanks again.

              • Numeric Field Length in the Trillions
                joey

                Originally posted by Patrick 123:

                 

                Perhaps with the global use of MOnarch where in some countries monetary values are in the trillions, Datawatch should expand the numeric specification.

                /b[/quote]Good point that I never would have realized.  Personally, I woudln't mind having that problem in the US, especially in Net Income on our Income Statement.   smile.gif[/img]

                • Numeric Field Length in the Trillions
                  Grant Perkins

                  Many systems don't have even the 17 digits that Monarch offers. The issues is (and it was even more significant in earlier days) how many bytes one needs to allocate to store the number. The more bytes the bigger the record, the more storage required and the longer processing will take - even if the great majority of the contents of the field are not needing the large capacity.

                   

                  Before Europe mostly converted to the Euro I worked for a company supplying systems to many parts of the world including Italy where the Lira was in use. The numbers could be huge - but were never used in general commerce (and certainly not with decimals) because the calculation would be somewhat meaningless in real value terms. I forget the details now but the lira values were usually divided by a decimal factor that brought them into line with the numbers used on other currencies though many of those were, at the time, exchanging at about 10 local units to 1 GB pound which meant that all the numbers that we were dealing with were a factor of 10 greater than the core system was designed for (Actually about 7 since the core design of the system was of US origin but of course that made little difference to the number of digits provided for storing numeric and currency values.)

                   

                  Another factor to consider was reporting - very large numbers become a nightmare for report layouts. As I recall we added a couple extra characters for calculated (on the fly) column totals and similar but those larger sized field displays only existed in the report printing programs where and when the report design allowed them to be used.

                   

                  Ultimately the decision has to be whether to carry the data storage and processing overhead in order to satisfy what is, for most people, a very occasional use of large (by number of digits)  numbers (unless working in the scientific community.)

                   

                  17 digits is a very large number (one assumes the decimals can be dropped as being rather irrelevant in that case). Whenever I have seen numbers that big reported in the past it usually meant that there was a bug in a program somewhere!   :eek: 

                   

                   

                  Grant

                  • Numeric Field Length in the Trillions
                    Patrick 123

                    Grant your points taken.

                     

                    The question now is whether it will be easier to change the software developers globally or the technocrat of these countries to devalue their currencies. I am not answering this one. Perhaps, the question should not have been raised in the first place. Silly me.

                     

                    Cheers