vbakke
commented
6 years ago I'm not sure, but I have a feeling that we are trying to tackle more that one obstacle with the same recipe. But I don't think we have one-solution-fits-all-problems here.
First of all, I don't think we should leave anything up to the OS/architecture. (Unless, ........, see exception below.)
But, let's agree separate the issues:
- A) IOTA team has already encoded negative values in trits, e.g. -4Mi and +4Mi. (Am I right in assuming these values are encoded in trits?)
- B) "Converting" integer/floats is different from converting (large) streams of bit/trits/bytes/trytes.
- C) The current asciiToTrytes convert 3 trits to "tryte3 characters" 9+A-Z is widely recognised.
- D) Conversions are "one-way". (E.g. trytes2ascii can convert back to the original bytes, but cannot convert any tryte. Same the other way.)
A) numbers We'll just have to leave this as it is. Don't we. Messing with this will break too much. But it solves negative trit values.
B) - Streams To save space, we can convert a long stream of trits, as a very large number, and then encode that value as bits. (I think is similar the what @sketch34 suggest in https://github.com/vbakke/trytes/issues/6.)
I haven't had time to do the maths here. But I believe in such a solution, the last trit transferred, will influence all the bits in the transaction. Meaning we cannot start converting before we have received all trits.
Pro: We only waste at the maximum 7 bits (if converting to bytes), Con: Large messages will most likely create problems.
A compromise is to block ting off in smaller batches. That will waste more bits/trits, but the whole process is more manageable.
C) IOTA tryte characters How 3 trits are encoded as the 9 + A-Z characters is widely recognised. And I don't think we can break this.
A huge benefit of this, is that having the IOTA tryte character, we have abstracted the whole trit question. We don't need to know anymore. The trit implementation is completely hidden away. And all we need to care about is the values 0-26 (as in asciiToTrytes.js)
I think this is a great. Trits can be implemented by the hardware in the way they want. As long as it gets converted to 9A-Z, the application layer does not even need to know if it is balanced or unbalanced trits.
This is the exception for the comment at the top. OS/Architecture should not dictate the application level. With the IOTA character abstraction layer, the to worlds can live separate.
D) Conversions are "one-way" Obviously, not really one-way, as you must be able to revert back to the original.
But when converting from, e.g. trits: even using B) you end up with only a subset of the possible bits after the conversion. You can convert back to the original. But you cannot use the same function to convert any of the superset's combinations. (Like the bucket example: You can pour a gallon into a 10L bucket. And back. But never the full 10L bucket into a gallon.)
Summary
I feel like what I'm writing is not open for other ideas, and only arguing for my own view here. I don't mean to.
I also feel that you are focused on a topic I regard as already solved in the lower level. I focus more in the application level.
Maybe I don't see the same issues since I don't have the same knowledge as you. Do you agree with some of the bullet points above?
How does the process of encoding trits into bytes work when the trits represent a negative value?
For example, consider the following sequence of little-endian* trits:
00++000++--+-bal3
These trits represent the value -42424210.
How do we determine the length of the resulting binary sequence? +42424210 can be represented using 19 bits (11001111001001100102):
signed long)?* (in this context, assume little-endian trits and bits — that's a whole 'nother can of worms!)