find ASCII value of, 7 digit 1’s complement of a string(char) in java - char

I have to find ASCII value of 7 digit 1’s complement of a string(char) in java.
Thanks in advance.

OK, so let's start with the basics.
You need the one's complement on 7 bits only of the byte. Therefore it is true that, given 7 bytes only:
0x3E = 0 011 1110
0x41 = 0 100 0001
0x41 is indeed the one's complement of 0x3E.
Now, you have a problem to begin with, and that problem is that in Java, a char is not interchangeable with a byte because of character codings.
However, since your range of characters is limited to ASCII, you can use US-ASCII as an encoding. So, the first step is to:
final Charset ascii = StandardCharsets.US_ASCII;
final byte[] bytes = theInput.getBytes(ascii);
final byte[] transformedBytes = new byte[bytes.length];
byte original, transformed;
for (int index = 0; index < bytes.length; index++) {
original = bytes[index];
transformed = transformByte(original);
transformedBytes[index] = transformed;
}
return new String(transformedBytes, ascii);
And now, the transformedByte() method needs to be written.
One's complement simply consists of a bitwise not on all the bytes, but here you want to limit that to 7 bytes; the solution is therefore to first do the negation normally, and then mask with 0x7f, which is 0111 1111; this is made possible by the fact that none of your byte values have the highest bit set:
private static void transformByte(final byte original)
{
return ~original & 0x7f;
}
This can be substituted directly into the original method, it's not even worth a separate method ;)

Related

Encode/decoded a randomized, fixed-length string to and from a 64 bit integer

I want to convert a fixed-length, say 50 character long randomized string into a 64 bit integer and be able to convert it back to original text given the 64 bit integer.
Does an algorithm exist for this? I want to go with encoding/decoding rather than hashing/reverse lookup.
just sumarization of the comments...
1:1 mapping between string and number requires enough characters and bits to store your data. Assuming 26 char alphabet only:
64bit -> 2^64 // possible numbers in 64 bits
1char -> 26 // possible characters per 1 char
so in order to get the number of chars fitting into 64 bit integer
chars = floor( 64 / (log(26)/log(2)) )
= floor( 64 / 4.7004397181410921603968126542567)
= floor( 13.6 )
= 13
if you want to know how many bits you need for 50 chars:
bits = ceil( 50 / (log(2)/log(26)) )
= ceil( 50 / 0.21274605355336315360618778415321
= ceil( 235.02198590705460801984063271284 )
= 236
Now if you want to encode 13 char (a..z) from text into 64 bit unsigned integer x:
char text[13] = "bla bla bla b";
unsigned int x,m,i;
for (i=0,x=0,m=1;i<13;i++,m*=26)
x += ((unsigned int)(text[i]-'a'))*m;
And decoding back:
for (i=0;i<13;i++)
{
text[i] = (x%26)+'a';
x /= 26;
}
As you can see its the same as converting between numbers in different bases...
In case you want to have faster dec/enc at the cost of text size you can ceil the number of bits per single character to 5 meaning floor(64/5) = 12 chars and use bits operations instead (each character would be 5 bits in the number)...
char text[12] = "bla bla bla ";
unsigned int x,i;
for (i=0,x=0,i<12;i++)
{
x <<= 5;
x |= text[i]-'a';
}
for (i=0;i<12;i++)
{
text[11-i] = (x&31)+'a';
x >>= 5;
}
However if you have any additional knowledge about the characters its possible to implement compression but only in cases where entropy allows it... for more info google RLE,Huffman encoding...

How to test whether a binary string is valid UTF8?

https://github.com/google/codesearch/blob/master/index/write.go#L581
I see the above to test whether two bytes can appear in a valid UTF8 string. But I don't understand how it works. Could anybody help me understand why this function works? Thanks.
See wikipedia for a description of the encoding. The encoding is:
num
bytes 1st byte 2nd byte 3rd byte 4 byte
1 0xxxxxxx
2 110xxxxx 10xxxxxx
3 1110xxxx 10xxxxxx 10xxxxxx
4 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
To help make the code easier to compare the the wikipedia article, here's the code with < n rewritten to <= n-1 and integer literals rewritten to binary integer literals.
func validUTF8(c1, c2 uint32) bool {
switch {
case c1 <= 0b01111111:
// 1-byte, must be followed by 1-byte or first of multi-byte
return c2 <= 0b01111111 || 0b11000000 <= c2 && c2 <= 0b11110111
case c1 <= 0b10111111:
// continuation byte, can be followed by nearly anything
return c2 <= 0b11110111
case c1 <= 0b11110111:
// first of multi-byte, must be followed by continuation byte
return 0b10000000 <= c2 && c2 <= 0b10111111
}
return false
}
The first case checks the byte following a 1-byte encoding (0xxxxxxx).
The second case checks the byte following a continuation byte (10xxxxxx).
The third case checks the byte following the start of a multi-byte encoding (110xxxxx, 1110xxxx, 11110xxx).
The function reports whether two bytes can be in a valid UTF-8 encoding. A sequence of valid byte pairs is not necessarily a valid UTF-8 encoding.
Using the standard library's unicode/utf8 module is probably better suited for your task than using that function. Check out utf8.Valid documentation.

How to calculate g values from LIS3DH sensor?

I am using LIS3DH sensor with ATmega128 to get the acceleration values to get motion. I went through the datasheet but it seemed inadequate so I decided to post it here. From other posts I am convinced that the sensor resolution is 12 bit instead of 16 bit. I need to know that when finding g value from the x-axis output register, do we calculate the two'2 complement of the register values only when the sign bit MSB of OUT_X_H (High bit register) is 1 or every time even when this bit is 0.
From my calculations I think that we calculate two's complement only when MSB of OUT_X_H register is 1.
But the datasheet says that we need to calculate two's complement of both OUT_X_L and OUT_X_H every time.
Could anyone enlighten me on this ?
Sample code
int main(void)
{
stdout = &uart_str;
UCSRB=0x18; // RXEN=1, TXEN=1
UCSRC=0x06; // no parit, 1-bit stop, 8-bit data
UBRRH=0;
UBRRL=71; // baud 9600
timer_init();
TWBR=216; // 400HZ
TWSR=0x03;
TWCR |= (1<<TWINT)|(1<<TWSTA)|(0<<TWSTO)|(1<<TWEN);//TWCR=0x04;
printf("\r\nLIS3D address: %x\r\n",twi_master_getchar(0x0F));
twi_master_putchar(0x23, 0b000100000);
printf("\r\nControl 4 register 0x23: %x", twi_master_getchar(0x23));
printf("\r\nStatus register %x", twi_master_getchar(0x27));
twi_master_putchar(0x20, 0x77);
DDRB=0xFF;
PORTB=0xFD;
SREG=0x80; //sei();
while(1)
{
process();
}
}
void process(void){
x_l = twi_master_getchar(0x28);
x_h = twi_master_getchar(0x29);
y_l = twi_master_getchar(0x2a);
y_h = twi_master_getchar(0x2b);
z_l = twi_master_getchar(0x2c);
z_h = twi_master_getchar(0x2d);
xvalue = (short int)(x_l+(x_h<<8));
yvalue = (short int)(y_l+(y_h<<8));
zvalue = (short int)(z_l+(z_h<<8));
printf("\r\nx_val: %ldg", x_val);
printf("\r\ny_val: %ldg", y_val);
printf("\r\nz_val: %ldg", z_val);
}
I wrote the CTRL_REG4 as 0x10(4g) but when I read them I got 0x20(8g). This seems bit bizarre.
Do not compute the 2s complement. That has the effect of making the result the negative of what it was.
Instead, the datasheet tells us the result is already a signed value. That is, 0 is not the lowest value; it is in the middle of the scale. (0xffff is just a little less than zero, not the highest value.)
Also, the result is always 16-bit, but the result is not meant to be taken to be that accurate. You can set a control register value to to generate more accurate values at the expense of current consumption, but it is still not guaranteed to be accurate to the last bit.
the datasheet does not say (at least the register description in chapter 8.2) you have to calculate the 2' complement but stated that the contents of the 2 registers is in 2's complement.
so all you have to do is receive the two bytes and cast it to an int16_t to get the signed raw value.
uint8_t xl = 0x00;
uint8_t xh = 0xFC;
int16_t x = (int16_t)((((uint16)xh) << 8) | xl);
or
uint8_t xa[2] {0x00, 0xFC}; // little endian: lower byte to lower address
int16_t x = *((int16*)xa);
(hope i did not mixed something up with this)
I have another approach, which may be easier to implement as the compiler will do all of the work for you. The compiler will probably do it most efficiently and with no bugs too.
Read the raw data into the raw field in:
typedef union
{
struct
{
// in low power - 8 significant bits, left justified
int16 reserved : 8;
int16 value : 8;
} lowPower;
struct
{
// in normal power - 10 significant bits, left justified
int16 reserved : 6;
int16 value : 10;
} normalPower;
struct
{
// in high resolution - 12 significant bits, left justified
int16 reserved : 4;
int16 value : 12;
} highPower;
// the raw data as read from registers H and L
uint16 raw;
} LIS3DH_RAW_CONVERTER_T;
than use the value needed according to the power mode you are using.
Note: In this example, bit fields structs are BIG ENDIANS.
Check if you need to reverse the order of 'value' and 'reserved'.
The LISxDH sensors are 2's complement, left-justified. They can be set to 12-bit, 10-bit, or 8-bit resolution. This is read from the sensor as two 8-bit values (LSB, MSB) that need to be assembled together.
If you set the resolution to 8-bit, just can just cast LSB to int8, which is the likely your processor's representation of 2's complement (8bit). Likewise, if it were possible to set the sensor to 16-bit resolution, you could just cast that to an int16.
However, if the value is 10-bit left justified, the sign bit is in the wrong place for an int16. Here is how you convert it to int16 (16-bit 2's complement).
1.Read LSB, MSB from the sensor:
[MMMM MMMM] [LL00 0000]
[1001 0101] [1100 0000] //example = [0x95] [0xC0] (note that the LSB comes before MSB on the sensor)
2.Assemble the bytes, keeping in mind the LSB is left-justified.
//---As an example....
uint8_t byteMSB = 0x95; //[1001 0101]
uint8_t byteLSB = 0xC0; //[1100 0000]
//---Cast to U16 to make room, then combine the bytes---
assembledValue = ( (uint16_t)(byteMSB) << UINT8_LEN ) | (uint16_t)byteLSB;
/*[MMMM MMMM LL00 0000]
[1001 0101 1100 0000] = 0x95C0 */
//---Shift to right justify---
assembledValue >>= (INT16_LEN-numBits);
/*[0000 00MM MMMM MMLL]
[0000 0010 0101 0111] = 0x0257 */
3.Convert from 10-bit 2's complement (now right-justified) to an int16 (which is just 16-bit 2's complement on most platforms).
Approach #1: If the sign bit (in our example, the tenth bit) = 0, then just cast it to int16 (since positive numbers are represented the same in 10-bit 2's complement and 16-bit 2's complement).
If the sign bit = 1, then invert the bits (keeping just the 10bits), add 1 to the result, then multiply by -1 (as per the definition of 2's complement).
convertedValueI16 = ~assembledValue; //invert bits
convertedValueI16 &= ( 0xFFFF>>(16-numBits) ); //but keep just the 10-bits
convertedValueI16 += 1; //add 1
convertedValueI16 *=-1; //multiply by -1
/*Note that the last two lines could be replaced by convertedValueI16 = ~convertedValueI16;*/
//result = -425 = 0xFE57 = [1111 1110 0101 0111]
Approach#2: Zero the sign bit (10th bit) and subtract out half the range 1<<9
//----Zero the sign bit (tenth bit)----
convertedValueI16 = (int16_t)( assembledValue^( 0x0001<<(numBits-1) ) );
/*Result = 87 = 0x57 [0000 0000 0101 0111]*/
//----Subtract out half the range----
convertedValueI16 -= ( (int16_t)(1)<<(numBits-1) );
[0000 0000 0101 0111]
-[0000 0010 0000 0000]
= [1111 1110 0101 0111];
/*Result = 87 - 512 = -425 = 0xFE57
Link to script to try out (not optimized): http://tpcg.io/NHmBRR

SIMPLE-TLV vs BER-TLV

I have found in docs they are referring to SIMPLE-TLV and BER-TLV . I was look into most of the EMV and GP docs but they have not mentioned the different.
Could anyone help me to understand the difference of two ?
Data fields in ISO/IEC 7816-4 for smart cards
BER encoding
This is the specification of the more common BER encoding used by ISO/IEC 7816-4:
Each BER-TLV data object shall consists of 2 or 3 consecutive fields
(see ISO/IEC 8825 and annex D).
The tag field T consists of one or more consecutive bytes. It encodes
a class, a type and a number. The length field consists of one or more
consecutive bytes. It encodes an integer L. If L is not null, then the
value field V consists of L consecutive bytes. If L is null, then the
data object is empty: there is no value field.
Note that ISO/IEC 7816 only allows the use of up to 5 length bytes (specifying a size up to 2^32 - 1 bytes) in the current standard. Indefinite length encoding is not supported either. These limitations are specific to smart cards. Note that 4 and 5 byte length encodings were introduced in a later version of ISO/IEC 7816-4; earlier cards / card reading applications may only support 3 length bytes (i.e. a value size up to 64KiB bytes, instead of 4GiB).
The BER TLV specification is much more expansive (which is why SIMPLE-TLV is called "simple"). I won't go into the details too much as there is plenty of information available on the internet. To name just a few differences, the tags have syntactical meaning and may consist of multiple bytes and the length encoding is rather complex.
Normally BER should only be used as an encoding of ASN.1 structures, with the ASN.1 syntax defining the structure. ISO 7816-4 however messes this up and only specifies the BER tag bytes directly.
Note that sometimes DER is specified instead of BER. In that case you should only use the minimum number of bytes for the size of the length field - e.g. a single length byte with value 05 in the samples below. The ISO/IEC specification of BER encoding is basically a copy of the US specific X.690 standard, also reflected in the international standard ISO/IEC 8825-1 (both payware).
SIMPLE-TLV encoding
The BER specification in ISO/IEC 7816-4 is followed by the SIMPLE-TLV specification. SIMPLE-TLV is specific to ISO 7816-4.
Each SIMPLE-TLV data object shall consist of 2 or 3 consecutive
fields.
The tag field T consists of a single byte encoding only a number from
1 to 254 (e.g. a record identifier). It codes no class and no
construction-type. The length field consists of 1 or 3 consecutive
bytes. If the leading byte of the length field is in the range from
'00' to 'FE', then the length field consists of a single byte encoding
an integer L valued from 0 to 254. If the leading byte is equal to
'FF', then the length field continues on the two subsequent bytes
which encode an integer L with a value from 0 to 65535. If L in not
null, then the value field V consists of consecutive bytes. If L is
null, then the data object is empty: there is no value field.
Note that the standard forgets to specify the endianness directly. You can however assume big endian encoding within ISO/IEC 7816-4.
Samples
The following samples are all used to convey the same tag number (which defines the field) and value, except one that defines tag number 31 for BER.
Sample SIMPLE-TLV
0F 05 48656C6C6F // tag number 15, length 5 then the value
0F FF0005 48656C6C6F // tag number 15, length 5 (two bytes), then the value
Sample BER-TLV:
4F 05 48656C6C6F // *application specific*, primitive encoding of tag number 15, length 5 then the value
4F 8105 48656C6C6F // the same, using two bytes to encode the length
4F 820005 48656C6C6F // the same, using three bytes to encode the length
4F 83000005 48656C6C6F // the same, using four bytes to encode the length
4F 8400000005 48656C6C6F // the same , using five bytes to encode the length
5F0F 05 48656C6C6F // **invalid** encoding of the same, with two bytes for the tag, specifiying a tag number 15 which is smaller than 31
5F1F 05 48656C6C6F // application specific, primitive encoding of **tag number 31**
In the last example with the two byte tag encoding, the first byte is 40 hex, where the first 3 leftmost bits 010 specify application specific encoding, adding the magic value 1F (31) to it to indicate that another byte will follow with the actual tag number, again 1F, so value 31.
Differences
The following differences should be noted:
SIMPLE-TLV is a different method of encoding for tag and length (although the encoding may look similar, e.g. when using a single byte to indicate the length part)
SIMPLE-TLV does not contain information about the class of the field, e.g. if it is defined for ASN.1 (because it is not linked to ASN.1)
SIMPLE-TLV does not contain information if it is primitive or constructed (primitive directly specifies a value, constructed means nested TLV structures)
SIMPLE-TLV has restrictions regarding the tag number (between 1 and 254, inclusive) and length (up to 65535)
Simple TLV simply consists of Tag (or Type), Length, and Value.
The BER-TLV is a special TLV which has one or more TLV inside its Value. So it has composite structure.
Tag1 Len1 Tag2-Len2-Value2 Tag3-Len3-Value3 ... TagN-LenN-ValueN
------------------------Value1------------------------
[Example C# code for Bert-Tlv Parser][1]:
[1]https://github.com/umitkoc/BertTlv
public class Tlv : ITlv, IFile
{
List<TlvModel> modelList=new();
string parser = "";
string length = "";
String empty = "";
string ascii = "";
int decValue = 0;
int step = 0;
public Tlv(String data)
{
TlvParser(data.Replace(" ",""));
}
public void readTag()
{
String line = "";
StreamReader sr = new StreamReader("taglist.txt");
while ((line = sr.ReadLine()) != null)
{
modelList.Add(new()
{
tag = line.Split(",")[0].Trim(),
description = line.Split(",")[1].Trim()
});
}
sr.Close();
}
public void insertTag()
{
try
{
StreamWriter sw = new StreamWriter("test.txt");
foreach (var item in modelList)
{
sw.WriteLine($"{item.tag},{item.description}");
}
sw.Close();
}
catch (Exception e)
{
Console.WriteLine("Exception: " + e.Message);
}
}
public int writeFile(String parser)
{
StreamWriter sw = new StreamWriter("output.txt");
sw.WriteLine(parser);
sw.Close();
return 0;
}
private int TlvParser(String data, int i = 0, string tag = "")
{
if (i == 0)
{
readTag();
}
if (i < data.Length)
{
tag += data[i];
TlvModel model = getTag(tag);
if (model != null)
{
decValue = int.Parse(data.Substring(i + 1, 2), System.Globalization.NumberStyles.HexNumber);
// lengthControl(data,i+3,decValue);
if (model.description.Contains("Template"))
{
parser += $"{empty}|------ tag: {model.tag}({model.description})\n";
step += 1;
empty = Empty();
return TlvParser(data, i + 3, "");
}
else
{
parser += $"{empty}|------ tag: {model.tag}({model.description}){empty}|------ value --> {ConvertHex(data.Substring(i + 3, decValue * 2))} \n";
}
i += 3 + decValue * 2;
return TlvParser(data, i, "");
}
else
{
return TlvParser(data, i + 1, tag);
}
}
return writeFile(parser);
}
public TlvModel getTag(string tag)
{
return modelList.Find(i => i.tag == tag);
}
public string ConvertHex(string hex)
{
ascii = "";
for (int i = 0; i < hex.Length; i += 2)
{
ascii += System.Convert.ToChar(System.Convert.ToUInt32(hex.Substring(i, 2), 16));
}
return ascii;
}
private string Empty()
{
for (int s = 0; s < step; s++)
{
empty += "\t";
}
return empty;
}
public void setTag(TlvModel model)
{
modelList.Add(model);
insertTag();
}
}

Is it possible to convert any base to any base (range 2 to 46)

I know it is simple and possible to convert any base to any base. First, convert any base to decimal and then decimal to any other base. However, I had done this before for range 2 to 36 but never done for 2 to 46.
I don't understand what I will put after 36, because 36 means 'z' (1-10 are decimal numbers then the 26 characters of the alphabet).
Please explains what happens after 36.
Every base has a purpose. Usually we do base conversion to make complex computations simpler.
Here are some most popular bases used and their representation.
2-binary numeral system
used internally by nearly all computers, is base two. The two digits are 0 and 1, expressed from switches displaying OFF and ON respectively.
8-octal system
is occasionally used in computing. The eight digits are 0–7.
10-decimal system
the most used system of numbers in the world, is used in arithmetic. Its ten digits are 0–9.
12-duodecimal (dozenal) system
is often used due to divisibility by 2, 3, 4 and 6. It was traditionally used as part of quantities expressed in dozens and grosses.
16-hexadecimal system
is often used in computing. The sixteen digits are 0–9 followed by A–F.
60-sexagesimal system
originated in ancient Sumeria and passed to the Babylonians. It is still used as the basis of our modern circular coordinate system (degrees, minutes, and seconds) and time measuring (minutes and hours).
64-Base 64
is also occasionally used in computing, using as digits A–Z, a–z, 0–9, plus two more characters, often + and /.
256-bytes
is used internally by computers, actually grouping eight binary digits together. For reading by humans, bytes are usually shown in hexadecimal.
The octal, hexadecimal and base-64 systems are often used in computing because of their ease as shorthand for binary. For example, every hexadecimal digit has an equivalent 4 digit binary number.
Radices are usually natural numbers. However, other positional systems are possible, e.g. golden ratio base (whose radix is a non-integer algebraic number), and negative base (whose radix is negative).
Your doubt is whether we can convert any base to any other base after base exceeds 36
( # of Alphabets + # of digits = 26+ 10= 36)
Taking example of 64-Base
It uses A–Z(Upper case)(26), a–z(lower case)(26), 0–9(10), plus 2 more characters. This way the constraint of 36 is resolved.
As we have (26+26+10+2)64 symbols in 64-base for representation, we can represent any number in 64 base. Similarly for more base they use different symbols for representation.
Source: http://en.wikipedia.org/wiki/Radix
The symbols you use for digits are arbitrary. For example base64 encoding uses 'A' to represent the zero valued digit and '0' represents the digit with the value 52. In base64 the digits go through the alphabet A-Z, then the lower case alphabet a-z, then the traditional digits 0-9, and then usually '+' and '/'.
One base 60 system used these symbols:
So the symbols used are arbitrary. There's nothing that 'happens' after 36 except what you say happens for your system.
With number systems, you are allowed to play god.
Playing god
What you need to understand is, that symbols are completely arbitrary. There is no god-given rule for "what comes after 36". You are free to define whatever you like.
To encode numbers with a certain base, all you need is the following:
base-many distinct symbols
a total order on the symbols
An arbitrary example
Naturally, there's an infinite amount of possibilities to create such a symbol table for a certain base:
Θ
ェ
す
)
0
・
_
o
や
ι
You could use this, to encode numbers with base 10. Θ being the zero-element, ェ being the one, etc.
Conventions
Of course, your peers would not be too happy if you started using the above symbol table. Because the symbols are arbitrary, we need conventions. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 is a convention, as are the symbols we use for hexadecimal, binary, etc. It is generally agreed upon what symbol table we use for what basis, that is why we can read the numbers someone else writes down.
The important thing to remember is that all numbers are symbolic of a value. Thus if you wanted to do that, you could just make a list containing the values at each position. After base 36, you simply run out of characters you can make a logical sequence out of. For example, if you used the Cambodian Alphabet with 70 odd characters, you could do base 80.
Here is the complete code I have written, hope this will help.
import java.util.Scanner;
/*
* author : roottraveller, nov 4th 2017
*/
public class BaseXtoBaseYConversion {
BaseXtoBaseYConversion() {
}
public static String convertBaseXtoBaseY(String inputNumber, final int inputBase, final int outputBase) {
int decimal = baseXToDecimal(inputNumber, inputBase);
return decimalToBaseY(decimal, outputBase);
}
private static int baseXNumeric(char input) {
if (input >= '0' && input <= '9') {
return Integer.parseInt(input + "");
} else if (input >= 'a' && input <= 'z') {
return (input - 'a') + 10;
} else if (input >= 'A' && input <= 'Z') {
return (input - 'A') + 10;
} else {
return Integer.MIN_VALUE;
}
}
public static int baseXToDecimal(String input, final int base) {
if(input.length() <= 0) {
return Integer.MIN_VALUE;
}
int decimalValue = 0;
int placeValue = 0;
for (int index = input.length() - 1; index >= 0; index--) {
decimalValue += baseXNumeric(input.charAt(index)) * (Math.pow(base, placeValue));
placeValue++;
}
return decimalValue;
}
private static char baseYCharacter(int input) {
if (input >= 0 && input <= 9) {
String str = String.valueOf(input);
return str.charAt(0);
} else {
return (char) ('a' + (input - 10));
//return ('A' + (input - 10));
}
}
public static String decimalToBaseY(int input, int base) {
String result = "";
while (input > 0) {
int remainder = input % base;
input = input / base;
result = baseYCharacter(remainder) + result; // Important, Notice the reverse order here
}
return result;
}
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
System.out.println("Enter : number baseX baseY");
while(true) {
String inputNumber = scanner.next();
int inputBase = scanner.nextInt();
int outputBase = scanner.nextInt();
String outputNumber = convertBaseXtoBaseY(inputNumber, inputBase, outputBase);
System.out.println("Result = " + outputNumber);
}
}
}

Resources