Re: Draft of Binary module

>> A second stream of consciousness:
>>
>> I feel very uneasy about representing octets using integers. So I ask
>> myself why? Is it history - i.e. eXist and Zorba (maybe others)
>> represent octets as octal strings and allow for the conversion of
>> octal to/from decimal with functions.
>
> Odd, I haven't seen octal used in anger for about 25 years, I thought it was
> completely obsolete. But then I guess I've managed to avoid writing in C.
> Every since the industry standardized on an 8-bit byte, hexadecimal has
> seemed much more natural.

So perhaps I should elaborate on my use case for Octal numbers. In
eXist-db we implement as a minimum a Unix style permission model, this
is convenient for many of our users as they already understand the
Unix permission model. So each file in eXist-db has a 'mode' which
people are used to expressing as an octal number.

e.g. sm:chmod(xs:anyURI("/db/myfile.xml"), "0770")

Would change the mode of 'myfile.xml' to 0770 (i.e. rwxrwx---). So yes
we have users that know and are used to working with Octal numbers, in
the past we used to expect people to supply an xs:integer equivalent,
but that was really a pain in the ass, as its hard for users to know
that 0770 is equal to 504. Its much easier to think of these mode
values in octal as read (4) write(2) and execute (1) can easily be
composed and understood by humans whereas an integer mask cannot.

>>
>> An octet is implicitly in Base 8
>
> Eh? if it's anything, surely it's implicitly in base 2?

Maybe we are talking at cross purposes? I am talking about octal
numbers, i.e. the number system base 8 where a single value can be in
the range of 0 - 7.

>> , so why would I then want to
>> manipulate it as thought it were Base 10 (but without converting it to
>> Base 10). This just doesnt make sense to me -
>>
>> If I understand correctly -
>>
>> bin:binary-to-octets(xs:hexBinary("FFFF"))  would give me (255, 255)
>
> Seems natural to me.
>
>>
>> Rather if you want to go to base10 then
>> bin:binary-to-radix(xs:hexBinary("FFFF"), 10) could give me 65535.
>
> But there's nothing intrinsically decimal about the value 65535, other than
> the way it's being printed on the page.
>
> bin:binary-to-radix(xs:hexBinary("FFFF"), 17) would give you exactly the
> same integer - it only becomes base 17 when you convert the integer to a
> string to display it.
>
>>
>>
>> All of the bitwise operators seem to operate on xs:hexBinary
>
> Yes, I think it's a separate discussion whether bitwise operators on
> integers would be more useful. I think the main problem is that we don't
> have hex literals, so we can't say $x & xFF00, instead we have to say either
>
> (1) if we use hexBinary: bin:and($x, xs:hexBinary("FF00"))
> (2) if we use base64Binary: bin:and ($x, xs:base64Binary("/wA="))
> (3) if we use integer: bin:and($x, 65280)
>
> None of these is nice, but the first seems to me the most readable. If we go
> with (and/or/not) working on integers, then perhaps we should also have
> functions
>
> bin:hex("FF00") => 65280
>
> bin:octal("177400") => 65280 (since you're telling me that there are indeed
> people who still use octal...)
>
> Michael Kay
> Saxonica
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
adam@exist-db.org
irc://irc.freenode.net/existdb

Received on Thursday, 14 March 2013 11:40:20 UTC