i have a string "2.45", i need to convert this string into hexa form, the i need to convert that data into two bytes of data 0x32 0x45 (in integer 50, 69)
I did script upto converting to hexa
@Nish , Welcome, you assertion - 'I did script upto converting to hexa' ... can you share that please, the site is a COLLABORATION, you show your attempts (no screenshots please, copy/paste is the most flexible), the team can review and come back with suggestions (which may include complete solutions).
You may need to elaborate what you mean by 'hexa'
Thks
#!/bin/bash
A=2.45
B=$(echo -n "$A" | xxd -p)
byte1="${B:0:2}"
byte2="${B:2:2}"
byte3="${B:4:2}"
byte4="${B:6:2}"
dec1=$((16#${byte1}))
dec2=$((16#${byte2}))
dec3=$((16#${byte3}))
dec4=$((16#${byte4}))
sum1=$((dec1*10 + dec2))
sum2=$((dec3 + dec4))
dechex1=$(printf "%02X" "$sum1")
dechex2=$(printf "%02X" "$sum2")
echo "sum1 and sum2: $dechex1 $dechex2"
The result I get from that is sum1 and sum2: 222 69
One problem is that the . is Hex 2e, and you are later treating that as part of a 2-digit decimal number. It is not clear how you want to encode variants like 13.7 or 1.9. If the format is always like 9.99 then the . is completely redundant in the encoded form.
I'm not clear why the 4 and 5 are each encoded in 4 bits, but the 2 is expected to be encoded as 8 bits which in Hex represent the Decimal of the ASCII value. This is very muddled. I would require the output to be 0x0245 (a well-defined format called Binary Coded Decimal, aka COMP-3 in COBOL).
You can debug all the values like declare -p byte{1..4} to see where you first get unexpected results.
Also note that the %02X format outputs a minimum of two zero-padded digits. It does not slice larger values, it outputs all the digits.
#!/bin/bash
A=2.45
B=$(echo -n "$A" | xxd -p )
byte1="${B:0:2}"
byte2="${B:2:2}"
byte3="${B:4:2}"
byte4="${B:6:2}"
dec1=$(printf "%d" "0x$byte1")
dec2=$(printf "%d" "0x$byte2")
dec3=$(printf "%d" "0x$byte3")
dec4=$(printf "%d" "0x$byte4")
sum1=$((dec1 + dec2))
sum2=$((dec3 + dec4))
dechex1=$(echo "obase=16; $sum1" | bc)
dechex2=$(echo "obase=16; $sum2" | bc)
echo "sum1 and sum2: $dechex1 $dechex2"
here i converted . to integer value
And yet you don't post the output you got, or any debug.
$ declare -p byte{1..4} dec{1..4} sum{1..2} dechex{1..2}
declare -- byte1="32"
declare -- byte2="2e"
declare -- byte3="34"
declare -- byte4="35"
declare -- dec1="50"
declare -- dec2="46"
declare -- dec3="52"
declare -- dec4="53"
declare -- sum1="96"
declare -- sum2="105"
declare -- dechex1="60"
declare -- dechex2="69"
$ echo "sum1 and sum2: $dechex1 $dechex2"
sum1 and sum2: 60 69
i too got 60 69
i am not sure this is the right answer
There is no "right answer", because you have not completely specified what you want the outcome to be.
The primary question would be: "Is this procedure reversible, so that I have an operation that can retrieve the original data in all cases".
Usually, the target format is specified by the requirements of the next process that requires to use this data item. Often, those requirements are badly specified, incomplete, ambiguous, or just plain wrong.
This version logically has to be wrong. You just add the decimal values of the last two digits together. Therefore, sum2 will be decimal 105 whether the input digits are "45" or "54". So the encoding is not unique -- 2.45 and 2.54 give the same value, as would 2.19 and 2.91.
I don't even need to think about the encoding of "2." when you add those decimal values. The . does not even represent a number at all, so adding it to something else has no meaning.
An explanation of how this data will be used by the next action would be helpful. Basically, if you run the encoding from 0.00 to 9.99, you have to get 1000 different results. If you don't, then encoding is ambiguous.
whilst Half-precision floating-point format - Wikipedia would probably do the needful, not sure its what @Nish is after - as they've failed to clarify
import ieee754
ieee754.half('2.45').hex()
('40E7', ['0100', '0000', '1110', '0111'])
ieee754.half('2.45').hex()[0]
'40E7'