convert dollar number to dollar string

[Paul Purvis]

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
   ss=SPACE$(TEMP2)
   ssPtr=STRPTR(ss)
   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
   GOTO EXITTHEFUNCTION
 END IF

[John Gleason]

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.

[Michael Mattias]

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.

[Paul Purvis]

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).

[Paul Purvis]

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.

paul

[Michael Mattias]

>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.

[Cliff Nichols]

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.

[Michael Mattias]

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.

MCM

[John Gleason]

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!

[Michael Mattias]

> the rounding discrepancy...

ptrss=STRPTR(ss)
 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?

MCM

[John Gleason]

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.
moneyamount=99999999999999.99@  'ok 8.04
moneyamount=99999999999999.99@@ 'not ok
moneyamount=99999999999999.99## 'not ok

[Paul Purvis]

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
example
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

doublechecklastdigits=1
checklastdigits=bla bla bla
end if



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


paul

[Paul Purvis]

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.
paul

added
found this thread

http://www.powerbasic.com/support/pbforums/showthread.php?t=23740

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.

[Michael Mattias]

#DEBUG OVERFLOW ON
FUNCTION Foo..


 ON ERROR  GOTO Errortrap
 Z = X * Y

ErrorTrap:
  IF ERR = %ERROR_OVERFLOW THEN
    xxxxxx

My bad, I forgot: #DEBUG OVERFLOW ON is still in the New Feature Suggestion box.

[John Gleason]

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.

[Michael Mattias]

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.