I'm writing a Wireshark dissector in lua and trying to decode a time-based protocol field.
I've two components 1)
local ref_time = os.time{year=2000, month=1, day=1, hour=0, sec=0}
and 2)
local offset_time = tvbuffer(0:5):bytes()
A 5-Byte (larger than uint32 range) ByteArray() containing the number of milliseconds (in network byte order) since ref_time. Now I'm looking for a human readable date. I didn't know this would be so hard, but 1st it seems I cannot simple add an offset to an os.time value and 2nd the offset exceeds Int32 range ...and most function I tested seem to truncate the exceeding input value.
Any ideas on how I get the date from ref_time and offset_time?
Thank you very much!
Since ref_time is in seconds and offset_time is in milliseconds, just try:
os.date("%c",ref_time+offset_time/1000)
I assume that offset_time is a number. If not, just reconstruct it using arithmetic. Keep in mind that Lua uses doubles for numbers and so a 5-byte integer fits just fine.
Related
Can anyone explain why the result is 252.99999999999997 and not 253? What should be used instead to get 253?
double x = 2.11;
double y = 0.42;
print(((x + y) * 100)); // print 252.99999999999997
I am basically trying to convert a currency value with 2 decimal (ie £2.11) into pence/cent (ie 211p)
Thanks
In short: Because many fractional double values are not precise, and adding imprecise values can give even more imprecise results. That's an inherent property of IEEE-754 floating point numbers, which is what Dart (and most other languages and the CPUs running them) are working with.
Neither of the rational numbers 2.11 and 0.42 are precisely representable as a double value. When you write 2.11 as source code, the meaning of that is the actual double values that is closest to the mathematical number 2.11.
The value of 2.11 is precisely 2.109999999999999875655021241982467472553253173828125.
The value of 0.42 is precisely 0.419999999999999984456877655247808434069156646728515625.
As you can see, both are slightly smaller than the value you intended.
Then you add those two values, which gives the precise double result 2.529999999999999804600747665972448885440826416015625. This loses a few of the last digits of the 0.42 to rounding, and since both were already smaller than 2.11 and 0.42, the result is now even more smaller than 2.53.
Finally you multiply that by 100, which gives the precise result 252.999999999999971578290569595992565155029296875.
This is different from the double value 253.0.
The double.toString method doesn't return a string of the exact value, but it does return different strings for different values, and since the value is different from 253.0, it must return a different string. It then returns a string of the shortest number which is still closer to the result than to the next adjacent double value, and that is the string you see.
I am trying to convert NSString to long but I am getting garbage value. Below is my code :
long t1 = [[jsonDict valueForKeyPath:#"detail.amount"]doubleValue] * 1000000000000000000;
long t2 = [[jsonDict valueForKeyPath:#"detail.fee"]doubleValue] * 10000000000000000;
NSLog(#"t1: %ld",t1);
NSLog(#"t2: %ld",t2);
detail.amout = 51.74
detail.fee = 2.72
O/P :
t1: 9223372036854775807 (Getting Garbage value here)
t2: 27200000000000000 (Working fine)
Thanks in advance.
Each number types (int, long, double, float) has limits. For your long 64 bit (because your device is 64bit) number the upper limit is :9,223,372,036,854,775,807 (see here: https://en.wikipedia.org/wiki/9,223,372,036,854,775,807)
In your case, 51.74 * 1,000,000,000,000,000,000 =
51,740,000,000,000,000,000
While Long 64bit only has a maximum of
9,223,372,036,854,775,807
So an overflow happens at 9,223,372,036,854,775,808 and above. Which is what your calculation evaluates into.
Also to note, that what you are doing will also cause problem if you only cater for 64bit long range, because what happens when your app runs on a 32bit (like iPhone 5c or below)?
Generally a bad idea to use large numbers, unless you're doing complex maths. If number accuracies are not critical, then you should consider simplifying the number like 51,740G (G = Giga). etc.
It's because you're storing the product to long type variables t1 and t2.
Use either float or double, and you'll get the correct answer.
Based on C's data types:
Long signed integer type. Capable of containing at least the
[−2,147,483,647, +2,147,483,647] range; thus, it is at least 32
bits in size.
Ref: https://en.wikipedia.org/wiki/C_data_types
9223372036854775807 is the maximum value of a 64-bit signed long. I deduce that [[jsonDict valueForKeyPath:#"detail.amount"]doubleValue] * 1000000000000000000 is larger than the maximum long value, so when you cast it to long, you get the closest value that long can represent.
As you read, it is not possible with long. Since it looks like you do finance math, you should use NSDecimalNumber instead of double to solve that problem.
I have two cards which contains a hex value, I am struggling to find out what kind of algorithm is used ti get the decimal value.
8HEX from chip: 0b98c44a Printed on card: 3491308370
8HEX from chip: 0c96425c Printed on card: 812204602
does any one of you number experts in here find out how it is done, you helped me with this before :)
The relation between the numbers seems to be that the bits of every byte has been reversed.
When you print first pair in binary they are:
11010000 00011001 00100011 01010010 = 3491308370
00001011 10011000 11000100 01001010 = 0x0b98c44a
The second pair is:
00110000 01101001 01000010 00111010 = 812204602
00001100 10010110 01000010 01011100 = 0x0c96425c
If you want to know how to convert one number to the other, you should mention which programming language you are using.
Hi
I want to convert "qrysth.Fields[i].AsFloat" to a string so I use the following code:
FormatFloat('0.###############',qrysth.Fields[i].AsFloat)
but I find the result string is 12.000000000000001 while qrysth.Fields[i].AsFloat is 12.00. I know FormatFloat actually not use 12.00 to do the convert, but use an infinite number of binary to do the convert. (like 0.1 in decimal system is 0.1, but it is an infinite number in binary system 0.00011001100...)
Is there other way I could get 12.00 in the case above? or 12.000000000000000 at least?
If you really get 12.000000000000001, then your field didn't hold exactly 12, so the output is correct. You asked for high precision by putting so many # characters in the format. If you don't want it so precise, then use a less precise format string.
FormatFloat('0.00',qrysth.Fields[i].AsFloat) will give '12.00'.
To be able to get '12.000000000000000' you should do the rounding yourself, as there's no loss of precision.
I want to convert
"qrysth.Fields[i].AsFloat" to a string
Then why not use AsString?
qrysth.Fields[i].AsString
This will give you the best representation, as long as you're not concerned about the exact width. If you are, use FormatFloat with the exact number of digits you need - in other words, if you're looking for 12.00, use FormatFloat('##.##', qrysth.Fields[i].AsFloat), or even better CurrToStrand AsCurrency, as they automatically uses two digits after the decimal point.
function MyFormatFloat(V: Double): String;
const
DesiredMinPrec = '0.000000000000000';
AssumedMaxPrec = '0.#####';
begin
Result := FormatFloat(DesiredMinPrec, StrToFloat(FormatFloat(AssumedMaxPrec, V)));
end;
I have this line, which shows the minutes and seconds. But I have to add milliseconds to it as well for greater accuracy. How do I add that in this line, or is there an easier way to get the desired result?
#duration = [cd.ExactDuration/60000000, cd.ExactDuration/1000000 % 60].map{|t| t.to_s.rjust(2, '0') }.join(':'))
The exact duration type is saved in microseconds. So the first converts to microseconds to minutes, the second part is microseconds to seconds. Now I need to add milliseconds.
cd.ExactDuration/1000 % 1000 should do the trick.
Of course you may also want to tweak the formatting, since that's a datum you don't want to right-justify in a 2-wide field;-). I'd suggest sprintf for string-formatting, though I realize its use is not really intuitive unless you come from a C background.