No announcement yet.

convert dollar number to dollar string

  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    John, that is tremendous.
    i learned a lot from that piece of code too.
    i am sure you wore yourself out on that one.

    i spent some time trying to crash the program since there was nothing else to write which would be faster.

    i believe this should be the only change to the only crash i could get out of it

     IF remains=0 THEN
       IF zerostringblank THEN GOTO exitthefunction
       IF temp2<1 THEN GOTO exitthefunction
       POKE BYTE,ssPtr+temp2-1,48
       IF temp2=1 THEN GOTO exitthefunction
       POKE BYTE,ssPtr+temp2-2,48
       IF temp2=2 THEN GOTO exitthefunction
       POKE BYTE,ssPtr+temp2-3,46
       IF temp2=3 THEN GOTO exitthefunction
       POKE BYTE,ssPtr+temp2-4,48
     END IF
    Last edited by Paul Purvis; 7 May 2008, 06:25 PM.
    p purvis


    • #22
      Thanks Paul, I gave it the ol' college try. hehheh. It doesn't wear me out too much because for some reason, my brain thinks about that kind of stuff whether I want it to or not. I'll put your mod there into the code above to make it more bulletproof so when you hit it with a hammer, it won't crack. I think creating the string might need to be moved up a couple lines too.


      • #23
        Did you ever notice how the ultimate fastest is always the ultimate un-maintainable?

        Sheesh, there's four years worth of GOTOs and multiple EXIT points in that one dinky little routine.
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]


        • #24
          my points to follow in writing routines
          point 1
          when you have a routine that does a specific job and the routine will be used in a lot of various programs, that routine should be written as efficient as possible and also be tested thoroughly and the routine should useful for many years.
          point 2
          the program should be written to execute with speed
          point 3
          the program should be written to have some flexibility so it can be used for multiple purposes if possible
          point 4
          the program should modular if possible (a function)
          point 5
          the program if possible should not depend on outside routines that may not be accessible to another programmer or program.
          point 6
          the program should transverse as many operating systems and compilers as possible
          point 7
          follow good programming rules

          rule 1 thru rule 99
          do not look a gift horse in the mouth

          some of my programming practices are:
          if your program is going to process lots of data, make the code as fast as possible, do not expect a user to have the fastest most current computer of today.
          matter of fact, assume he has one of the oldest computers and program for that kind of resource.

          never expect your program to be used just for a few years, program it as if you are going to be the one using it and you have to use if for 100 years.
          make your program as fast as possible using as little memory as possible.

          when it comes to data, plan for your program to be used in a very big way and make the access to that data as fast as possible and where the data can be backed up efficiently(efficiently means fast and the smallest in size of data being backed up and having full recovery). where data maybe old and never be changed again , plan for a way to remove the data from the active data and still have access to data.(in other words, the user should never have to look up something on paper if it was ever stored in the computer, storage device resources will always grow faster than the use of your program).
          Last edited by Paul Purvis; 8 May 2008, 02:18 PM.
          p purvis


          • #25
            some things i learned on this project, a routine that is performed many times in the same program.

            it is better sometimes just to have inline code as opposed to a loop of some sort where the loop may have some complicated code and there are not may iterations in the loop you are replacing.

            strings take time to build, a lot of time, specially if you are using concatenation.
            where a fixed length string can be used, use it, and learn to use pointers or any other routine that can change the byte(s) in the string if possible.
            if your program does not work well with a fixed length string, consider a static dynamic string variable and a static integer variable to be used as a flag, then mark the flag once the static dynamic string variable is created on the routines first use.

            assign static values using hex numbers
            i have not tested this but i would be place bets on it making the program faster. i am self taught, learned by necessity, and i never understood why some programmers defined variables with a hex number. it must be for speed in the program. even if it does not create more speed, you will appear smarter than other programmers(clothes makes the man right).
            sorry just hum mering myself.

            many times the longest approach to a problem is the shortest path to solving the problem, meaning using some of the simplest programming skills will produce the fastest code.

            use a mixture of programming concepts and routines to make your code better, faster is always better, always remember your program may be used in a high end processing environment

            use byref wherever possible as opposed to byval for speed when passing strings to functions.

            p purvis


            • #26
              >assign static values using hex numbers.... it must be for speed in the program

              If you are talking about inline numeric literals (e.g., LET X = 3) , using hex notation (LET X = &h3) does nothing at runtime because the evaluation is done at compile-time.

              Better still, if the value does not change, use an equate. That's why they exist.
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]


              • #27
                Slightly modified quote
                if you program, make the code as fast as possible, do not expect a user to have the fastest most current computer of today.
                matter of fact, assume he has one of the oldest computers and program for that kind of resource.
                BINGO< BANGO< BONGO

                wayyyy too many programs assume and even INSIST you have the latest and greatest...and yet some of the cleanest code I have seen (and the fastest) run on an old DOS machine, or Win95 or less

                The only good plan is plan with what you have for todays tools, and what you think may work in the future, and adjust to your "Application Scope" as time goes on.
                Engineer's Motto: If it aint broke take it apart and fix it

                "If at 1st you don't succeed... call it version 1.0"

                "Half of Programming is coding"....."The other 90% is DEBUGGING"

                "Document my code????" .... "WHYYY??? do you think they call it CODE? "


                • #28
                  Dispelling the rest of the old wives' tales you've heard.......
                  use byref wherever possible as opposed to byval for speed when passing strings to functions.
                  Not universally true; depends on how many times the parameter is referenced in the function.
                  where a fixed length string can be used, use it
                  Not universally true; depends on the application. FWIW, when performing a string operation (eg LEFT$, MID$) on a fixed string variable the compiler creates and destroys a temporary string anyway.

                  faster is always better, always remember your program may be used in a high end processing environment
                  Absolutely untrue. In a 'batch' program, a few seconds difference of run-time is immaterial; resource (memory, disk) usage and maintainability should get more 'weight' when choosing your coding technique.

                  Remember, you might not be the next programmer to have to update or enhance this program.

                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]


                  • #29
                    Paul, here is the situation re. the rounding discrepancy:
                      moneyamount=99999999999999.99          'this produces an error in the returned string .98 for cents
                      moneyamount=9999999999999999 / 100     'this is ok
                      moneyamount = VAL("99999999999999.99") 'this is ok
                      moneyamount=99999999999999 + .99       'this is ok
                      'So the max val is 99,999,999,999,999.99 ~100 trillion BUT must be properly fed to function because of issue
                      'PB support is aware of, and on the case!


                    • #30
                      > the rounding discrepancy...
                       POKE LONG,ptrss+temp2-4, &h30302e30
                        IF remains>99999 THEN
                          IF temp2<7 THEN ss=STRING$(TEMP2,"%"):GOTO EXITTHEFUNCTION
                          POKE BYTE,ptrss+temp2-7,44
                          IF remains>99999999 THEN
                            IF temp2<11 THEN ss=STRING$(TEMP2,"%"):GOTO EXITTHEFUNCTION
                            POKE LONG,ptrss+temp2-12, &h20202C20
                            IF remains>99999999999 THEN
                              IF temp2<15 THEN ss=STRING$(TEMP2,"%"):GOTO EXITTHEFUNCTION
                              POKE BYTE,ptrss+temp2-15,44
                              IF remains>99999999999999 THEN
                                IF temp2<19 THEN ss=STRING$(TEMP2,"%"):GOTO EXITTHEFUNCTION
                                POKE BYTE,ptrss+temp2-19,44
                      To eliminate rounding errors in that kind of code, a good step is to explicity type your numeric literals, eg "999999999&" or "99999999!", not just "9999999".

                      I might also do that for performance purposes... in that I do not know how PB casts numeric literals when they appear in an expresssion. If I've already cast the literal to a compatible type for the operation, then that conversion is done at compile time and will not be required at runtime.

                      Note, I would not be surprised if the compiler already did this, but why guess?

                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]


                      • #31
                        Surprisingly, I discovered these are ok in 8.04 as a workaround:
                          LOCAL MONEYAMOUNT AS CUR
                        'or LOCAL MONEYAMOUNT AS CUX 
                        'or LOCAL MONEYAMOUNT AS EXT
                        'Then use the [B]single[/B] currency @ sign. @@ or ## will not work.
                        [email protected]  'ok 8.04
                        [email protected]@ 'not ok
                        moneyamount=99999999999999.99## 'not ok


                        • #32
                          here is a crazy suggest, a brain storm of such right now.
                          there maybe a way to double check the returned strings.
                          this is just a thought

                          if the value of the amount is over or under a certain amount(+-large values).
                          then try to get the last digits(possibly just the cents) of what value was passed and compare those digits to the string returned.

                          actually you can incorporate a check feature of a value being out of range too into this as well
                          just throwing some number out there in this

                          if value>9999999999.99 then
                          if value>99999999999999.99 then returnstring="%%%%%%%%%%%%":exit function
                          rem variable doublechecklastdigits as a long 0 or 1
                          rem variable checklastdigits=00 as a long 00 thru 99

                          checklastdigits=bla bla bla
                          end if

                          if doublechecklastdigits then
                          bla bla bla
                          if val(mid$(returnstring,#,2))<>checklastdigits then
                          end if
                          end if

                          p purvis


                          • #33
                            in the above
                            i believe there are already if then for values so if the above where implemented
                            the if statement for checking values over a certain amount is already in place to catch the larger numbers and only a if statement at then end to check to routines.

                            there would be another way to consider.
                            letting pb handle the conversion on the larger numbers to string.
                            i do not know what the constraints are that way but if in fact pb does have certain issue and those issues are worked out in the future, that would solve the problem then.
                            also it might seem ok to let users see the numbers in exponential form as opposed to returning an incorrect string.

                            found this thread
                            for dealing with extended precision values

                            and on a last thought
                            maybe the value if over $$$$$ returnstring is going to be %%%%%%%%%%%%%%%%%%%
                            to force the programmer to come up with his own way of representing values over a certain amount and which would better server the users and readers.
                            scientifc notation if not good if you do not know what it stands for and also there possibly could be somebody doing ocr work on printed documents, and i do not really like the %%%%%% it looks like 96 anyways, but what you going to do, huh, anybody having that much money is to old to read it anyways.
                            the %%%%%%%%%%%%%%%%% way would be staying with a standard of not producing any return strings of values that would not fit.
                            Last edited by Paul Purvis; 9 May 2008, 04:13 PM.
                            p purvis


                            • #34
                              #DEBUG OVERFLOW ON
                              FUNCTION Foo..
                               ON ERROR  GOTO Errortrap
                               Z = X * Y
                                IF ERR = %ERROR_OVERFLOW THEN
                              My bad, I forgot: #DEBUG OVERFLOW ON is still in the New Feature Suggestion box.
                              Michael Mattias
                              Tal Systems (retired)
                              Port Washington WI USA
                              [email protected]


                              • #35
                                Hey, "%" sure does look like a 96! That could indeed fool OCR software I believe. And keep in mind: the %%%'s could appear not just in big numbers, but small ones too--if you specify too small of a length in the 2nd parameter.

                                Also, I think that checking the output isn't really needed. I haven't seen the rounding problem with, say currency values already properly stored as 8 bytes, or in fact any other type (CUX, EXT, DOUBLE). The discrepancies only occur on input of the original values, which is where extra care need be taken.

                                Added: I may have misunderstood: were you talking above about checking numbers larger than +/-100 trillion? That could be easily added to the function. I thought you were asking about the rounding issue.
                                Last edited by John Gleason; 9 May 2008, 05:44 PM.


                                • #36
                                  I believe the "problem" (I shall not remove the quotes) of rounding and/or lack of decimal precision for inline numeric literals has come up here before.

                                  IIRC there is some kind of limit on the number of decimal digits which are accepted at compile time.

                                  Also IIRC, the way to get more decimal precision for constants is to eshew literals by CALCULATING the values in code and using the calculated variable for comparisons and arithmetic.
                                  Michael Mattias
                                  Tal Systems (retired)
                                  Port Washington WI USA
                                  [email protected]