How to add zeros before number in Lua? - lua

I need to add zeros before, so the number always stays in the 3 digits range. If the number is 9 then I would need 009, same goes with with 2 digit if the number is 99 then I would need 099. I have no idea how to do it in Lua, if someone knows the answer I would be very grateful for it. Thanks.
EDIT
string.format("%03d", 99)
and it worked

Related

How to add leading zeroes to format?

I need a print function that writes Loop i / round, where both values i and round have to have at least four digits (12 -> 0012). It must have the format-method too.
I found the paste formatC and other ways to add leading zeroes but I can't make them work for this case..
It needs to be like this:
print('Loop {} / {}'.format('i', 'round'))
But with four digit numbers as I said.
number_str = str(a_number)
zero_filled_number = number_str.zfill(4)
a_number is 12.
zero_filled_number will give you 0012
Use print("{:02d}".format(1)) as found in this answer.

Converting a string to int is dropping the leading 0 and makes it think it is an octal number (xcode iOS)

I'm a little stumped on this one so appreciate the assistance of the experts on this forum, please.
My app has a text field where the user enters a 10 digit number, that number can start with a 0, e.g. 0727158880
I need to convert that number to an int so I can increment it by 1 each time my app goes through a loop of doing some stuff. But when I convert the string to an int it drops the leading 0 and returns just: 727158880
I "think" this is because it sees the leading 0 and thinks it is an octal number, but I don't want it to do that. Any ideas how I can keep the number as entered by the user and then incremement it?
Thanks!
This has nothing to do with octal numbers at all. You are converting a string to an integer. Integers are just numbers, they have no digits, they have no leading zero digits.
If you enter "man printf" into terminal it will tell you all the formats for printing numbers, and you can tell it to print an integer in 10 digits with leading zeroes.
A number cannot have leading 0. Hence you know there is 10 digits number. A solution is
NSInteger number = [str integerValue];
number++;
NSString *newStr = [NSString stringWithFormat:#"%010d", number];

Converting six-bit binary number to it's corresponding two digit BCD number?

Here is the question that I tried so hard but I couldn't solve it.
I captured the question as it was from the question-paper, I couldn't solve it in the exam, and non of student's could.
You probably ask, why don't you ask your lecturer ( it's fair question because you are not here to solve the exam-question or a homework), we did but she didn't solve it she just told us the BCD is like this :
10^0 10^1 10^2 ....
Any Help appreciated, Thanks.
It seems like what she wants is for you to specify the binary BCD output for these inputs. So, for example, 53 would output as 101 0011 (starting from D6). (101 = 5, 0011 = 3)
7.17,The 32 * 6 ROM, together with the 20 line, as shown in Fig. P7.17, converts a six‐bit binary
number to its corresponding two‐digit BCD number. For example, binary 100001 converts
to BCD 011 0011 (decimal 33). Specify the truth table for the ROM.see the answer

Finding the correct formula for encoded hex value in decimal

I have a case here where I am trying to figure out how a hex number is converted into a decimal number.
I had a similar case before, but found out that if I reversed the hex string, and swapped each second value (little-endian), then converting it back to a decimal value I got what I wanted, but this one is different.
here is the values we received
Value nr. 1 is
Dec: 1348916578
Hex: 0a66ab46
I just have this one decimal/hex for now but I am trying to get more values to compare results.
I hope any math genius out there will be able to see what formula might been used here :)
thanks
1348916578
= 5 0 6 6 D 5 6 2 hex
= 0101 0000 0110 0110 1101 0101 0110 0010
0a66ab46
= 0 A 6 6 A B 4 6 hex
= 0000 1010 0110 0110 1010 1011 0100 0110
So, if a number is like this, in hex digits:
AB CD EF GH
Then a possible conversion is:
rev(B) rev(A) rev(D) rev(C) rev(F) rev(E) rev(H) rev(G)
where rev reverses the order of bits in the nibble; though I can see that the reversal could be done on a byte-wise basis also.
Interesting.... I expanded the decimal and hex into binary, and this is what you get, respectively:
1010000011001101101010101100010
1010011001101010101101000110
Slide the bottom one over by padding with some 0s, then split into 8-byte blocks.
10100000 1100110 11010101 01100010
10100 1100110 10101011 01000110
It seems to start to line up. Let's make the bottom look like the top.
Pad the first block with 0s and it's equal.
The second block is ok.
Switch the 3rd block around (reverse it) and 10101011 becomes 11010101.
10100000 1100110 11010101 01000110
Likewise with the 4th.
10100000 1100110 11010101 01100010
Now they're the same.
10100000 1100110 11010101 01100010
10100000 1100110 11010101 01100010
Will this work for all cases? Impossible to know.
The decimal value of x0a66ab46 is 174500678 or 1185637898 (depending which endian you use, with any 8, 16 or 32bit access). There seems to be no direct connection between these values. Maybe you just have the pair wrong? It could help if you posted some code about how you generate these value pairs.
BTW, Delphi has a fine little method for this: SysUtils.IntToHex
What we found was that our min USB reader that gave 10 bit decimal format is actually not showing the whole binary code. The hexadecimal reader finds the full binary code. so essentially it is possible to convert from hexadecimal value to 10 bit decimal by taking off 9 characters after binary conversion.
But this does not work the other way around (unless we strip away 2 characters from the hexadecimal value the 10 bit decimal code will only show part of the full binary code).
So case closed.

Data Validation

So I have entered my second semester of College and they have me doing a course called Advanced COBOL. As one of my assignments I have to my make a program that tests certain things in a file to make sure the input has no errors. I get the general idea but there are just a few things I don't understand and my teacher is one of those people who will give you an assignment and make you figure it out yourself with little or no help. So here is what I need help with.
I have a field that the first 5 columns have to be numbers, the 6th column a capital letter and the last 2 numbers in a range of 01-68 or 78-99.
one of my fields has to be a string of numbers with a dash in it like 00000-000, but some have more than one dash. How can I count the dashes to identify that there is a problem.
Here are a few hints...
Use a hieratical record structure to view the data in different ways. For example:
01 ITEM-REC.
05 ITEM-CODE.
10 ITEM-NUM-CODE PIC 9(3).
10 ITEM-CHAR-CODE PIC A(3).
88 ITEM-TYPE-A VALUE 'AAA' THRU 'AZZ'.
88 ITEM-TYPE-B VALUE 'BAA' THRU 'BZZ'.
05 QUANTITY PIC 9(4).
ITEM-CODE is a 6 character group field, the first part of which is numeric (ITEM-NUM-CODE) and the last part
is alphabetic (ITEM-CHAR-CODE). You can refer to any one of these three variables in your program. When you
refer to ITEM-CODE, or any other group item, COBOL
treats the variable as if it were declared as PIC X. This means you can
MOVE just about anything into it without raising an error. For example:
MOVE 'ABCdef' TO ITEM-CODE
or
MOVE 'ABCdef0005' TO ITEM-REC
Neither one would cause an error even though the elementary data item ITEM-NUM-CODE is definitely not a number.
To verify the validity
of your data after a group move you should validate each elementary data item separately (unless
you know for certain no data type errors could have occurred). There are a variety of ways to do this. For
example if the data item has to be numeric the following would work:
IF ITEM-NUM-CODE IS NUMERIC
CONTINUE
ELSE
DISPLAY 'ITEM-NUM-CODE IS NOT NUMERIC'
PERFORM BIG-BAD-ERROR
END-IF
COBOL provides various class tests which can be applied against a data item. For
example: NUMERIC, ALPHABETIC and ALPHANUMERIC are commonly used.
Another common way to test for ranges of values is by defining various 88 levels - but exercise
caution. In the above
example ITEM-TYPE-A is an 88 level that defines a data range from 'AAA' through 'AZZ' based on
the collating sequence currently in effect. To verify that ITEM-CHAR-CODE contains only alphabetic
characters and the first letter is an 'A' or a 'B', you could do something like:
IF ITEM-CHAR-CODE ALPHABETIC
DISPLAY 'ITEM-CHAR-CODE is alphabetic.'
EVALUATE TRUE
WHEN ITEM-TYPE-A
DISPLAY 'ITEM-CHAR-CODE is in range AAA through AZZ'
WHEN ITEM-TYPE-B
DISPLAY 'ITEM-CHAR-CODE is in range BAA through BZZ'
WHEN OTHER
DISPLAY 'ITEM-CHAR-CODE is in some other range'
END-EVALUATE
ELSE
DISPLAY 'ITEM-CHAR-CODE is not alphabetic'
END-IF
Note the separate test for ALPHABETIC above. Why do that when the 88 level tests
could have done the job? Actually the 88's are not sufficient because they
cover the entire range from AAA through AZZ based on the collating sequence currently
in effect. In
an EBCDIC based environment (a very large number of COBOL shops use EBCDIC) this captures
values such as A}\. the close-brace and backslash characters are non-alpha but
fall into the middle of
the range 'A' through 'Z' (what the #*#! is that all about?). Also note that a value such
as 'aaa' would not satisfy the ITEM-TYPE-A condition because lower case letters fall outside
the defined range. Maybe time to check out an EBCDIC character table.
Finally, you can count the number of occurrences of a character, or string of characters, in
a variable with the INSPECT verb as follows:
INSPECT ITEM-CODE TALLING DASH-COUNT FOR ALL '-'
DASH-COUNT needs to be a numeric item and will contain the number of dash characters in ITEM-CODE. The INSPECT
verb is not so useful if you want to count the number of digits. For this you would need one statement for each digit.
It might be easier to just code a loop something like:
PERFORM VARYING I FROM 1 BY 1
UNTIL I > LENGTH OF ITEM-CODE
EVALUATE ITEM-CODE(I:1)
WHEN '-'
COMPUTE DASH-COUNT = DASH-COUNT + 1
WHEN '0' THRU '9'
COMPUTE DIGIT-COUNT = DIGIT-COUNT + 1
WHEN OTHER
COMPUTE OTHER-COUNT = OTHER-COUNT + 1
END-EVALUATE
END-PERFORM
Now ask yourself why I was comfortable using a zero through 9 range check? Hint: look at the collating sequence.
Hope this helps.

Resources