I was adding ÁÉÍÓÚÝÞÆÖ to áéíóúýþæö lower change.
I have no problems.
I used to - not now.
I am happy with JQT but not really adjusted to it yet.
-
Björn Helgason
gsm:6985532
skype:gosiminn
On 1.3.2014 07:22, "bill lam" wrote:
> Not sure what is your probleam with tolower. Anyways you can
> r
Not sure what is your probleam with tolower. Anyways you can
re-use your old tolower by converting utf8 to latin1, do
everything that you used to and then convert back to unicode.
eg. unicode -> latin1
a. {~ 3&u:@ucp 'utf8 or wide unicode'
do not worry latin1 cannot display correctly in J sess
I wrote a new tolower for nationalcharactersupport.
I have not done that since J turned Unicode.
To begin with then I did it in JQT on the Android.
JQT has never worked for me in Android before this latest release.
It took some time learning how to go about this.
Turns out that the national ch
Thank you all for valuable comments.
--
regards,
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
The idea of J with APL (or APL-like) characters is a perennial topic.
Many of us (myself included) feel that there is a beauty in those symbols.
But I don't think the Jsoftware group should devote *any* time to such
a project. (And I don't think there is any danger of that.)
There are other
programming forum
> Cc:
> Sent: Friday, February 28, 2014 10:32:13 AM
> Subject: Re: [Jprogramming] apl character support
>
> Also, you're sacrificing some of the nice relations between some of the J
> symbols and making it less well-integrated if you throw in random APL
> cha
uare] on chrome webmail client... so unreadable even if I
understood APL.
- Original Message -
From: Devon McCormick
To: J-programming forum
Cc:
Sent: Friday, February 28, 2014 10:32:13 AM
Subject: Re: [Jprogramming] apl character support
Also, you're sacrificing some of the nice re
Also, you're sacrificing some of the nice relations between some of the J
symbols and making it less well-integrated if you throw in random APL
characters. In the above cases, I'm thinking of the relationships between
the variants of "power":
^ exponentiation, ^. log, ^: power conjunction.
Workin
You may think you are close to a solution but there are serious problems.
e.g.
- does * denote times or exponentiation (is * the APL * or the ASCII *)?
- you can enter i. as ⍳ but for i: you must enter i:
- |. is not ⌽ but ⊖, depending on which APL you are talking about
- / is not / but ⌿, depend
With some modicitions, J can accpet both ascii and about
30 APL symbols as primitive,
⌈>. Ceiling
⌊<. Floor
⍴$Shape
∼-. Not
∣|Absolute value
⍳i. Index generator
⋆^Exponential
−-Negation
⌹%. Matrix inverse
○o. P
Originally utf8 allowed at most 6 bytes that would be enough any codepoint
in ucs4. In latter unicode standard, it was decided not all of 32 bits of
ucs4 were needed and the new range corresponds 4 bytes of utf8.
On Feb 28, 2014 4:42 AM, "Raul Miller" wrote:
> Unicode is messy, but it's not that
Unicode is messy, but it's not that messy.
The utf-8 encoding places a limit on how many characters can be
encoded, and if I understand properly, that limit is slightly over a
million, and less than a quarter of those theoretical characters
currently have been assigned. Of course... unicode is a s
Unicode was supposed to be the solution to the problems with the APL chars
as well all the code pages with national characters.
As should be obvious the solution is far from anywhere close.
UTF-8 UTF-16 UTF-32 UTF-64 UTF-???
--
F
'þ' is not a literal. It is UTF-8. To treat it as a literal is wrong. You
can't separate the first half of a UTF-8 character from the last half. In
terms of UTF-8 it is one character but $ treats it as two literal
characters. The thing is that when dealing with UTF-8 one can't expect
primitives des
J literal considers literal _128{.a. as valid. Those bytes are invalid in
UTF-8 as UTF-8 uses them to represent unicode values >127. To represent
those characters in UTF-8 require two literals each. It is not an oddness
in the UTF-8 specification. It is the confusion caused by treating UTF-8 as
lit
On Thu, Feb 27, 2014 at 9:39 AM, Don Guinn wrote:
> Although the unicode value of 'þ' is less than 256 it still must be
> represented with two bytes in UTF-8. This is where it gets confusing to
> view UTF-8 as literal. And why I sometimes think it would be nice if UTF-8
> was a type unique from li
What you are seeing here is an oddness in the unicode specification.
a.i.8 u: 7 u: 'þ'
195 190
7 u: gives you utf-16 character representation, and 8 u: gives you
utf-8 character representation.
It just happens to be the case that the character value in the utf-16
representation of thorn (þ) h
Is 'þ' in the 256 characters? It has a unicode value of 254 but a UTF-8
numeric value of 195 190. It's literal numeric value (non-UTF-8) is invalid
when treated as UTF-8.
# 'þ'
2
#7 u:'þ'
1
254{a.
�
4 u: 254
þ
195 190{a.
þ
3!:0]7 u:'þ'
131072
3!:0 'þ'
2
Although the unicode va
There are a lot of strange things happening regarding national characters.
þ is within the 256 chars but behaves strange regarding a.
7 u: 'þ'
þ
a. i. 7 u: 'þ'
254
254 { a.
�
7 u: 254 { a.
|domain error
| 7 u:254{a.
3 u: 254 { a.
254
'þ' = 254 { a.
0 0
(7 u: 'þ') = 254 { a.
1
IFAIK APL does not allow names with non-ascii character. That will
be an interesting extension but it also depends on locales which
include Indic and Arabic language that I have no knowledge at all.
It is easier if we restrict it to European international
characters, but then I consider it not too
But it is a start to playing with APL characters as names. Some unicode
characters need to be treated like letters and others as words in
themselves for ;: . International characters should be like A-Z,a-z and can
be included in words. Other characters like Greek characters could be
treated as w
There are a variety of different kinds of unicode "characters".
http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters
Looking at the ;: monad, the general classes of characters which one
would expect ;: to recognize are:
Numbers
Letters
Spaces
Other
(and "spelling error").
So the first ste
If we simply allow unicode characters in names, although we can assign
ascii primitives to APL-like names, but that will require space
around each of those names, so that insead of writing
life←{↑1 ⍵∨.∧3 4=+/,_1 0 1∘.⊖_1 0 1∘.⌽⊂⍵}
we need to write
life ← {↑ 1 ⍵ ∨ . ∧ 3 4=+/,¯1 0 1 ∘ .⊖ ¯1 0 1 ∘
Not that I know of - but if it takes 2 keys to produce the mathematical
divide and 2 to produce the box and one to overstrike
what is the gain?
Don.
On 26/02/2014 12:09 PM, Jim Russell wrote:
Has modern technology eliminated over strikes?
On Feb 26, 2014, at 2:52 PM, Don Kelly wrote:
'box d
Has modern technology eliminated over strikes?
> On Feb 26, 2014, at 2:52 PM, Don Kelly wrote:
>
> 'box divide' requires pressing 3 keys at once
--
For information about J forums see http://www.jsoftware.com/forums.htm
I have used APL for many years and while I like the glyphs (eg 'iota' vs
i. ) , having the upper and lower case alphabet]
along with the APL glyphs requires each key having up to 4 characters
resulting in much more use of shift , alt or alt-shift.
'box divide' requires pressing 3 keys at once -
The discussion keeps coming back to APL characters. For now not why not
just look at using international characters (Unicode/UTF-8) as letters in
names? One can assign some of those as letters for primitives if he wants.
Then see where things go.
A problem with accepting unicode/UTF-8 characters i
a. is just 256 literal characters, it is a noun.
I expect u: might have been what you were thinking about? It's a verb.
Thanks,
--
Raul
On Wed, Feb 26, 2014 at 2:19 AM, Björn Helgason wrote:
> Actually I want a. back as it was.
>
> Giving me two or three number is wrong and is confusing at be
Actually I want a. back as it was.
Giving me two or three number is wrong and is confusing at best.
It should return the digital number for Unicode and only one number per
char.
a. is the atomic vector and this way the atomic has grown to include all of
Unicode.
-
Björn Helgason
gsm:6985532
sky
There's an infinite supply of those.
Thanks,
--
Raul
On Tue, Feb 25, 2014 at 4:12 PM, Don Guinn wrote:
> Yes, that's what I do. But it is a problem waiting to bite the unaware.
>
>
> On Tue, Feb 25, 2014 at 12:37 PM, Raul Miller
> wrote:
>
> > You can always yourself a verb to concatenate u
Yes, that's what I do. But it is a problem waiting to bite the unaware.
On Tue, Feb 25, 2014 at 12:37 PM, Raul Miller wrote:
> You can always yourself a verb to concatenate utf-8.
>
> For example: ,&.(7&u:)
>
> Thanks,
>
> --
> Raul
>
>
> On Tue, Feb 25, 2014 at 2:07 PM, Don Guinn wrote:
>
> >
You can always yourself a verb to concatenate utf-8.
For example: ,&.(7&u:)
Thanks,
--
Raul
On Tue, Feb 25, 2014 at 2:07 PM, Don Guinn wrote:
> Sometimes I wish that UTF-8 were considered a unique character type
> different from literal (2) and unicode (131072). Really bad things happen
> i
My experience of teaching both APL and J to college sophomores was that,
despite the "difficulties" of the APL keyboard layout (with key tops having the
APL symbols marked on them), the students found the APL character set quicker
to learn, and remember, than the J symbols. And that for them it
e.com
[mailto:programming-boun...@forums.jsoftware.com] On Behalf Of bill lam
Sent: Monday, February 24, 2014 23:12
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] apl character support
This seems simpler. The first thing to do is build a prototype implementaton,
and then we can see wha
Sometimes I wish that UTF-8 were considered a unique character type
different from literal (2) and unicode (131072). Really bad things happen
if you happen to catenate literal containing UTF-8 characters with unicode.
On Tue, Feb 25, 2014 at 11:58 AM, Björn Helgason wrote:
> It is not much I li
I, too, am very fond of the APL characters but they are a mix of the
conceptually helpful - like ⍉ (transpose) - and ad-hoc obscurities - ⍴
(rho).
The J characters have a bit of ad-hockery about them but are extremely
well-integrated with respect to each other.
Just look across any line of the vo
It is not much I like in m$word but...
Pointing at a char and pressing alt+u gives me a number alt+u again gives
the char again.
The u: exercises in J are a bit confusing.
-
Björn Helgason
gsm:6985532
skype:gosiminn
On 25.2.2014 18:03, "Don Guinn" wrote:
> Searching, counting characters etc. ar
Searching, counting characters etc. are easier to convert UTF-8 to Unicode
(wide), doing whatever, then converting back to UTF-8.
On Tue, Feb 25, 2014 at 9:10 AM, Björn Helgason wrote:
> a. and especially i. a. - looking up chars indexes used to be useful.
>
> It is not as easy anymore.
>
> The
a. and especially i. a. - looking up chars indexes used to be useful.
It is not as easy anymore.
The national chars are often not in there with a single number.
Sometimes two or three.
Reading files also sometimes with unicode markings.
-
Björn Helgason
gsm:6985532
skype:gosiminn
On 25.2.2014
In that case, perhaps my original proposal is feasible. Since utf8
for bmp are atmost 3 bytes, we can scan with look ahead for 3
bytes and convert any APL glyphs to single byte internal
representatin before passing into monad ;:
Вт, 25 фев 2014, Don Guinn писал(а):
> I tried that a while back. I
I tried that a while back. I extended the table for ;: to treat the bytes
for _128{.a to be treated as letters which made all multi-byte UTF-8
treated as alphas. Statements were broken into tokens properly. But then I
found that the interpreter used the top half of a. internally. I mentioned
that i
This seems simpler. The first thing to do is build a prototype implementaton,
and then we can see what are other problems out there.
Пн, 24 фев 2014, Don Guinn писал(а):
> A middle ground might be to allow for some Unicode (UTF-8) to be
> considered letters like a-z,A-Z. Then one could name APL
A middle ground might be to allow for some Unicode (UTF-8) to be
considered letters like a-z,A-Z. Then one could name APL iota to something
like i. . In addition, it would allow non-English languages not be
restricted to ASCII characters for names. Greek letters in mathematics
could be used as na
(continue..)
Monad ;: already can distinguish strings and primitives.
;: 'f=: ''i.''&i.'
+-+--++-+--+
|f|=:|'i.'|&|i.|
+-+--++-+--+
Вт, 25 фев 2014, bill lam писал(а):
> If internal representation is only visible in 5!:x conjunction,
> perhaps we can keep original 5!:x that print ascii
If internal representation is only visible in 5!:x conjunction,
perhaps we can keep original 5!:x that print ascii and add some
new 5!:(10+x) to print APL glyph.
Пн, 24 фев 2014, Roger Hui писал(а):
> Don't go there. Let's say you have some internal representation for
> index-of. What do you out
Don't go there. Let's say you have some internal representation for
index-of. What do you output for 5!:5 <'f' where f=: 'i.'&i.? Would that
result have different lengths at different times? Would the character
string 'i.' in the definition of f be stored as the ASCII characters 105
and 46?
I guess J can support both ascii and APL glyph as primitives by
modifying the c source code for monad ;: and map both ascii and
APL glyph to the same internal representation token for the
primitives.
Since J is script-based, J itself does not need to concern how
APL character will be input or outp
There has been some nice work in other areas to support keyboards. The
following page uses that work to provide an APL keyboard.
http://home.comcast.net/~paul.l.jackson/APL.js/
If you know the APL keyboard, just type ` followed by a normal character
and an APL character will appear.
If you don'
I think you joined it about 20 minutes after I posted my message.
http://jsoftware.com/pipermail/chat/2014-February/005754.html
and 10 minutes after
http://jsoftware.com/pipermail/chat/2014-February/005755.html
See also: http://jsoftware.com/pipermail/chat/2014-February/date.html
FYI,
--
Rau
Ok. I just joined it. Thanks for the prod.
Raul Miller wrote:
Let's take this to the chat forum... (I'm composing for the chat forum now.)
--
For information about J forums see http://www.jsoftware.com/forums.htm
Let's take this to the chat forum... (I'm composing for the chat forum now.)
Thanks,
--
Raul
On Mon, Feb 24, 2014 at 2:00 PM, PMA wrote:
> I'd love to hear -- putting aside implementation issues, people's aversion
> to the unfamiliar, and what is or isn't ugly -- how the list members would
> e
I'd love to hear -- putting aside implementation issues, people's aversion
to the unfamiliar, and what is or isn't ugly -- how the list members would
expect adoption of APL chars to impact (enhance/ruin/...) J.
Roger Hui wrote:
I love the APL chars as much as the next guy. Some people would arg
I love the APL chars as much as the next guy. Some people would argue that
APL chars are no longer a problem, but recent experience with my Samsung
tablet indicates otherwise.
On Mon, Feb 24, 2014 at 8:27 AM, Raul Miller wrote:
> Maybe I should be doing this in a different forum? It's hard to
Someone could edit the J interpreter such that when you type a
combination of characters, it will replace them with a better, one
character alternative. The question is if people want this to be only
visual or actually change what you've typed in.
On Mon, Feb 24, 2014 at 11:27 AM, Raul Miller wro
Maybe I should be doing this in a different forum? It's hard to
anticipate if or where conversation will go.
Anyways, http://www.johndcook.com/symbols/2014/02/apl/ reminded me to
think about the tradeoffs involved in J's design:
thru=: [ + 1 i.@+ -~
10 thru 20
10 11 12 13 14 15 16 17 18 19
55 matches
Mail list logo
