Data inspector: .net decimal type
Data inspector: .net decimal type
Hi,
I use HxD often to decipher the format of different data files and it's just great.
These days, I'm facing a problem where I think that floating values are stored in the decimal .net format, see here: https://herongyang.com/C-Sharp/Floating ... cimal.html
Is it possible to add this type in the data inspector?
I use HxD often to decipher the format of different data files and it's just great.
These days, I'm facing a problem where I think that floating values are stored in the decimal .net format, see here: https://herongyang.com/C-Sharp/Floating ... cimal.html
Is it possible to add this type in the data inspector?
Re: Data inspector: .net decimal type
The link doesn't load currently, but I found another one that is quite useful, especially for an implementation in Delphi:
http://rvelthuis.de/programs/decimals.html
Delphi has a related datatype called Currency, which is a fixed-point datatype: https://docwiki.embarcadero.com/Librari ... m.Currency
http://rvelthuis.de/programs/decimals.html
Delphi has a related datatype called Currency, which is a fixed-point datatype: https://docwiki.embarcadero.com/Librari ... m.Currency
A Currency object is implemented as a 64-bit signed integer. The interval of Currency is
[-922337203685477.5808.. 922337203685477.5807
- (263+1)/10000.. 263/10000]
Re: Data inspector: .net decimal type
After reading through it a bit, it's possible, but non-trivial, since I need to add support for handling a 96-bit integer division by 10 and multiplication by 10, while 96-bit integers are not supported on 32-bit architectures (nor 128-bit integers).
Then handing over this sequence of generated decimal digits, or rather characters to the standard formatting routine. Possible, but less trivial than it might seem at first.
This stackoverflow answer might help, since it only requires bitshifts, which should be relatively easy to implement without direct 96-bit integer support:
https://stackoverflow.com/a/19076173
And this for multiplication: https://stackoverflow.com/questions/107 ... eger-by-10
But they both still need addition over a 96-bit integer (or subtraction), which would be slow, since addition has to be emulated, yet again. In assembly this could be easier (and faster), but also non-portable, hmmm...
Then handing over this sequence of generated decimal digits, or rather characters to the standard formatting routine. Possible, but less trivial than it might seem at first.
This stackoverflow answer might help, since it only requires bitshifts, which should be relatively easy to implement without direct 96-bit integer support:
https://stackoverflow.com/a/19076173
And this for multiplication: https://stackoverflow.com/questions/107 ... eger-by-10
But they both still need addition over a 96-bit integer (or subtraction), which would be slow, since addition has to be emulated, yet again. In assembly this could be easier (and faster), but also non-portable, hmmm...
Re: Data inspector: .net decimal type
Thank for looking at this request. Is the computation speed really important?
Re: Data inspector: .net decimal type
It's not only speed but complexity of the algorithm. Using assembler is actually a bit easier in this case, since additions with carry exist (which allows to chain several 32-bit additions).
Still an implementation that needs quite some dev time.
Still an implementation that needs quite some dev time.
Re: Data inspector: .net decimal type
Yes, I understand the problem since we just have the 64 bits integer type in C (in most cases). But, what about the use of double type and even single precision float to store the result of these 96 bits? Of course, we loose digits, but the point is just to recognize if we have decimal .net format stored inside a file.
Re: Data inspector: .net decimal type
Here a proof of concept using double type in C/C++:
Code: Select all
unsigned char st[16];
/* The 16 bytes of decimal format are present in st[] in little endian order */
double d = 0;
for (int i = 0; i < 12; i++) d += pow(16, (double)(i*2)) * (double)st[i];
d /= pow(10, (double)st[14]);
if (st[15] & 0x80) d = -d;
/* The result is in d */
Re: Data inspector: .net decimal type
I forgot to say that I'm aware this is not optimized at all. It's fast coded, just enough to make it work. In real word, I would take the 12 bytes of the mantissa as three 32 bits integers or one 64 bits and one 32 bits in order to limit the number of multiplications.
Re: Data inspector: .net decimal type
I started to make a 96bit integer implementation using assembler. Since it's just for adding and subtractng, the amount of assembler is not too much. The major reason is that it would be a pitty to round a purposefully precision datatype. It needs more testing and checking, but the basic approach works already. At least binary to string conversion, the reverse way still needs time.
Part of the explanation given is also to explain the time it takes to implement properly. Many people want quick and dirty solutions, I also like to have the result be stable, and predictable, since it will be in my program longer term.
Thanks for your input/sustained interest, together with donations, it makes it more motivating to implement.
Part of the explanation given is also to explain the time it takes to implement properly. Many people want quick and dirty solutions, I also like to have the result be stable, and predictable, since it will be in my program longer term.
Thanks for your input/sustained interest, together with donations, it makes it more motivating to implement.
Re: Data inspector: .net decimal type
You're a perfectionist. I wasn't even aware that most changes in the data inspector reflect in the file's bytes.Maël wrote: ↑24 Mar 2022 15:04 I started to make a 96bit integer implementation using assembler. Since it's just for adding and subtractng, the amount of assembler is not too much. The major reason is that it would be a pitty to round a purposefully precision datatype. It needs more testing and checking, but the basic approach works already. At least binary to string conversion, the reverse way still needs time.
Part of the explanation given is also to explain the time it takes to implement properly. Many people want quick and dirty solutions, I also like to have the result be stable, and predictable, since it will be in my program longer term.
Thanks for your input/sustained interest, together with donations, it makes it more motivating to implement.
That's the way... I use your program in some fashion but, other people use it differently.
Anyway, it's a great software. Thank you for this amazing work.
Re: Data inspector: .net decimal type
Upon more exact inspection it turns out the shift/add based division solution only works for 32 bit integers, and I first need to understand this better to make it work with wider integers.
Re: Data inspector: .net decimal type
Much clearer version of the divide by 10 code:
https://hackaday.com/2020/06/12/binary- ... aint-easy/
https://hackaday.com/2020/06/12/binary- ... aint-easy/
Re: Data inspector: .net decimal type
Just an idea, it's maybe stupid but... Is division by ten really mandatory to display a .net decimal number?
Once you have the string that represent the 96 bits integer*, you have just to put the decimal point at the right place and, if needed, add the decimal exponent. All of that could be directly calculated by the 8 bits value of this exponent.
(*) I don't know whether it's easy or not to get.
Once you have the string that represent the 96 bits integer*, you have just to put the decimal point at the right place and, if needed, add the decimal exponent. All of that could be directly calculated by the 8 bits value of this exponent.
(*) I don't know whether it's easy or not to get.
Re: Data inspector: .net decimal type
Divison by 10 is necessary to convert the integer to a sequence of characters that can be displayed as a string. There is no IntToStr for UInt96.
I mostly understood the algorithm now, just trying to understand how the error correction works in the last step. When I did I should be able to adapt it and make it work.
I mostly understood the algorithm now, just trying to understand how the error correction works in the last step. When I did I should be able to adapt it and make it work.
Re: Data inspector: .net decimal type
Ok, I was fearing something like that. The principle of this algorithm is comprehensible but so complicated compared to the use of high-level language (I program a little in assembly, that said). I never realized that a division by ten is always an approximation.Maël wrote: ↑25 Mar 2022 15:32 Divison by 10 is necessary to convert the integer to a sequence of characters that can be displayed as a string. There is no IntToStr for UInt96.
I mostly understood the algorithm now, just trying to understand how the error correction works in the last step. When I did I should be able to adapt it and make it work.