An interesting concept is base256 encoding that is visually useful. As a simple test
u: 256 + i.8 32 ĀāĂ㥹ĆćĈĉĊċČčĎďĐđĒēĔĕĖėĘęĚěĜĝĞğ ĠġĢģĤĥĦħĨĩĪīĬĭĮįİıIJijĴĵĶķĸĹĺĻļĽľĿ ŀŁłŃńŅņŇňʼnŊŋŌōŎŏŐőŒœŔŕŖŗŘřŚśŜŝŞş ŠšŢţŤťŦŧŨũŪūŬŭŮůŰűŲųŴŵŶŷŸŹźŻżŽžſ ƀƁƂƃƄƅƆƇƈƉƊƋƌƍƎƏƐƑƒƓƔƕƖƗƘƙƚƛƜƝƞƟ ƠơƢƣƤƥƦƧƨƩƪƫƬƭƮƯưƱƲƳƴƵƶƷƸƹƺƻƼƽƾƿ ǀǁǂǃDŽDždžLJLjljNJNjnjǍǎǏǐǑǒǓǔǕǖǗǘǙǚǛǜǝǞǟ ǠǡǢǣǤǥǦǧǨǩǪǫǬǭǮǯǰDZDzdzǴǵǶǷǸǹǺǻǼǽǾǿ will hopefully show up in all modern email clients. The problem with using the "superascii" code page is that it contains unprintable characters. while the above is the most computer efficient implementation of base256 display, excellent other choices would be: 1. replace only the unprintable superascii characters 2. do so in a way that doesn't mess up J's boxing display. 3. still show up in any email client/browser from this decade. 4. Substitute with an eye for flexibility of unprintables such that greek/cyrillic/arabic/apl/math can be rendered (alongside "core superascii") one at a time. There may (I have no idea though japanese seems to use 81 phoneme characters) be some useful characters that can be further interpreted by asian languages as doubles or triples. while adding and subtracting 256 is dead simple conversion for encoding, it is not rocket science to handcraft a substitution table. The main purpose of this is to just display binary data. the convenience of encoding text into bytes with just a "document code page" overhead. Its also happens to be quite easy to take any list of integers and determine what code page it belongs to (as long as there is common superascii) if the integers include greek or japanese characters, then that is the writer's code page. The reader can display in any code page if all of the foreign characters "are greek to them" Has this idea already been implemented somewhere? ----- Original Message ----- From: 'Pascal Jasmin' via Programming <[email protected]> To: "[email protected]" <[email protected]> Cc: Sent: Tuesday, July 7, 2015 12:09 AM Subject: Re: [Jprogramming] interesting unicode some more functions uucp2 =: ucp`]`(ucp@:u:)@.(1 i.~ 2 131072 = 3!:0)"1 :.utf82 utf82 =: [: ": uucp2`(uucp2 ::u:@:({&a.))@.([: *./ 256&>)^:(1 4 64 e.~ 3!:0)"1 :.uucp2 futf =: 3 u: ":@:uucp2 :.fucp fucp =: 3 u: uucp2 :.futf the variants of uucp and utf8 take as input strings, unicode or integers, and ensure widechars or utf8 format. futf takes 3 types of input and returns utf8 bytes. fucp takes 3 types of input and returns unicode shorts. The only flakey part is converting from utf8 bytes directly to unicode shorts. If you don't know whether input integers are utf8 or utf16, you can use utf82 first as in: uucp2@:utf82 > uucp2@:utf82 each futf each fucp each utf82 each futf each uucp2 each > <@utf82"1 i.8 32 > uucp2@:utf82 each fucp each fucp each futf each <@utf82"1 ] 0 10000 20000 > +/ i.8 32 NB. ;: doesn't work well with utf. though cut is ok ;: '123 34 44 asdf' , , ' ' , "1 uucp2 2 }. i.8 24 fucp each cut utf82 '123 34 44 asdf' , , ' ' , "1 uucp2 4 }. i.8 24 ----- Original Message ----- From: 'Pascal Jasmin' via Programming <[email protected]> To: Programming Forum <[email protected]> Cc: Sent: Monday, July 6, 2015 7:46 PM Subject: [Jprogramming] interesting unicode u: 256#. inv 9812938749123747923849273491287349128437921837928173492734791823749102983479128379128472342342342342342342342343x will print visually useful binary data (I guess referred to as superascii here: http://www.jsoftware.com/jwiki/Guides/UnicodeGettingStarted?highlight=%28unicode%29) timespacex 'u: 65536#. inv 9812938749123747923849273491287349128437921837928173492734791823749102983479128379128472342342342342342342342343x' 0.00072128 77184 timespacex 'u: 256#. inv 9812938749123747923849273491287349128437921837928173492734791823749102983479128379128472342342342342342342342343x' 0.00013824 114944 quite a bit faster to just stick to superascii, but the reason for it is this surprising result: timespacex '256x#. 256#. inv 9812938749123747923849273491287349128437921837928173492734791823749102983479128379128472342342342342342342342343x' 0.00016256 115200 timespacex '65536x#. 65536#. inv 9812938749123747923849273491287349128437921837928173492734791823749102983479128379128472342342342342342342342343x' 0.00069696 77440 its surprising in that it should be less work to split and reassemble into larger chunks. another quirk: (expected) 3!:0 u: 65536 #. inv 9812923438x 131072 3!:0 ": u: 65536 #. inv 9812923438x 2 NB. string but displays the same as if unicode. sounds neat. 3 u: u: ": u: 65536 #. inv 9812923438x 2 228 163 165 229 144 174 if you take a string that looks like unicode it turns into superascii 3 u: u: 65536 #. inv 9812923438x 2 18661 21550 one way to ensure the right result is to use instead of uucp, uucp2 =: ucp`]`(ucp@:u:)@.(1 i.~ 2 131072 = 3!:0) 3 u: uucp2 3 u: u: 65536 #. inv 9812923438x 2 18661 21550 3 u: uucp2 ": u: 65536 #. inv 9812923438x 2 18661 21550 3 u: uucp2 u: 65536 #. inv 9812923438x 2 18661 21550 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
