The "standard" way to handle innate significance greater than the number of specified digits is to expand the field to accommodate. At least that's the way printf works.
Why does hex even get used by programmers?
For me the answer is that you get a direct representation of the bits of the value in a more compact form than with binary.
While it may be mathematically correct to add more preceding zeroes, for a logical bit representation this is wrong.
It suggests additional zero bits where no bits are (a not existing bit is not zero).
So I would say there is a mathematical hex methode and a logical hex methode. And the original hex methode was just a logical one. It may even be the correct way to wrap around and begin again with bit 0..3 if you show more than 8 digits for a locigal methode.
Andy
BTW my initial (logical) hex methode was: (31 bytes)
pub hex(value,digits) : c
repeat digits
if (c := (value <-= 4) & $F) > 9
c += 7
out(c + "0")
I guess the key argument for matching performance with expectation is the comment in the original code:
digits: number of hexadecimal digits to send. Will be zero padded if necessary.
To me, this implies that any number of zero digits can be added, as necessitated by the value of the digits parameter. There is nothing to suggest that eight is the maximum value. And if you're coming from a background, such as C or Perl, where printf is used, it's entirely logical to expect as many leading zeroes as you specify, regardless of whether they are significant or not. Again, it's astonishing to me that this subject has engendered more than two posts worth of discussion. Just fix the dang code, and all will be right with the universe.
Before somebody else notices it:
My code from post #22 does not work correct for lower than 8 digits !
That happens if you only are concentrated on one aspect.
This version should work, but saves not so much code space (42 bytes):
pub hex(value,digits) : c
repeat while digits > 0
if digits-- < 9
if (c := value >> (digits<<2) & $F) > 9
c += 7
out(c + "0")
Your code reminded me that I neglected one of the edge conditions in my own code: i.e. the case where digits < 0. Here's the fix:
PUB hex(value, digits) : c
value ->= digits << 2
repeat while digits-- > 0
char((digits < 8) & ((((c := (value <-= 4) & $f) > 9) & 7) + c) + "0")
BTW, just so we're all on the same page, what's the correct procedure for measuring code size? I've been comparing the total size reported via F8 with the method vs. with it deleted completely.
Phil, Using bst here, I've been bringing up the compiler listing and either subtracting or actually counting the bytes. With that I count 43 bytes for your method (all bases covered!) just above post #39. On the other hand, when I choose compile information with and without your method, it reports a difference of 13 longs, which would be 52 bytes. How does the PC count the overhead?
Andy, I too count 42 bytes for your recent method post #38 in the compiler listing. This one seems correct too, and covers a negative number of digits.
Thanks, Tracy, 'interesting results. Andy's code and mine are virtually identical, except that I collapsed his ifs into bitwise ANDs, thinking it would save code space. On the contrary, it seems to have cost a byte and is less readable. Hmm.
Comments
-Phil
PUB hex(value, digits) : c value ->= digits << 2 repeat while digits-- char((digits < 8) & ((((c := (value <-= 4) & $f) > 9) & 7) + c) + "0")BTW, in this version, if digits == 0, nothing gets output, like the original. It's longer than the other entries, though.
-Phil
For me the answer is that you get a direct representation of the bits of the value in a more compact form than with binary.
While it may be mathematically correct to add more preceding zeroes, for a logical bit representation this is wrong.
It suggests additional zero bits where no bits are (a not existing bit is not zero).
So I would say there is a mathematical hex methode and a logical hex methode. And the original hex methode was just a logical one. It may even be the correct way to wrap around and begin again with bit 0..3 if you show more than 8 digits for a locigal methode.
Andy
BTW my initial (logical) hex methode was: (31 bytes)
pub hex(value,digits) : c repeat digits if (c := (value <-= 4) & $F) > 9 c += 7 out(c + "0")To me, this implies that any number of zero digits can be added, as necessitated by the value of the digits parameter. There is nothing to suggest that eight is the maximum value. And if you're coming from a background, such as C or Perl, where printf is used, it's entirely logical to expect as many leading zeroes as you specify, regardless of whether they are significant or not. Again, it's astonishing to me that this subject has engendered more than two posts worth of discussion. Just fix the dang code, and all will be right with the universe.
-Phil
-Phil
My code from post #22 does not work correct for lower than 8 digits !
That happens if you only are concentrated on one aspect.
This version should work, but saves not so much code space (42 bytes):
pub hex(value,digits) : c repeat while digits > 0 if digits-- < 9 if (c := value >> (digits<<2) & $F) > 9 c += 7 out(c + "0")It also shows nothing if digits is 0.Andy
Your code reminded me that I neglected one of the edge conditions in my own code: i.e. the case where digits < 0. Here's the fix:
PUB hex(value, digits) : c value ->= digits << 2 repeat while digits-- > 0 char((digits < 8) & ((((c := (value <-= 4) & $f) > 9) & 7) + c) + "0")BTW, just so we're all on the same page, what's the correct procedure for measuring code size? I've been comparing the total size reported via F8 with the method vs. with it deleted completely.
-Phil
Andy, I too count 42 bytes for your recent method post #38 in the compiler listing. This one seems correct too, and covers a negative number of digits.
-Phil