Thanks, Jürgen!
On Sat, Oct 19, 2019 at 10:50 AM Dr. Jürgen Sauermann <
mail@jürgen-sauermann.de> wrote:
> Hi Blake,
>
> thanks, fixed in *SVN 1192*.
>
> Jürgen
>
>
> On 10/18/19 7:25 PM, Blake McBride wrote:
>
> ∇TEST
> [1] ABC
> [2] DEF
> [3] ⍝ GHI
> [4] JKL
> [5] EN1: MNO
> [6] ∇
>
>
Hi Blake,
thanks, fixed in SVN 1192.
Jürgen
On 10/18/19 7:25 PM, Blake McBride
wrote:
∇TEST
[1] ABC
[2] DEF
[3] ⍝ GHI
[4] JKL
[5] EN1: MNO
[6] ∇
∇TEST
[1] ABC
[2] DEF
[3] ⍝ GHI
[4] JKL
[5] EN1: MNO
[6] ∇
x←⎕CR 'TEST'
x
TEST
ABC
DEF
⍝ GHI
JKL
EN1: MNO
⎕IO
1
x[2;1]←' '
x
TEST
BC
DEF
⍝ GHI
JKL
EN1: MNO
⎕FX x
TEST
∇TEST[⎕]∇
∇
[0] TEST
[1]BC
[2] DEF
[3] ⍝ GHI
[4] JKL
[5] EN1: MNO
Hi,
It was confusing for me as well but it is the right behavior:
http://help.dyalog.com/15.0/Content/Language/Primitive%20Functions/Encode.htm
Br,
/Alexey
2017-03-30 6:25 GMT+02:00 Elias Mårtenson :
> While discussing APL and J on IRC, I discovered a weird behavioural
> difference. Is GNU APL
While discussing APL and J on IRC, I discovered a weird behavioural
difference. Is GNU APL doing the right thing here?
* 10 10 10 ⊤ 125 46 789*
┏→┓
↓1 0 7┃
┃2 4 8┃
┃5 6 9┃
┗━┛
I'd expect to get the result that I'm getting by applying ⍉ to the result,
in other words, I'd expect the fo
Hi Brian,
thanks, #
is fixed in SVN 895. Also updated the ⎕CR and
FILE_IO documentation.
BTW, ⎕FIO ''
says:
...
Legend: a - address family, IPv4 address, port (or
errno)
d - table of dirent
When I dump a workspace with )DUMP_HTML, the string
'' in one of my functions is translated to
'&' but it should translate to
'' (the second semicolon is omitted).
By the way, I have found that when I input a text file
using #FIO[6] I get an integer vector. Applying 19 #CR
#UCS to t
Good to know, and I agree.
Thanks.
Blake
On Sat, Apr 18, 2015 at 7:12 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi Elias,
>
> correct. Unfortunately there seems to be a mismatch between the ISO
> standard on one side,
> and the IBM reference manual and the IBM APL2 inte
Hi Elias,
correct. Unfortunately there seems to be a mismatch between the
ISO standard on one side,
and the IBM reference manual and the IBM APL2 interpreter on the
other.
For example, the formula for 8○ is (¯1-B*2)*.5 in the ISO
stand
According to my documentation that I copied from the ISO spec, 8○ should be
equivalent to: (¯1-R⋆2)⋆0.5 and ¯8○ should be equal to -(¯1-R×2)⋆0.5.
In GNU APL the opposite happens. I.e. ¯8○ returns what 8○ is supposed to
return and vice versa.
Is my analysis correct?
Regards,
Elias
Hi Tobia,
the quick answer is this. Suppose we have:
A / ¨ B.
The the parser does this:
read B (no pattern match)
read ¨ (no pattern match)
read /
At this point we could:
(i) take / to mean (function) comp
Thanks.
I understand that there is a tradeoff involving run-time lookahead. It's
still not entirely clear to me why simple cases would parse correctly, even
with a user-defined symbol as the left argument (A/B) while applying an
operator would break the parser (A/¨B). I'll have to study the parser
Hi Tobia,
I have fixed the special case
{(2|⍵) / ⍵} ⍳3
that you reported, SVN 519.
There remains a handful of border cases related to / ⌿ \ and ⍀
caused by the ambiguity of these symbols
because, for example, functi
Hello
Sorry for opening a new post above, I did not realize this was already
being discussed here.
I'm far from being an APL expert, but I humbly believe the current behavior
to be a bug. Consider this expression, where A and B are arrays (or
scalars):
A F / B
If F is a function, then / s
Hi Elias,
thanks, fixed in SVN 511.
/// Jürgen
On 11/26/2014 04:38 PM, Elias Mårtenson
wrote:
Hello Jürgen and thanks for the explanation.
Based on what you just explained, I would have assum
Hi Jürgen,
Thanks for doing the analysis.
> 2. Alternatives
> -
>
> I have tested what happens if we would introduce a M M pattern into GNU APL
> in order to
> get IBM APL2's behavior.
I don't understand this bit. Monadic operators don't bind like this in APL2.
Surely the w
Hello Jürgen and thanks for the explanation.
Based on what you just explained, I would have assumed the following to
work?
* m (/⍨) 2 = +/[1] 0 = m ∘.| m←⍳N*
LENGTH ERROR
m(/⍨)2=+/[1]0=m∘.|m←⍳N
But this variation works?
* m (/⍨) (2 = +/[1] 0 = m ∘.| m←⍳N)*
2 3 5 7 11 13 17 19 23
Hi again,
I have analyzed this a bit further. Below are my conclusions.
1. Problem description
Elias' initial question can be reduced to this: Given APL values A
and B, say
A←1 2 3 4 5
Hi Jay,
yes, what I meant is that / is called like a dyadic function as in
1 1 1 / 1 2 3.
But handling it always like an operator could be a better solution.
Currently in GNU APL operators are distinguished from functions
which works well
On 25 November 2014 at 14:06, Jay Foad wrote:
> On 25 November 2014 at 13:38, Juergen Sauermann
> wrote:
>> I have read the IBM binding rules a number of times but they seem not to
>> help. The problem of these rules is
>> that they give different results in the cases where / is an operator and
>
On 25 November 2014 at 13:38, Juergen Sauermann
wrote:
> I have read the IBM binding rules a number of times but they seem not to
> help. The problem of these rules is
> that they give different results in the cases where / is an operator and
> where / is a function.
In IBM APL2 / is always an op
Hi Elias,
this is caused by an ambiguity of / (or ⌿, \. or ⍀ for that
matter). These four
APL symbols can, unfortunately, be dyadic functions or monadic
operators.
Your example boils down to this:
A←1 2 3 4 5
Given a typical implementation of prime-finding, the following expression
works fine:
*(2 = +/[1] 0 = m ∘.| m) / m←⍳N*
2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97
However, trying to swap the sides of the selection gives an error message:
*m /⍨ 2 = +/[1] 0 =
Fixed. Thanks!
On Mon, May 26, 2014 at 7:39 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi Blake,
>
> thanks, fixed in SVN 291.
>
> /// Jürgen
>
>
>
> On 05/26/2014 05:51 AM, Blake McBride wrote:
>
>> ∇test[⎕]∇
>> ∇
>> [0] test
>> [1] ⍞←'11 '
>> [2] zz←⍞
Hi Blake,
thanks, fixed in SVN 291.
/// Jürgen
On 05/26/2014 05:51 AM, Blake McBride wrote:
∇test[⎕]∇
∇
[0] test
[1] ⍞←'11 '
[2] zz←⍞
[3] ⍞←'22 '
[4] zz←⍞
∇
test
11
11 22
I just hit Enter at the end of each line.
11 should not be displa
∇test[⎕]∇
∇
[0] test
[1] ⍞←'11 '
[2] zz←⍞
[3] ⍞←'22 '
[4] zz←⍞
∇
test
11
11 22
I just hit Enter at the end of each line.
11 should not be displayed twice.
Blake
Hi Peter,
I believe IBM's APL2 langage reference manual and the ISO standard
describe almost the
same thing in different ways. The ISO standard is a bit more formal
while the IBM docs are
more descriptive. Unfortunately the ISO standard has significant gaps.
most notably the
concept of bindi
Hi Peter,
I wouldn't really bother looking back - I have done a lot of them - ibm
370/tcc/stsc apl*plus/york apl/aplum/sax/aplx/apl2 (no dyalog!!) and this
gnu-apl is going to be cutting edge! Just post any code you have problems with
and people will look at - lots to learn but don't look back
This is a bug in my brain but related to GNU APL.
Last time I used APL was when I worked at IPSA.
The language has been extended since then.
I have the ISO Standard and even the IBM APL2 Language Summary & Programming
Guide.
What can I read for a summary of the differences between the APL I know/
Hi,
thanks for reporting this, fixed in SVN 181.
/// Jürgen
On 03/31/2014 05:59 PM, Kacper Gutowski wrote:
On 2014-03-31 10:15:23, Blake McBride wrote:
I still think there is a small bug, however. Seeing the message 'problem
'Nabla.cc:444' would make anyone think there was an internal probl
On 2014-03-31 10:15:23, Blake McBride wrote:
> I still think there is a small bug, however. Seeing the message 'problem
> 'Nabla.cc:444' would make anyone think there was an internal problem. APL
> had
> a standard message when that type of event occurred. GNU APL should display
> the standard
Thank you for your reply. I was trying to correct a typo when I encountered
the problem. Yes, the problem is that I have a SI. It has been so long, I
forgot about that.
I still think there is a small bug, however. Seeing the message 'problem
'Nabla.cc:444' would make anyone think there was an
On 2014-03-31 15:37:45, Elias Mårtenson wrote:
> Are you sure it's a bug? You seem to be taking the value of "r" when it has no
> value.
I think the problem is that you can't edit a function that is currently
on SI stack, not that Parse erred.
-k
Are you sure it's a bug? You seem to be taking the value of "r" when it has
no value.
Also, I think your "x" should be "×".
Regards,
Elias
On 31 March 2014 13:19, Blake McBride wrote:
> ∇r←c Parse a
> [1] r←(((0≠⍴a)x⍴r),⌈/r)⍴(,r∘.≥⍳⌈/r←¯1+(r,1+⍴a)-0,r←r/⍳⍴a)\(~r←r∈c)/a←,a
> [2] ∇
> ','
∇r←c Parse a
[1] r←(((0≠⍴a)x⍴r),⌈/r)⍴(,r∘.≥⍳⌈/r←¯1+(r,1+⍴a)-0,r←r/⍳⍴a)\(~r←r∈c)/a←,a
[2] ∇
',' Parse 'Hello,there,how are you'
VALUE ERROR
Parse[1]
r←(((0≠⍴a)x⍴r),⌈/r)⍴(,r∘.≥⍳⌈/r←¯1+(r,1+⍴a)-0,r←r/⍳⍴a)\(∼r←r∈c)/a←,a
^
35 matches
Mail list logo
