
|
If you were logged in you would be able to see more operations.
|
|
|
this data format would be composed of zeros and ones, of variable length like strings and lists (as much as can fit in the script memory)
(rawbits)astring would either convert the string into raw bits if the string is composed only of 1's and 0's, or no bits at all if there is anything else, same thing for integers
(string)arawbits would result in a string composed of zeros and 1's in the exact order they are in the rawbits, or an empty string if there are no bits
(integer)arawbits would result in literal trensplantation of zeros and 1's, would look the same if either is converted to string, except for any zeros to t he left of the last 1s, but if there are no bits it would still become the integer 0
to do actual bit by bit conversion between types, there would be llRawbits2* and ll*2Rawbits functions that would see the bits as bits on all data types. For the data types that got a fix number of bits, like integers, the llRawbits2* functions would have a parameters for the beginning bit, if it runs out of bits, the remaining bits are zero. If it's necessary to have a valid format, like valid UTF* encoding for strings, if the rawbits are not in the right format, return a constant.
Just about all operations that can be done with integers should work with rawbits, but there would be no wrapping around if the value goes bigger than DEBUG_CHANNEL. There would also be functions like for lists and strings, for finding and replacing groups of bits. There would also be functions for inserting/overwriting N copies of a group of bits (somthing like llRawbitsPatternFill(rawbits destrawbits, rawbits sourcerawbits, integer startpoint, integer repetitions, integer insertoroverwrite) ) if the repetitions go beyond existing bits, they create new ones, and if it's set to insert isntead of overwrite, existing bits past the start point are bumped to the next bits to fit the fill pattern. Ideally there should also be a function to reverse the order of the bits.
Perhaps the llRawbits2* functions should have a begin and end parameters, at least for the ones to formats that don't require a fixed number of bits.
To reduce the bit count, there is no need to add an additional command, just use the replace or pattern fill command and replace some bits with an empty rawbits pattern (I'm not sure which character(s) would be used to surround rawbits typed int he script, but whatever is chosen, to make an empty rawbits just do it like for empty strings and lists, or perhaps don't delimit rawbits, but represent an empty rawbits by a single decimal point (the little dot used on floats) with no digits on either side)
Perhaps use the decimal point as the delimiter char, while also allowing additional points in the middle, if there is either a digit, or another point touching it's not the end of the rawbits group ( both . and .. would be empty rawbits, and .10. and .1.0.0.110.01.0.0....10011.. etc would all be valid rawbits). When just assigning a value, the points in the middle are ignored, but when replacing or doing pattern fills, whenever an inner dot is present, the bit it replaces/overwrites is deleted and the bits surrounding come together. Though I'm not sure how exactly the void bits would be stored int he rawbits, perhaps they can't really exists, and we just use a single . for empty rawbits and never together with any digit or other points as described above and no interleaved deletion.
ps:I'm not sure if I'm missing anything for the moment, this might not be the final deifnition, and of course, I'm open to suggestions 
|
|
Description
|
this data format would be composed of zeros and ones, of variable length like strings and lists (as much as can fit in the script memory)
(rawbits)astring would either convert the string into raw bits if the string is composed only of 1's and 0's, or no bits at all if there is anything else, same thing for integers
(string)arawbits would result in a string composed of zeros and 1's in the exact order they are in the rawbits, or an empty string if there are no bits
(integer)arawbits would result in literal trensplantation of zeros and 1's, would look the same if either is converted to string, except for any zeros to t he left of the last 1s, but if there are no bits it would still become the integer 0
to do actual bit by bit conversion between types, there would be llRawbits2* and ll*2Rawbits functions that would see the bits as bits on all data types. For the data types that got a fix number of bits, like integers, the llRawbits2* functions would have a parameters for the beginning bit, if it runs out of bits, the remaining bits are zero. If it's necessary to have a valid format, like valid UTF* encoding for strings, if the rawbits are not in the right format, return a constant.
Just about all operations that can be done with integers should work with rawbits, but there would be no wrapping around if the value goes bigger than DEBUG_CHANNEL. There would also be functions like for lists and strings, for finding and replacing groups of bits. There would also be functions for inserting/overwriting N copies of a group of bits (somthing like llRawbitsPatternFill(rawbits destrawbits, rawbits sourcerawbits, integer startpoint, integer repetitions, integer insertoroverwrite) ) if the repetitions go beyond existing bits, they create new ones, and if it's set to insert isntead of overwrite, existing bits past the start point are bumped to the next bits to fit the fill pattern. Ideally there should also be a function to reverse the order of the bits.
Perhaps the llRawbits2* functions should have a begin and end parameters, at least for the ones to formats that don't require a fixed number of bits.
To reduce the bit count, there is no need to add an additional command, just use the replace or pattern fill command and replace some bits with an empty rawbits pattern (I'm not sure which character(s) would be used to surround rawbits typed int he script, but whatever is chosen, to make an empty rawbits just do it like for empty strings and lists, or perhaps don't delimit rawbits, but represent an empty rawbits by a single decimal point (the little dot used on floats) with no digits on either side)
Perhaps use the decimal point as the delimiter char, while also allowing additional points in the middle, if there is either a digit, or another point touching it's not the end of the rawbits group ( both . and .. would be empty rawbits, and .10. and .1.0.0.110.01.0.0....10011.. etc would all be valid rawbits). When just assigning a value, the points in the middle are ignored, but when replacing or doing pattern fills, whenever an inner dot is present, the bit it replaces/overwrites is deleted and the bits surrounding come together. Though I'm not sure how exactly the void bits would be stored int he rawbits, perhaps they can't really exists, and we just use a single . for empty rawbits and never together with any digit or other points as described above and no interleaved deletion.
ps:I'm not sure if I'm missing anything for the moment, this might not be the final deifnition, and of course, I'm open to suggestions  |
Show » |
| There are no comments yet on this issue.
|
|