variable = calling PRINT USING template$
..........
.........
print variable
template$ = "###,.##"
...............
...............
print using template$
variable = calling PRINT USING template$???
I wrote one exactly like that description but it is currently being held hostage in the lost realm of our old forum. Bummer.
Hi
I've just a little fallen in confusion...
in pseudocode
FUNCTION num2str(num as DOUBLE)
num2str = print using "####,.##" 'obviously this DOES NOT WORK just for example
END FUNCTION
Here is what I was trying to achieve. Print using ##### etc... works fine, but, it has some padding that I do not want
I am curious what is the difference with what is wanted here and this:
https://www.qb64.org/forum/index.php?topic=840.msg100462#msg100462
Code: QB64: [Select]
counter = 1 somenumber = 1000000000.23 CLS '<<<<<<<<<<<<< added to make sure seeing fresh number clearly 'somenumber = somenumber + 2.4 PRINT somenumber '<<<<<<<<<<<<<<<<< moved to compare equal values '// convert to number delimted string tempStr = "" number = tempStr tempStr = "" ' adjust len of precisio to match precision = tempStr xnum2str$ = number + precision
This looks solid as a rock without _display using QB64 X64. I will complain precision 3, gives only 2 decimal places.
Testing with X32 and negative numbers (dec set at 2), I find error in code:
I also see that my commatose code is not handling neg numbers quite right either. dang!
That may be a glitch with the display flickering.
Try adding _DISPLAY to your loop to stop flicker.
If that doesn’t work, put a check to count commas (a DO LOOP with INSTR can do that easily enough), and then pause execution when a value appears without it. Print that value to the screen, and we can use it to figure out why the comma would appear sometimes, but not others.
Once the fringe case is identified (if it exists), then it can be debugged/accounted for. ;)
btw, after reading this and my otherone - they are extremely similar, it is the same issue, with a sleight variation - any chance a mod can move this to that thread. Makes more sense.
I think I just solved it too, it is something to do with the way I am parsing the string
using anything larger than 100k or 1mil the comma drifts. while I will look here in a sec, but for public curiosity, is qb64 strings zero based or 1?
abcdef
does "a" position = zero or 1?
Just as a random side comment on this subject, I've seen other BASICs with either an SPRINT/SPRINT USING statement (SPRINT -> PRINT to a string) or a USING$ function, which is probably implemented by "riding" the code of PRINT USING. Perhaps it might be worth thinking about implementing _USING$(pattern$,value)?
Just as a random side comment on this subject, I've seen other BASICs with either an SPRINT/SPRINT USING statement (SPRINT -> PRINT to a string) or a USING$ function, which is probably implemented by "riding" the code of PRINT USING. Perhaps it might be worth thinking about implementing _USING$(pattern$,value)?
As another side comment: would it be so difficult to interface (implement) two new reserved words with the C/C++ printf() and sprintf() stdio.h functions using their syntax and parameters that would avoid to "translate" the current PRINT USING while being more powerfull?
Just my two cents.
# Denotes a numerical digit. An appropriate number of digits should be used for values received.
Hi
fine to add meself to this thread again
I have wrote a my routine... :-)
yes! Why? As someone knows the way to write numbers in italian is different from that used here, (also date and some few other things...) so I try to make my algorithm in QB64 working on string format and letting to show international format (, for thousand and . for decimal or that italian that is the inverse system i.e. international 1,000,009.999 = italian 1.000.009,999 ). So here my work.
The following examples show the decimal separator and the thousands separator in various countries that use the Arabic numeral system.or you can expand your function to get Universal goal of accurate annotation for numbers...
Style Countries
1,234,567.89 Canada (English-speaking; unofficial), China, Hong Kong, Ireland, Israel, Japan, Korea, Malaysia, México, New Zealand, Pakistan, Philippines, Singapore, Taiwan, Thailand, United Kingdom, United States.
1234567.89 SI style (English version), Australia, Canada (English-speaking), China, Sri Lanka, Switzerland (officially encouraged for currency numbers only[40]).
1234567,89 SI style (French version), Albania, Belgium (French), Bulgaria, Canada (French-speaking), Czech Republic, Estonia, Finland, France, Hungary, Italy, Kosovo, Latin Europe, Norway, Peru, Poland, Lithuania, Russia, Slovakia, Slovenia, South Africa, Sweden, Switzerland (officially encouraged, except currency numbers[40]), Ukraine.
1,234,567·89 Ireland, Malaysia, Malta, Philippines, Singapore, Taiwan, United Kingdom (older, typically hand written)[41]
1.234.567,89 Argentina, Austria, Belgium (Dutch), Bosnia and Herzegovina, Brazil, Chile, Costa Rica, Croatia,[42][43] Denmark, Germany, Greece, Indonesia, Italy, Netherlands, Portugal, Romania, Russia, Slovenia, Spain,[44]Turkey, Vietnam.
12,34,567.89 Bangladesh, India (see Indian Numbering System).
1'234'567.89 Switzerland (computing), Liechtenstein.
1'234'567,89 Switzerland (handwriting).
1.234.567'89 Spain (handwriting).
123,4567.89 China (based on powers of 10 000—see Chinese numerals).
I wrote one exactly like that description but it is currently being held hostage in the lost realm of our old forum. Bummer.unfortunately the wayback machine only shows the thread title in Libraries Format$() - or "PRINT USING for variables"
That is very interesting, If I understand...
Italian uses a ","(comma) for a decimal notation and a "."(dot) for thousands separator?
If so we could change the function to ask for a delimiter.
thanks for that info.
I wrote one exactly like that description but it is currently being held hostage in the lost realm of our old forum. Bummer.unfortunately the wayback machine only shows the thread title in Libraries Format$() - or "PRINT USING for variables"
So, why not using _PRINTF(), _SPRINTF(), _FPRINTF() etc. with all their relevant parameters that also take care of the right or left aligment as well as leading spaces?
Just my two cents.
So, why not using _PRINTF(), _SPRINTF(), _FPRINTF() etc. with all their relevant parameters that also take care of the right or left aligment as well as leading spaces?
Just my two cents.
simple answer - just trying to stay "native" :-)
and IMHO, I only use QB64 for basic / fun programing, I have my heavy hitter languages for the Clydesdale work :-)