Qbasicnews.com
February 26, 2020, 02:14:43 AM
 Pages: 1 2 [3]
 Author Topic: Batter up!  (Read 9289 times)
Moneo
Na_th_an

Posts: 1971

 « Reply #30 on: September 16, 2003, 11:31:17 PM »

PVERA: I'm going to insert some notes into your code.
Code:

cls
dim amount\$(30)      ´WHY 30, WHEN BELOW YOU'RE READING 28?
dim digit(4)                ' THIS SHOULD BE DIM DIGIT(4) AS INTEGER

for count=1to28       ' THIS SHOULD BE 1 TO 28
data "one","two" and so forth  ´SINCE YOU'RE READING 28
'                                WORDS, WE SHOULD SEE THE OTHERS.

next count

value\$="9999.99"

dp=instr(1,value\$, ".")
dollars\$=mid\$(value\$, 1(dp-1))  'SHOULD BE ,1,DP-1)
cents\$="dollars\$ " +mid\$(value\$,(dp+1))+ " cents"
'ABOVE MAKES NO SENSE (NO PUN INTENDED).
'ON A CHECK, THE CENTS ARE SHOWN AS "AND CC/100", WHERE CC IS THE CENTS. YOU DON'T SPELL OUT THE WORD CENTS.
'PLUS YOU DONT WANT THE DOLLAR AMOUNT IN NUMBERS
' BEFORE THE CENTS. SO, THE REVISED CODE SHOULD BE:
CENTS\$="and"+MID\$(VALUE\$,DP+1)+"/100"

num.digits=len(dollars\$)

for count=1tonum.digits  'SHOLUD BE 1 TO NUM.DIGITS
digit(count)val(mid\$(dollars\$, count,1))  'MISSING EQUAL SIGN
'print digit(count)
next count

if num.digits=4then  'SHOULD BE 4 THEN
if digits(1) >0 then
print amount\$(digit(1))="thousand ";

and the above is repeated with the hundred only it digit 2

'THIS MAY WORK FOR THOUSANDS AND HUNDREDS, BUT WONT
'WORK FOR THE "TENS" POSITION HAVING 20,30,40 ETC., AND
' ALSO WON'T WORK FOR THE "TEENS".
'NEEDS MORE WORK.
*****
 Logged
heavenraiza
Member

Posts: 80

 « Reply #31 on: September 16, 2003, 11:50:04 PM »

question related to the same problem. im doing the similar problem for my class. we basically finished the coding & as i am overlooking the code there is a piece that is puzzling me, its part of the error checking subroutine. can someone tell me what this line of code is suppose to do:

PRINT "Enter Number: "
LINE INPUT value\$

dp=INSTR(1,value\$,".")

****************************HELP ON THIS PART
IF INSTR(dp, value\$, ".") <> 0 THEN
GOSUB Display.Error
RETURN Start
END IF
*******************************************

Display.Error:
PRINT "Entry Error -  Must Be In Format DDDD.CC - Limit \$9999.99"
SLEEP 5
RETURN

shouldnt the dp varible store the place where the decimal point is, now if in the if/then statement if its <> 0 why should an error be displayed?
 Logged

here are 10 types of people, those that understand binary & those that dont. . .
pvera11
New Member

Posts: 8

 « Reply #32 on: September 17, 2003, 12:08:16 PM »

sorry i jus got lazy in speling out everythin....i jus wanted to show the basic concept.....

but you get it right..?

 Logged
Agamemnus
x/ \z

Posts: 3491

 « Reply #33 on: September 17, 2003, 12:58:58 PM »

There are at least 3 things to check for:
1) double decimals.
2) no decimal.
3) Less than 2 values after the decimal.
4) More than 4 values before the decimal.

(2) and (3) can be easily fixed by just adding ".00" or extra decimal spaces if it's something like "565.5" (add "0")

The code that you show tries to make certain that there are no double decimals. However, it has a flaw. It should look like this (without the other 3 things..):

Code:

temp% = INSTR(value\$, ".")
temp% = INSTR(temp% + 1, value\$, ".")
IF temp% THEN GOSUB display.error: return start
 Logged

Peace cannot be obtained without war. Why? If there is already peace, it is unnecessary for war. If there is no peace, there is already war."

Visit www.neobasic.net to see rubbish in all its finest.
Moneo
Na_th_an

Posts: 1971

 « Reply #34 on: September 18, 2003, 01:04:40 AM »

AGA,
temp% = INSTR(".", value\$)
should be
temp% = INSTR(value\$,".")
*****
 Logged
Moneo
Na_th_an

Posts: 1971

 « Reply #35 on: September 18, 2003, 01:10:00 AM »

Quote from: "pvera11"
sorry i jus got lazy in speling out everythin....i jus wanted to show the basic concept.....

but you get it right..?

PVERA,
I get your basic intent, but your code needs work. You can't use the same logic for the tens and uints digit positions.
*****
 Logged
heavenraiza
Member

Posts: 80

 « Reply #36 on: September 18, 2003, 02:18:28 AM »

what do you mean by that? --- > (without the other 3 things..):

why is temp%? i know is a variable but why the %. our teacher didnt teach us this yet or if ever.
 Logged

here are 10 types of people, those that understand binary & those that dont. . .
Agamemnus
x/ \z

Posts: 3491

 « Reply #37 on: September 18, 2003, 08:55:32 AM »

Moneo: I fixed it. Whoops...

Teh other three things to check for. If you "can't" use "%", just put "defint a-z" at the start of your code and forget about the "%". defint a-z makes all your variables integers, 2 byte values with range -32768 to 32767.
 Logged

Peace cannot be obtained without war. Why? If there is already peace, it is unnecessary for war. If there is no peace, there is already war."

Visit www.neobasic.net to see rubbish in all its finest.
Moneo
Na_th_an

Posts: 1971

 « Reply #38 on: September 18, 2003, 02:14:27 PM »

Quote from: "Agamemnus"
There are at least 3 things to check for:
1) double decimals.
2) no decimal.
3) Less than 2 values after the decimal.
4) More than 4 values before the decimal.

PVERA,
The above 4 conditions that Agamemnus indicates should be checked for, are very important. This brings us to consider whether the input amount to your program should be thoroughly validated, or whether your program can assume that it was previously validated. In other words, what are the input specifications for your program? Make sure to get a decision from your teacher on this, because the validation logic is going to cost you a bit of extra code.
A) If the specs say that the input amount is previously validated, then the documentation of your program must specify that this program will then not need to perform validation, and that in the event that an invalid amount is received, the program will produce unknown results.
B) If the specs don't say that the input amount is previously validated, then I would add the following conditions to Agamemnus' list:
1) Regarding Aga's #1 about double decimals: I would rephrase this to say "no decimal or only 1 decimal point is allowed".
5) Decimal places: Input amount cannot have more than 2 decimal places; that is, amounts of 123.456 or 123.4567 are invalid.
6) Except for the allowed decimal point, every character or digit of the input amount must be strictly numeric. This automatically excludes the amount from having commas.
7) Input amount cannot be null. (Check this first).
*****
 Logged
Moneo
Na_th_an

Posts: 1971

 « Reply #39 on: September 18, 2003, 02:57:23 PM »

HEAVENRAIZA:

Let me expand on Aga's good explanation on the meaning and use of "%".

As you know there are 4 numeric data types: Integer, Long, Single, and Double.

In order to do anything with a numeric variable, QB must know the DATA TYPE of the variable.

There are 4 ways of defining a data type to a variable:

1) By using a DEFtype statement (DEFINT, DEFDBL, etc.) with a letter range. This is normally put at the beginning of the program. Example: DEFINT A-Z This sets the default data type to INTEGER for all variables beginning with A through Z.

2) Whether or not you used a DEFtype, you can explicitly define the data type of a variable with a DIM statement. Examples:
DIM TOTAL AS DOUBLE
DIM COUNTER AS LONG

3) Whether or not you used a DEFtype, you can explicitly append one of the following suffixes to a variable name to define the data type for the variable.
% Integer
& Long
! Single
# Double

4) The fourth case is the QB default. If you did not define the data type for a variable with any of the above methods, then QB will automatically assign the variable as being data type SINGLE.

Recommendations:
1) Put a DEFINT A-Z statement at the top of your program. This covers all the common uses of variables by defining them all as Integer.
2) For variables which you determine are not going to be Integer, use a DIM statement (as shown above) to define the required data types of these variables. This allows you not to have to append the explicit data type suffixes onto these variable names every time they're referenced in the code.
*****
 Logged
heavenraiza
Member

Posts: 80

 « Reply #40 on: September 18, 2003, 07:59:39 PM »

thanx Aga & Moneo i get the idea..but when will i use stuff like that? we havent done any programs that involves us to do that.
 Logged

here are 10 types of people, those that understand binary & those that dont. . .
Moneo
Na_th_an

Posts: 1971

 « Reply #41 on: September 18, 2003, 10:17:24 PM »

Quote from: "heavenraiza"
thanx Aga & Moneo i get the idea..but when will i use stuff like that? we havent done any programs that involves us to do that.

You will eventually use "stuff like that" in most of your programs. If your teacher hasn't explained anything about DATA TYPES yet, I'm sure he will soon. The programs that you're writing now are probably giving you some fundamentals on coding in QB, and these programs probaby work fine without any explicit DATA TYPES, that is, they work fine using the QB default of SINGLE precision variables. So, don't worry about it for now.
*****
 Logged
heavenraiza
Member

Posts: 80

 « Reply #42 on: September 18, 2003, 11:02:40 PM »

ok, thanx.
 Logged

here are 10 types of people, those that understand binary & those that dont. . .
Moneo
Na_th_an

Posts: 1971

 « Reply #43 on: September 21, 2003, 01:18:15 AM »

Quote from: "heavenraiza"
ok, thanx.

HEAVENRAIZA:
Just a personal note. It's a pleasure working with you, because you always respond to any help given you. You respond when you don't understand, and you acknowledge the help when you do. Thanks go to you!
*****
 Logged
heavenraiza
Member

Posts: 80

 « Reply #44 on: September 21, 2003, 01:24:44 AM »

thanx Moneo. . .i love the help that has been giving to me on this forum. i am definitely learning more & more thanx to you guys. i am even more happy that no one has made me feel stupid on this forum when i ask questions & when my questions are answered they are very detailed & informative.
 Logged

here are 10 types of people, those that understand binary & those that dont. . .
 Pages: 1 2 [3]