Just for the record: Rick and Erich have updated the code and improved the
speed considerably, which
is really great!
---rony
On 19.04.2019 17:01, Moritz Hoffmann wrote:
> Hi,
> looking at ooRexx's implemetation of x2c I find the original code much easier
> to understand and to
> reason
Double-checked the test hex strings and their positions of illegal whitespace
chars, here the native
routine with the corrected position:
int64_t hex2char(RexxCallContext *rcc, CSTRING hexData, size_t len, char
*data)
{
// check for trailing whitespace
char
On 19.04.2019 15:55, Rony G. Flatscher wrote:
> On 19.04.2019 13:09, Rick McGuire wrote:
... cut ...
Sorry, the following error message is correct, the position 6 is correct (had
changed the hex string):
>
> * the hexadecimal string "Ab 0 0 ff 00 ff 00 ff 12" has an illegal
>
On 19.04.2019 13:09, Rick McGuire wrote:
> Well, you're missing all of the logic that allows for blanks at the
> boundaries and you're also
> assuming that you have an even number of digits to convert. If you remove all
> of the things that
> x2c() has to account for, then yes, you can do a
Well, you're missing all of the logic that allows for blanks at the
boundaries and you're also assuming that you have an even number of digits
to convert. If you remove all of the things that x2c() has to account for,
then yes, you can do a faster conversion.
Rick
On Fri, Apr 19, 2019 at 6:51 AM
Thank you all for your feedback to my quite "dirty" ;) posting!
As Mike pointed out 'a'-'z' were not honored, but also blanks in between pairs
of hex digits, which
Rexx allows for.
Rewriting the algorithm a little bit it runs even faster (up to 4.5 times
compared to x2c()):
/* A Rexx hex
: Re: [Oorexx-devel] An alternative algorithm for x2c()
Rony:
Too many comparisons are being done from a performance perspective; a minimal
comparison for validation and no comparison for translation is the fastest.
Actual translation should be done with a pair of 256-byte arrays for s
Rony:
Too many comparisons are being done from a performance perspective; a minimal
comparison for validation and no comparison for translation is the fastest.
Actual translation should be done with a pair of 256-byte arrays for speed AND
portability across character sets. Speed varies
case 'A': tmp=10; break;
case 'B': tmp=11; break;
case 'C': tmp=12; break;
case 'D': tmp=13; break;
case 'E': tmp=14; break;
case 'F': tmp=15; break;
Also need to add cases 'a' through 'f'?
___
Not sure if it would be any faster, but maybe neater to simplify some of the
below along the lines of:
case '0':
case '1':
case '2':
case '3':
case '4':
case '5':
case '6':
case '7':
case '8':
case '9': tmp=hexData[i-1]-'0'; break;
(I'd also make the increments of i
10 matches
Mail list logo