Re: Niladic functions vs niladic lambdas
On Thu, 8 Jun 2023 at 17:38, Emmanuel Charpentier wrote:
> It seems that niladic lambdas are treated like constants.
>
In GNU APL lambda is dyadic if it contains a reference to ⍺ or monadic if
it uses ⍵. There is no way to distinguish a call of niladic lambda from a
definition of niladic lambda in assignment, so the moment you write
nts←{...} it gets evaluated and nts becomes a regular variable holding its
result rather than a function. Jürgen wanted to depart as little as
possible from normal semantics of defined functions when introducing lambda
notation.
> FWIW, running the same code in a Dyalog APL Jupyter notebook gives similar
> results :
>
(...)
> t2 ← nts
> ⍞←'Spent time : ',⍕(t2-t1)÷1000
>
> In Dyalog, on the other hand, all lambdas are always ambivalent. They can
be called with either one or two arguments regardless of how they are
defined, but there are no niladic lambdas at all. What your code actually
does is calling the function train (t2-t1) with the argument of ÷1000 (t1
and t2 are functions, not values). Both t1 and t2 are evaluated at the same
time here, not when you alias nts to them.
As you can see, it can be confusing either way.
-k
>
Re: output formatting
On Sun, 10 Sept 2023 at 01:08, Stephen Lewis wrote: > Writes elements in 4 row matrix with spurious > extra characters and a blank line. One thing you could do is to increase the print width ⎕PW so that it doesn't wrap, but ultimately this default printout is intended for human consumption. Short of formatting it explicitly and writing it to file, another thing you could try would be to use the quote-quad output: ⍞←2 50⍴⍳100 This is outside of the ISO standard (which only accepts character vectors rather than arbitrary values for quote-quad output) and I'm not sure if it's exactly what you need, but it's a reasonably simple way to send the character representation (in its default form as if by monadic ⍕, with columns still aligned and padded with spaces) to the output without any additional wrapping with indents or blank lines. -k
Re: [Bug-apl] ⎕TZ and ⎕TS
On 2014-01-27 17:26:56, Juergen Sauermann wrote: > should be fixed in SVN 108. It appears to work now, but it will give incorrect results in summer in zones where daylight saving time is used. Maybe something along the lines of difftime(mktime(localtime(…)), mktime(gmtime(…))) would work on all target systems? By the way, are there any idioms making use of that silent failure when ⎕TZ is assigned value outside [¯12, 12]? According to APL2 manual setting ⎕TZ←14 should be a no-op, and so it is in GNU APL. But IBM has choosen to ignore existence of valid timezones outside that range. In fact, currently they get detected correctly but once changed it can't be set back because of this limitation on assignment. $ TZ=Pacific/Kiritimati apl --silent ⎕TZ 14 ⎕TZ←1 ⎕TZ←14 ⎕TZ 1 It works as documented, but is it needed? -k
[Bug-apl] Print width
Hi, After lines are neatly wrapped in r109 in SVN, but I think there's some off by one error; it behaves as if ⎕PW was ⎕PW-1. ⎕PW⍴'X' XXX X -k
Re: [Bug-apl] Print width
On 2014-01-28 14:23:01, Juergen Sauermann wrote: > that was on purpose because the default ⎕PW is 80 and on some > 80 column terminals this causes an extra empty line to be printed. If there are terminals like that, wouldn't it be easier to just initialize ⎕PW to 79 while keeping relation between this value and way wrapping occurs the same as in other systems? It's a bit annoying when you have some pretty-printing functions that read value of ⎕PW to decide how to format output. Anyway, it's not that easy as width being ⎕PW-1. When printing mixed arrays X such that (⎕PW-1)=¯1↑⍴⍕X, i.e. ones that should fill the whole line but not wrap, they sometimes get wrapped too. ⎕PW←30 (⎕PW-1)⍴'X' X 10|⍳⎕PW÷2 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1,(⎕PW-3)⍴'X' 1 XXX 1,⍨(⎕PW-3)⍴'X'⍝ Last element wrapped for no reason? XXX 1 ⍕1,⍨(⎕PW-3)⍴'X' ⍝ See? No reason at all. XXX 1 'X',1,(⎕PW-5)⍴'X' ⍝ ⋆Two⋆ lines printed. X 1 X ⍕'X',1,(⎕PW-5)⍴'X'⍝ Single line as expected. X 1 X Especially take a look at the last example. There is exactly nothing to wrap but additional line still appears. -k
[Bug-apl] Near-real numbers not handled properly
Hi, It seems that functions requiring “near-real numbers” as arguments throw DOMAIN ERROR when given a value represented internally as complex even if imaginary part is exactly equal zero. 1 > 0J0 DOMAIN ERROR 1>0 ^^ 1 ⌊ 0J0 DOMAIN ERROR 1⌊0 ^^ etc. Note: from ISO's definition of near-real one can infer that 0J0 is always near-real regardless of real-tolerance. On the other hand 0J0 is never demoted by GNU APL from complex to real. This isn't relevant to examples above but the problem initially hit me this way: ⌈/(3⍴2)⊤2 DOMAIN ERROR ⌈/(3⍴2)⊤2 ^ ^ -k
Re: [Bug-apl] Strange behaviour of ,/
On 2014-02-01 01:37:23, Elias Mårtenson wrote: > As far as I understand, OP/ is supposed to splice OP in between every element > in the array and return the result. > > Based on this, I would expect that ,/1 2 3 4 and 1,2,3,4 to be equivalent. That's how reduction is informally described, but join isn't a simple scalar function so precise definition matters in this case. > Am I misunderstanding or is GNU APL doing something wrong? Your example gives the same results in other systems as well. If I read the ISO standard correctly, there are two slightly different conforming definitions for reduce and GNU APL uses what they call enclose-reduction-style. It essentially boils down to this: f/1 2 3 4 ←→ ⊂1 f ⊃f/2 3 4 In fact, standard explicitly gives these two examples: (3 8⍴0) ≡,⌿2 3 4⍴0 ⍝Insert-Reduction-Style 1 (3 4⍴⊂0 0) ≡,⌿2 3 4⍴0 ⍝Enclose-Reduction-Style 1 Note that enclose is a no-op for simple scalars so +/1 2 3 4 isn't nested at all (it matches the informal description). -k
Re: [Bug-apl] Print width
As of revision 116, the problems with wrapping mixed arrays whose ⍕ is of ⎕PW width (or ⎕PW-1 before r113) still persist. But there is another issue with wrapping which I think may be related. When displaying nested vector whose elements are vectors, only the first element is treated as expected. All subsequent elements only start a new line when they were to wrap and then continue without wrapping past ⎕PW. ⎕PW←30 ⍴¨⍨,¨5 6 14 5 5 5 5 5 6 6 6 6 6 6 14 14 14 14 14 14 14 14 14 14 14 14 14 14 ⍴¨⍨,¨15 3 4 5 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 3 3 3 4 4 4 4 5 5 5 5 5 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 ⎕PW⍴'=' == -k
[Bug-apl] Errors on SAVE/LOAD with SI not empty
Hi, 1. Trying to )SAVE (or )CONTINUE) while stopped on SYNTAX ERROR, causes segmentation fault: + SYNTAX ERROR + ^ )SAVE FOO SEGMENTATION FAULT -- Stack trace at main.cc:113 0x7f13d18a8995 __libc_start_main 0x434135 main 0x51cabd Workspace::immediate_execution(bool) 0x46153dCommand::process_line() 0x46119f Command::process_line(UCS_string&) 0x51f9c5 Workspace::save_WS(std::ostream&, std::vector >&) 0x440378 XML_Saving_Archive::save() 0x43c30fXML_Saving_Archive::operator<<(StateIndicator const&) 0x7f13d339f210 0x476a7a 2. For every other error, it fails when trying to )LOAD workspace that was saved with non-empty state indicator: ⎕ES'FOO' FOO ⎕ES 'FOO' ^ )SAVE FOO 2014-02-02 22:40:59 (GMT+1) )LOAD FOO == Assertion failed: lev == level in Function: read_SI_entry in file: Archive.cc:1594 Call stack: -- Stack trace at Archive.cc:1594 0x7fde0eb87995 __libc_start_main 0x434135 main 0x51cabd Workspace::immediate_execution(bool) 0x46153dCommand::process_line() 0x460fcd Command::process_line(UCS_string&) 0x51ed29 Workspace::load_WS(std::ostream&, std::vector > const&) 0x44116c XML_Loading_Archive::read_Workspace() 0x43f12dXML_Loading_Archive::read_StateIndicator() 0x43f0b4 XML_Loading_Archive::read_SI_entry(int) 0x44294f do_Assert(char const*, char const*, char const*, int) SI stack: == *** immediate_execution() caught other exception *** On the side note, timestamp displayed on )SAVE and )LOAD is in UTC+0 (sometimes aka GMT) even though local timezone is printed alongside it. And additionally, hours/minutes/second are printed without leading zeros on )LOAD which can yield something like: $ faketime '2015-01-01 02:01' apl --silent )SAVE FOO 2015-01-01 01:01:02 (GMT+1) )LOAD FOO SAVED 2015-1-1 1:1:2 (GMT+1) )OFF -k
Re: [Bug-apl] Strange behaviour of ,/
On 2014-02-04 12:17:16, Elias Mårtenson wrote: > When I look at the result from ,/1 > 2 3 it looks like an array that contains a single element: another array with > the values 1 2 3 in it. But it isn't. Technically you aren't wrong at all, it IS an array that contains a single element. But one-element arrays can come in many shapes. Any array whose shape list consist of only ones is an “array that contains a single element.” For example if ⍴X ←→ 1 1 1 then X contains only single element although it's 3-dimensional (its rank ⍴⍴X is 3). In general, array X contains ×/⍴X elements, and, if ⍴X ←→ ,() then it also has one element (×/⍬ ←→ 1) but it is zero-dimensional (⍴⍴X ←→ 0). As Jay has written, you can't index it because number of indices must match number of axes. > But wait, I can take the first element from it: > > ↑,/1 2 3 > 1 2 3 First takes the first element of array's ravel list which is always a vector (rank 1). In other words, this works as you'd expect: (,,/1 2 3)[1] 1 2 3 Fact that scalars are rank zero arrays may be perplexing at first. It sure was for me; in Matlab, for example, nothing can have rank lower than 2, and therefore “vectors” come in two flavors (row and column) and “scalars” are expressed as 1×1 matrices. APL's approach is more consistent, though. Vector has rank one and scalar's rank is zero. Note that every time you write one element literal, you're creating a scalar not a single element vector: 1 = ⍳1 1 1 ≡ ⍳1 0 1 ≡ ↑⍳1 1 (,1) ≡ ⍳1 1 ⍴⍴1 0 ⍴⍴⍳1 1 ⍴'ab' 2 ⍴⍴'ab' 1 ⍴'a' ⍝ empty result ⍴⍴'a' 0 ⍴,'a' 1 -k
[Bug-apl] Problems with shared variables
Hello, There are multiple problems with shared variables facility. 1. Shared variable protocol is not safe in multi user environment. When user starts apl with shared variables enabled, it removes all other users' sessions from shared database as “stale” so currently even honest user without malicious intent will disrupt all the other users' work if they use shared variables (their programs will fail assertions at Symbol.cc:156 or 695). It happens because users can't kill one another's processes. But please note that trying to work around this won't do any good as there should be no reliable way of determining if other user's process is alive. But I don't think we want variables to be shared between users in the first place (despite of what comment at Svar_DB.cc:678 says). I think that shm name should be suffixed with UID or username and permissions should be set appropriately (0600). If we really need it shared between users, it should not be possible to destroy everything with simple dd if=/dev/urandom of=/dev/shm/apl-svars. I don't know how it was technically done in APL2, but User's Guide mentions some configuration file that described which shares were allowed so presumably there was some control over it. 2. Annoying warnings about missing APs on general offer. 0 ⎕SVO 'X' No binary found for AP 0 (interpreter path = /usr/bin) 1 And also: ⎕SVQ⍬ Could not open /usr/bin/APs : No such file or directory 3. Shared variables not working correctly: • When number of elements on their ravel list exceeds 255, vectors are truncated to their length modulo 256 while higher rank arrays cause errors on reference. 0⎕SVO'X' No binary found for AP 0 (interpreter path = /usr/bin) 1 X←⍳260 X 1 2 3 4 ⍴X 4 X←16 16⍴0 ⍴X 16 16 X DOMAIN ERROR X ^ → 5↑,X == Assertion failed: 0 in Function: init in file: Cell.cc:47 Call stack: -- Stack trace at Cell.cc:47 0x7f83c299c995 __libc_start_main 0x434105 main 0x51caed Workspace::immediate_execution(bool) 0x4613cdCommand::process_line() 0x46032b Command::process_line(UCS_string&) 0x469128 Executable::execute_body() const 0x4dc660 StateIndicator::run() 0x48941aPrefix::reduce_statements() 0x4853e4 Prefix::reduce_MISC_F_B_() 0x4dd33f StateIndicator::eval_B(Token&, Token&) 0x490546 Bif_F12_COMMA::eval_B(Value_P) 0x490388Bif_COMMA::ravel(Shape const&, Value_P) 0x458a11 Cell::init(Cell const&) 0x44293f do_Assert(char const*, char const*, char const*, int) SI stack: Depth:0 Exec: 0x1feb4c0 Pmode:◊ 5↑,X PC: 3 VALUE3«5» Stat: 5↑,X err_code: 0x0 thrown: at StateIndicator.cc:39 e_msg_1: 'No Error' e_msg_2: '' e_msg_3: '' == -- Stack trace at StateIndicator.cc:674 0x7f83c299c995 __libc_start_main 0x434105 main 0x51caed Workspace::immediate_execution(bool) 0x4613cdCommand::process_line() 0x46032b Command::process_line(UCS_string&) 0x469128 Executable::execute_body() const 0x4dc660 StateIndicator::run() 0x48941aPrefix::reduce_statements() 0x4853e4 Prefix::reduce_MISC_F_B_() 0x4dd4aa StateIndicator::eval_B(Token&, Token&) • When array is not simple. X←'abc' 'def' ⍴X 2 X DOMAIN ERROR X ^ X←⊂1 X 0 -k
Re: [Bug-apl] Implementing realtime variable viewer support
On 2014-02-12 12:58:05, Elias Mårtenson wrote: > The key feature that is needed is a way to be informed when a variable is > changed. Shared variables have such feature. Though, it's probably not the right place for you too look in this case, as shared variables are whole separate name class and are handled differently than ordinary variables. But one could even make hackish real-time display without any changes in interpreter by sharing variable in question and then in another terminal doing something along the lines of: ⎕SVO 'SVAR' 0 0 1 0 ⎕SVC 'SVAR' SVAR ⋄ →⎕LC ⍝ print SVAR in a loop every time it's changed Except that 15×35 array is too big to be shared right now... -k
Re: [Bug-apl] Print width
On 2014-02-13 16:47:10, Juergen Sauermann wrote: > Not sure, though, what is wrong with: > > ⎕PW⍴'=' > == Oh, absolutely nothing, it was just a visual aid to show where ⎕PW ends. Sorry for confusion, and thanks for the fixes. -k
Re: [Bug-apl] Unique of nested arrays doesn't work
On 2014-02-14 16:15:33, Juergen Sauermann wrote: > fixed in SVN 120. In r122, it doesn't give domain error anymore, but I think that results are not correct: ⎕RL 1 8⎕CR Y←⊂[1]?2 10⍴2 ┌→──┐ │┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐│ ││2 2│ │2 2│ │2 1│ │1 1│ │2 2│ │1 2│ │1 1│ │2 2│ │1 2│ │1 2││ │└───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘│ └∊──┘ 8⎕CR Z←∪Y ┌→┐ │┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐│ ││2 2│ │2 1│ │1 1│ │2 2│ │1 2│ │1 1│ │1 2││ │└───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘│ └∊┘ 8⎕CR ((Y⍳Y)=⍳⍴Y)/Y←,Y ⍝ ←→ ∪Y ┌→──┐ │┌→──┐ ┌→──┐ ┌→──┐ ┌→──┐│ ││2 2│ │2 1│ │1 1│ │1 2││ │└───┘ └───┘ └───┘ └───┘│ └∊──┘ Z[1] ≡ Z[4] 1 -k
Re: [Bug-apl] Bug when assigning variable to result of function call on self
On 2014-02-20 01:05:16, Elias Mårtenson wrote: > > ∇N disploop S > →(N=0)/0 > next: > S←next S > disp ← '.#'[1+S] > ⎕DL ÷4 > N←N-1 > →next > ∇ In this function, next is 2 (a label) rather than function you defined earlier. So you literally have [3] S←2 S. > By the way, shouldn't S be local to the function disploop? Why is it > visible at all here? It is local, look at your )SI. Here, after an error, you are scoped inside disploop function so you can examine the situation. You can escape using → or )SIC. -k
Re: [Bug-apl] Problems with shared variables
On 2014-02-16 18:09:06, Juergen Sauermann wrote: > Ad 1) I changed the assertions Symbol.cc to short warnings visible in )MORE. I wouldn't guess to check )MORE upon getting VALUE ERROR on shared variable, but I guess it's better than failed assertion. > Ad 3) hopefully fixed. I've mistakenly put example X←1 under this point, but a simple scalar of 1 is changed to 0. This is still broken in r135: 0⎕SVO'X' 1 X←1 X 0 X←2 X 2 > I could further improve the shared variables for workspace-to-workspace > communication, but this is some effort and before doing it I would like to > know if someone is seriously interested in it. The idea would be a > single process > managing all shared variables and TCP rather than UDP for communication with > that process. It appears to work correctly for cooperating users now. Malicious user, however, can still easily destroy other users' coupling of shared variables. I'm not going to push for changing it right now because I don't see any way to exploit it beyond denial of service and I'm not using shared variables for anything serious, but I think that it should be done eventually. -k
Re: [Bug-apl] Problems with shared variables
Hi again, There are still (r148) some problems similar to previously reported. When passing a big array as shared variable, instead of being truncated, now its tail is corrupted: 0⎕SVO'X' 1 X←489⍴2 ¯2↑X 2 ¯1254096894 This suggests some nasty out-of-bounds read. And, if array is even bigger, it gives the following error (after a few seconds): X←3000⍴4 TIMEOUT on signal ASSIGN_VALUE_c VALUE ERROR X←3000⍴4 ^ -k
Re: [Bug-apl] Problems with shared variables
Moreover, integral values in range 1+2⋆31 to (2⋆32)-1 are incorrectly interpreted as their two's complement negative equivalents: 0⎕SVO'X' 1 X←1+2⋆31 X ¯2147483647 -k
Re: [Bug-apl] Rank operator and function assignment
On 2014-03-04 18:53:29, Juergen Sauermann wrote: > They say that f ⍤y is a function which is then called with arguments B and > possibly A. > Thus Z is a value and not a function; the function is created internally. I guess the problem is that GNU APL doesn't really have what most people understand under lambdas even though it supports dfns syntax. Functions are not a first-class values. > The problem with ⍤ is its ambiguity regarding y. > y is expected to be a vector with 1, 2, or 3 elements. Perhaps as a result of the earlier, you can not even disambiguate rank arguments with parentheses this way (this works in other systems): (+⍤1) 2 3 4 5 RANK ERROR (+⍤1)2 3 4 5 ^ ^ By the way, while Elias's example was correctly parsed and interpreted, I think that parsing is not correct: +⍤1 +2 3 4 5 DOMAIN ERROR +⍤1+2 3 4 5 ^^ It is expected to be parsed as +⍤1(+2 3 4 5) and it's not ambiguous at all. I can't find it in the spec right now, but cf. ∘.=⍨ which is (∘.=)⍨ not ∘.(=⍨). Correct me if I'm wrong, but afaiu, operators, unlike functions, should be left associative. Additionally, in A+, but also in Dyalog and NARS as I just checked, there is a monadic ⊢, i.e. an identity function. It is useful exactly for this purpose, as it allows writing: +⍤1⊢2 3 4 5. Monadic ⊢ could also be used to display shy result regardless of type as in ⊢X←anything. It's overall pretty nice consistent extension that I'd be happy to see in GNU APL too. -k
Re: [Bug-apl] Suggestions needed: Editing of named lambdas
On 2014-03-06 10:53:12, Elias Mårtenson wrote:
> ∇λ←avg ⍵
> λ←(+/⍵)÷⍴⍵
>
> This will of course fail when the user tries to save the function.
I'm not using Emacs nor your mode, but why should it fail?
This works:
⎕FX 'λ←avg ⍵' 'λ←(+/⍵)÷⍴⍵'
avg
And so does this:
∇avg
[1] [0]λ←avg ⍵
[1] λ←(+/⍵)÷⍴⍵
[2] ∇
User can not start editing a new function writing ∇λ←avg ⍵, but there
is nothing preventing user from changing this header or making more than
one statement inside a function even if it was initially defined with
dfn syntax (so you can not assume that if it starts with λ then it has
only one statement).
This might not have been intended to work, but it does! :)
avg ← {(+/⍵)÷⍴⍵}
∇avg[⎕]
[0] λ←avg ⍵
[1] λ←(+/⍵)÷⍴⍵
[2] [0] λ←avg ⍵;z
[1] z←+/⍵
[2] λ←z÷⍴⍵
[3] ∇
⎕CR'avg'
λ←avg ⍵;z
z←+/⍵
λ←z÷⍴⍵
-k
Re: [Bug-apl] Rank operator and function assignment
On 2014-03-09 13:36:11, Juergen Sauermann wrote:
> Not sure though how this is related to how the rank operator is computed.
Related to how it is parsed, because in NARS2000 there is no difference
for operator's syntax whether its operands are functions or some other
values. Functions might not be a first-class values, but in some places
they are not distinguished from other values.
> This rank error is thrown because +⍤1 is a valid phrase and is
> reduced first, like in:
In NARS2000, +⍤1 is not a complete statement; when typed alone it will give
a syntax error because it's a function without an argument. It's equivalent
to {+⍤1⍵} (or {⍺+⍤1⍵} when used dyadically):
F←+⍤1 ◊ F 2 3 4 5 ←→ +⍤1 (2 3 4 5) ←→ (+⍤1) 2 3 4 5
> This raises the question if we should allow an operator like ⍤ to
> change the syntax of the language
> in order to work. To achieve the desired effect of binding 1 to +⍤
> we would then need to handle
> 'fun op B' in one way if op is ⍤ and in another way if not. even
> though that is implementable,
> i am hesitant to do it because IMHO it obscures the syntax of the language.
The change is not to treat ⍤ in any special way, it's to allow a vector
to be an argument of operator. These forms are syntactically parallel:
4∘.=+3 4 5 ←→ 4 ∘.= (+3 4 5)
4+⍤1+3 4 5 ←→ 4 +⍤1 (+3 4 5) ⍝ currently not true in GNU APL
“1” and “=” are syntactically in the same place in this example. The
only difference is that the right operand of ∘.f is a function and f⍤y
takes a vector.
I'm not entirely sure this is a good change to make in GNU APL, but
existence of ⍤ operator mandates it.
Rank is a strange operator that takes a vector as right operand rather than
a function. This by itself changes syntax of the language. But in NARS2000
and Dyalog (Dyalog has e.g. ⍣ that also can take number as operand) it simply
follows the same consistent rules that apply to functional arguments of all
the other operators.
In NARS2000 and Dyalog APL, I can do this:
∇Y←A (f FF g) B
[1] Y←A f g B
[2] ∇
3 +FF- 5
¯2
3 (+FF 5) 6 ⍝ sic, g←5
8 9
3 +FF 5 +6
8 9
3 (4 FF 5) 6
3 4 5 6
> > +⍤1 +2 3 4 5
(…)
> >It is expected to be parsed as +⍤1(+2 3 4 5) and it's not ambiguous at all.
> >I can't find it in the spec right now, but cf. ∘.=⍨ which is (∘.=)⍨ not
> >∘.(=⍨).
> >Correct me if I'm wrong, but afaiu, operators, unlike functions, should be
> >left associative.
> It is actually parsed as +⍤(1 +2 3 4 5) which becomes +⍤3 4 5 6
Yes, exactly, I see what happened. That's why I gave the example of
∘.=⍨ to show that operators should not take everything to the right as
their right operand. The interpretation of +⍤(1+2 3 4 5) would be
expected iff ⍤ were a function rather than operator (it would be used
monadically in this example) or monadic operator without right argument
at all (which is the case but I didn't know that before).
> Generally speaking, GNU APL computes the rank operator like this:
In other words, in GNU APL:
+⍤1 (2 3 4) ←→ +⍤ (1,⊂2 3 4)
This explains a lot. I thought that ⍤ is a dyadic operator with right
operand being vector, because that is how other systems treat it. But
GNU APL, instead of allowing right operand to be numeric, makes ⍤ a
monadic operator that treats right argument of the derived function in
unusual way.
That's a clever hack around the syntax that allows only functions as
arguments of operators.
-k
Re: [Bug-apl] "Largest integer" isnt' really largest?
On 2014-03-11 17:29:08, Frederick H. Pitts wrote:
> If one executes
>
> i ← 0
> 63 1 ⍴ { ⍵ , i ← ¯1 + 2 × i + 1 }¨ 1 + ⍳ 63
>
> one should get a 2-column table of bit count and corresponding maximum
> positive representable integer (assuming high order bit is a sign bit).
> The maximum integer should be odd. Running the above on GnuAPL (as well
> as ngnAPL), reveals that maximum integer goes even at bit count 55. It
> is strange that two independent implementations of APL have the same
> bug.
It isn't really that strange. In case of ngn, which uses underlaying
Number type of javascript, this isn't a bug at all. It's the correct
and expected result. Also note that in ngn it doesn't go negative at
any point.
At count of 54 your number i equals (2⋆53)-1 which is the maximal odd
integer encodable with 53-bit mantissa of double precision floats.
The only type available in javascript is double so in ngn-apl this is
the way it should be and the only way around it is to use some kind of
arbitrary precision arithmetic.
GNU APL, however, uses both doubles and 64-bit integers interchangeably
so as long it is an integer, it should be possible to have odd numbers
up to 2⋆63 as indicated in ⎕SYL. Apparently there are some problems
with choice of representation or conversions. Well, it is a bug.
I believe that expected result of your code is to have odd integers up
to the count of 63 where right column should be 4611686018427387903
(i.e. (2⋆62)-1) BUT followed by 9223372036854775808 at the count of 64,
because intermediate value (after multiplication and before adding ¯1)
is bigger than (2⋆63)-1 and therefore must be converted to double.
-k
Re: [Bug-apl] Scan operator has strange behaviour
On 2014-03-19 23:16:32, Elias Mårtenson wrote: > I see. So the way I see it, I should actually use 2 OP/X instead? I seems to > actually do what I expected. It if does what you need then sure, but it's a very different thing than scan: ,\'abcd' a ab abc abcd 2,/'abcd' ab bc cd -k
Re: [Bug-apl] How to zero every other 1 in a sequence
On 2014-03-21 00:23:41, Elias Mårtenson wrote: > One of my experiments was very short, and tantalisingly close to correct: > > ≠\V > > Unfortunately, it's not quite right. Does anyone have an idea how to coerce > that one into being right? I couldn't come up with anything better, but if you don't mind having a separate statement with assignment in place you could do something like: (V/V)←∊≠\¨V⊂V -k
Re: [Bug-apl] Finally turned javascript version to a true REPL interpreter
On 2014-03-30 20:50:31, baruc...@gmx.com wrote: > At first glance, it seems to work: http://baruchel.hd.free.fr/apps/apl/i/ > You can know use it as an online interpreter. I will add some colors/themes > in the days to come, but the most difficult part is done. Great work! It's really nice to have usable interpreter without installing anything. And thanks to being compiled to javascript (and thus reusing browser's sandboxing) it's much better than, say, Dyalog's TryAPL where a bunch of features were disabled (e.g. no ⍎). Things like this work :) ⍎s←'''⍎s←'',q,((1+q=s)/s),q←⎕UCS 39' However, entering nabla editor still falls back to using prompt boxes like in earlier version. -k
Re: [Bug-apl] Bug in function editing
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
Re: [Bug-apl] Finally turned javascript version to a true REPL interpreter
On 2014-03-31 15:40:06, Elias Mårtenson wrote: > The Nable editor should (in my opinion) open a separate editor just like the > Emacs mode does. :-) That's one way to do things. But wouldn't it be nicer to just use something like )EDIT rather than hijacking ∇ for that purpose? I actually hated the feature in NARS2000 because it prevents from simply pasting a function to a session. -k
Re: [Bug-apl] Bug in function editing
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 error message when that type of user error occurred. This type > of > error can sometimes occur even by an experienced APL programmer (as I was). > If > the system displayed a message that looked more like user error, it would > help. > You could just look at the error message that the other APL's display (since > I > don't remember what the normal response was to that user error). I agree, and most importantly I think Jürgen will also agree, that this behaviour is not correct. >From what I see in the source, )SI stack is checked and useful message “function could not be edited, since it is used on the )SI stack.” is initially written to the )MORE buffer but then it's lost when Nabla::throw_edit_error() displays “DEFN ERROR” (without “+”) and overwrites )MORE message with “Nabla.cc:444”. The part where it prints “bad editor command” before “DEFN ERROR” seems to be just a leftover after some debugging hack as it essentially will give the line in source where error was encountered while parsing ∇-line. For most of user errors, a caret showing location in input where error occurred should be enough, and others (like this one) should be described with )MORE. -k
Re: [Bug-apl] is there a )copy ⎕fns like ⎕ex is )erase
On 2014-04-26 12:08:14, Juergen Sauermann wrote: > I could make the ∇-editor aware that a )COPY is in progress and that > functions shall be deleted automatically by the ∇-editor. I like a lot that there is now a command that sources another file raw, much like "." in shell or "#include" in cpp. It's all that is needed to make more complex programs/libraries in forms of UNIX-ish-style scripts without relying on (hardly readable) workspace files. With this mindset I find any changes to behaviour highly unexpected and I would probably report them as a bugs (unless properly documented as an actual features, of course). It might not be a problem in case of ∇, but for updating already defined function it's an overkill as it can be easily done explicitly by programmer like that: ∇mean[0] R←mean B R←(+/B)÷⍴B ∇ This can be )COPY-ied many times without any problems as it enters the editor with a name only and then explicitly rewrites header line at [0]. As for implementing )EDIT-like routine, in other systems it launches editor with a function body only, not ∇-editor commands. So I think it might be a good idea to dump function's ⎕CR to a temporary file and then launch external editor on it. When done editing, read it back, split by lines, and simply pass it to ⎕FX. Maybe also ⎕EX FN when ⎕FX returns success with a different name, and)COPY/)DUMP to destination file as appropriate. The only drawback is that vi line numbers have 1-origin and this can't be changed to zero. And I'm not yet sure how to efficiently slurp UTF-8 file as characters. If I'm not mistaken, there isn't anything in lib_file_io to help and it might require parsing UTF-8 in APL at the moment. Alternatively, one could automatically wrap modified function from file with #!apl and ∇name[0] … ∇ header and then )COPY it in, but that would be ugly. On 2014-04-26 03:08:59, enztec wrote: > fp←'r' FILE_IO[24] 'vi workspaces/',fn,' < `tty` > `tty`' I guess, YMMV on other systems, but in my environment (linux) it suffices to do '> /dev/tty', there is no point in running additional command just to get current tty, and input redirection is superfluous when doing popen 'r'. -k
[Bug-apl] Return value of fgets ignored in lib_file_io. (Was: Re: is there a )copy ⎕fns like ⎕ex is )erase)
On 2014-04-26 07:13:21, enz...@gmx.com wrote: > btw if you can take a look at the FILE_IO code in > http://lists.gnu.org/archive/html/bug-apl/2014-04/msg00269.html > and give me an idea why the difference between c popen and apl popen - null > vs no '10' at end of data still returned - i'd appreciate it The difference is that there is a bug in lib_file_io. When FILE_IO[8] is called dyadically, return value of fgets(3) is silently ignored and garbage is returned. -k Index: src/native/file_io.cc === --- src/native/file_io.cc (revision 224) +++ src/native/file_io.cc (working copy) @@ -796,7 +796,7 @@ buffer = del = new char[bytes + 1]; const char * s = fgets(buffer, bytes, fe.fe_file); -const int len = strlen(buffer); +const int len = s ? strlen(s) : 0; Value_P Z(new Value(len, LOC)); new (&Z->get_ravel(0)) IntCell(0); // prototype loop(z, len) new (&Z->get_ravel(z)) IntCell(buffer[z] & 0xFF);
Re: [Bug-apl] is there a )copy ⎕fns like ⎕ex is )erase
On 2014-04-26 21:15:43, Elias Mårtenson wrote: > On 26 April 2014 20:52, Kacper Gutowski wrote: >> ∇mean[0] >> R←mean B >> R←(+/B)÷⍴B >> ∇ >> >> This can be )COPY-ied many times without any problems as it enters the >> editor with a name only and then explicitly rewrites header line at [0]. > > I don't like this at all. I want my APL source files to define functions as > such: > > ∇Z←foo X > Z←X+1 > ∇ > > I would also like to be able to reload the source files fully after making > major changes (a simple change can be pushed by simply pressing C-c C-c on it > of course). This means that I don't want to have any unexpected behaviour when > doing so. I agree this is much better when you consider legibility. My “solution” is indeed terrible and, in fact, doesn't even work correctly because it would fail to delete ending lines if new definition were shorter than old one. But still, I don't like the idea of doing things differently because this means that it no longer has the semantics of reading and executing files as scripts, but rather it is a fancy format for workspace. It's undeniably useful, but distinct from what I expected. But in the end, like I've written, in case of ∇ it may not be a problem. I don't like it, but I don't really see how could it get in the way. In fact, redefining functions from scratch is closer to what you would expect from usual scripting language (but I'm not going to postulate removal of ∇-editor altogether). -k
Re: [Bug-apl] Need xkb U code for two APL characters
On 2014-04-27 11:54:09, enz...@gmx.com wrote: > I have never seen or used the symbol ∵ called 'because' U2235 before - and > it is not in the supplied apl.xmodmap > perfect place left open for it is on vV∪∵shift-alt-v ? > btw what does it do - is it a type of 'apl exception' :) I'm also curious about it, I have never seen it used or mentioned in any reference. I only saw it on some photos of keyboards and images of keyboard layouts. For example, APLX page [1] shows such layout, but I couldn't find any use of it in APLX reference. A+ [2], which is a separate language, derived from APL but not compatible, uses it as bitwise operator that makes logical functions bitwise: 4≠2 1 4≠∵2 6 [1] http://www.microapl.co.uk/apl_help/ch_000_030.htm [2] http://www.aplusdev.org/ -k
Re: [Bug-apl] Correct use of ⍤
On 2014-05-04 22:21:48, Elias Mårtenson wrote: > I was reading the following thread on comp.lang.apl: > https://groups.google.com/ > d/msg/comp.lang.apl/ZmdHbyqSM4M/522hE9rDRTkJ > > In it, it is suggested that the following statement will work: > > (3 3⍴⍳9)×⍤1 ⍳3 > > However, GNU APL gives RANK ERROR here. Is that correct? It was discussed here earlier. GNU APL doesn't have syntax for non-functional right operand, instead ⍤ is monadic (f⍤) and right argument of derived function is treated in peculiar way that in some cases will make it look as elsewhere but it others will give confusing rank error. In GNU APL you have to write: (3 3⍴⍳9)×⍤1 (⍳3) -k
[Bug-apl] Segfault in PrintBuffer
Apparently, when array contains a big number that is to be displayed in exponential notation, the whole column containing it is printed with exponent. If array of mixed type has char and such big number in the same column, PrintBuffer segfaults on it: +X←?2 3 3⍴100 40 18 54 19 66 55 55 60 37 29 40 52 63 71 28 22 91 2 X[2;2;2]←1e10 ◊ X 40 1.8E1 54 19 6.6E1 55 55 6.0E1 37 29 4.0E1 52 63 1.0E10 28 22 9.1E1 2 X[1;1;1]←'a' ◊ X a 1.8E1 54 19 6.6E1 55 55 6.0E1 37 29 4.0E1 52 63 1.0E10 28 22 9.1E1 2 X[1;1;2]←'b' ◊ X get_height():'7' at PrintBuffer.cc:336 w=9* w=12* w=12* w=9* w=12* w=12* w=12* *ab54* *196.6E155* *556.0E137* ** *294.0E152* *631.0E1028* *229.1E12* == Assertion failed: is_rectangular() in Function: PrintBuffer in file: PrintBuffer.cc:341 Call stack: -- Stack trace at PrintBuffer.cc:341 0x7fa0206ffb45 __libc_start_main 0x435855 main 0x5291ed Workspace::immediate_execution(bool) 0x464f6dCommand::process_line() 0x463da3 Command::process_line(UCS_string&) 0x46e418 Executable::execute_body() const 0x4e37c0 StateIndicator::run() 0x49107aPrefix::reduce_statements() 0x48f6a0 Prefix::reduce_END_B__() 0x4e6d30 StateIndicator::statement_result(Token&) 0x525ecb Value::print(std::ostream&) const 0x4b498dPrintBuffer::PrintBuffer(Value const&, PrintContext const&) 0x4439af do_Assert(char const*, char const*, char const*, int) SI stack: Depth:0 Exec: 0xfb9d70 Pmode:◊ X[1;1;2]←'b' ◊ X PC: 13 RETURN_STATS Stat: X err_code: 0x0 thrown: at StateIndicator.cc:41 e_msg_1: 'No Error' e_msg_2: '' e_msg_3: '' == SEGMENTATION FAULT -- Stack trace at main.cc:122 0x7fa0206ffb45 __libc_start_main 0x435855 main 0x5291ed Workspace::immediate_execution(bool) 0x464f6dCommand::process_line() 0x463da3 Command::process_line(UCS_string&) 0x46e418 Executable::execute_body() const 0x4e37c0 StateIndicator::run() 0x49107aPrefix::reduce_statements() 0x48f6a0 Prefix::reduce_END_B__() 0x4e6d30 StateIndicator::statement_result(Token&) 0x525ecb Value::print(std::ostream&) const 0x4b498dPrintBuffer::PrintBuffer(Value const&, PrintContext const&) 0x443957 do_Assert(char const*, char const*, char const*, int) 0x500cbc TestFiles::assert_error() 0x7fa022656890 0x47dfda -k
[Bug-apl] Segfault in outer product with empty argument
Outer product of any function with empty left or right argument, results in segmentation fault: 'abc' ∘.= '' SEGMENTATION FAULT -- Stack trace at main.cc:122 0x7f90f668cb45 __libc_start_main 0x435995 main 0x529edd Workspace::immediate_execution(bool) 0x4651cdCommand::process_line() 0x463edd Command::process_line(UCS_string&) 0x46e678 Executable::execute_body() const 0x4e4370 StateIndicator::run() 0x4912caPrefix::reduce_statements() 0x48e293 Prefix::reduce_A_F_B_() 0x4e514a StateIndicator::eval_AB(Token&, Token&, Token&) 0x476173 DerivedFunction::eval_AB(Value_P, Value_P) 0x44df1dBif_OPER2_PRODUCT::eval_ALRB(Value_P, Token&, Token&, Value_P) 0x44b4ad Bif_OPER2_PRODUCT::outer_product(Value_P, Token&, Value_P) 0x44ad8a Bif_OPER2_PRODUCT::finish_outer_product(EOC_arg&) 0x45b9a4 Cell::init_from_value(Value_P, char const*) 0x45b7e9Cell::init(Cell const&) 0x7f90f85e3890 0x47e22a -k
[Bug-apl] Assertion failure in scalar function with empty right argument
Thanks for previous two. Is it expected, by the way, that assert ends in a segfault? Isn't this also a bug? Anyway, any scalar function given empty right argument and non-conforming non-empty left argument misses check for shape equality: ⍬ = 1 2 LENGTH ERROR ⍬=1 2 ^^ → 1 2 = ⍬ == Assertion failed: A->same_shape(*B) in Function: eval_fill_AB in file: SkalarFunction.cc:318 Call stack: -- Stack trace at SkalarFunction.cc:318 0x7fd11cda6b45 __libc_start_main 0x435995 main 0x529e6d Workspace::immediate_execution(bool) 0x4651cdCommand::process_line() 0x463f99 Command::process_line(UCS_string&) 0x46e678 Executable::execute_body() const 0x4e4390 StateIndicator::run() 0x49133aPrefix::reduce_statements() 0x48e293 Prefix::reduce_A_F_B_() 0x4e516a StateIndicator::eval_AB(Token&, Token&, Token&) 0x4df198 Bif_F2_EQUAL::eval_AB(Value_P, Value_P) 0x4dabcdSkalarFunction::eval_skalar_AB(Value_P, Value_P, ErrorCode (Cell::*)(Cell*, Cell const*) const) 0x4d8db4 SkalarFunction::eval_fill_AB(Value_P, Value_P) 0x443abf do_Assert(char const*, char const*, char const*, int) SI stack: Depth:0 Exec: 0x1399920 Safe ex: no Pmode:◊ 1 2 = ⍬ PC: 3 ENDL Stat: 1 2 = ⍬ err_code: 0x0 thrown: at StateIndicator.cc:41 e_msg_1: 'No Error' e_msg_2: '' e_msg_3: '' == SEGMENTATION FAULT -- Stack trace at main.cc:122 0x7fd11cda6b45 __libc_start_main 0x435995 main 0x529e6d Workspace::immediate_execution(bool) 0x4651cdCommand::process_line() 0x463f99 Command::process_line(UCS_string&) 0x46e678 Executable::execute_body() const 0x4e4390 StateIndicator::run() 0x49133aPrefix::reduce_statements() 0x48e293 Prefix::reduce_A_F_B_() 0x4e516a StateIndicator::eval_AB(Token&, Token&, Token&) 0x4df198 Bif_F2_EQUAL::eval_AB(Value_P, Value_P) 0x4dabcdSkalarFunction::eval_skalar_AB(Value_P, Value_P, ErrorCode (Cell::*)(Cell*, Cell const*) const) 0x4d8db4 SkalarFunction::eval_fill_AB(Value_P, Value_P) 0x443a67 do_Assert(char const*, char const*, char const*, int) 0x501acc TestFiles::assert_error() 0x7fd11ecfd890 0x47e22a -k
[Bug-apl] Assertion failure after reduction of empty array
Another one. Reduction of an empty array along the last non-singleton AND non-zero axis produces a weird value which crashes GNU APL when copied (e.g. when assigned to variable; nothing happens when it's simply printed or directly examined with rank/depth/whatever): X ← +/[3] 0 0 2 0⍴ 0 == Assertion failed: 0 in Function: init in file: Cell.cc:48 Call stack: -- Stack trace at Cell.cc:48 0x7f06b6b2db45 __libc_start_main 0x435995 main 0x529e3d Workspace::immediate_execution(bool) 0x4651cdCommand::process_line() 0x463f99 Command::process_line(UCS_string&) 0x46e678 Executable::execute_body() const 0x4e4360 StateIndicator::run() 0x49133aPrefix::reduce_statements() 0x48d46e Prefix::reduce_V_ASS_B_() 0x4f4a16 Symbol::assign(Value_P, char const*) 0x52652b Value::clone(char const*) const 0x45b7c1Cell::init(Cell const&) 0x443abf do_Assert(char const*, char const*, char const*, int) SI stack: Depth:0 Exec: 0x2105be0 Safe ex: no Pmode:◊ X ← +/[3] 0 0 2 0⍴ 0 PC: 10 ENDL Stat: X ← +/[3] 0 0 2 0⍴ 0 err_code: 0x0 thrown: at StateIndicator.cc:41 e_msg_1: 'No Error' e_msg_2: '' e_msg_3: '' == SEGMENTATION FAULT -- Stack trace at main.cc:122 0x7f06b6b2db45 __libc_start_main 0x435995 main 0x529e3d Workspace::immediate_execution(bool) 0x4651cdCommand::process_line() 0x463f99 Command::process_line(UCS_string&) 0x46e678 Executable::execute_body() const 0x4e4360 StateIndicator::run() 0x49133aPrefix::reduce_statements() 0x48d46e Prefix::reduce_V_ASS_B_() 0x4f4a16 Symbol::assign(Value_P, char const*) 0x52652b Value::clone(char const*) const 0x45b7c1Cell::init(Cell const&) 0x443a67 do_Assert(char const*, char const*, char const*, int) 0x501a9c TestFiles::assert_error() 0x7f06b8a84890 0x47e22a -k
[Bug-apl] Segmentation fault in zero take on scalar
0↑0 SEGMENTATION FAULT -- Stack trace at main.cc:122 0x7f81f5e43b45 __libc_start_main 0x4359b5 main 0x52a66d Workspace::immediate_execution(bool) 0x46520dCommand::process_line() 0x463fb9 Command::process_line(UCS_string&) 0x46eb18 Executable::execute_body() const 0x4e4830 StateIndicator::run() 0x4917daPrefix::reduce_statements() 0x48e733 Prefix::reduce_A_F_B_() 0x4e568a StateIndicator::eval_AB(Token&, Token&, Token&) 0x4a01f0 Bif_F12_TAKE::eval_AB(Value_P, Value_P) 0x45b8a9Cell::init(Cell const&) 0x7f81f7d9a890 0x47e6ca
Re: [Bug-apl] Restrictions on localization of system variables?
On 2014-05-27 18:06:06, Juergen Sauermann wrote: > Note that there are some subtle differences between IBM APL2 and GNU APL > when localizing ⎕-vars. In IBM APL2 they are undefined after localizing > them. > In GNU APL they are pre-initialized with their respective default values. > This > gives simpler (and therefore faster code) because no check for validity is > needed > for the variables themselves, but also for the many internal users of them. This indeed makes things simpler and I like the idea, but APL2's behavior is mandated by ISO 13751 which at the beginning of chapter 12 says: > Note: When a system-variable-symbol is localised the initial class of > its associated system-parameter is nil. If a primitive operation is > invoked that requires a system parameter whose class is currently nil, > the primitive operation signals implicit-error. Therefore, a > conforming-program that localises system-variable-symbols should > assign them values from their internal-value-set before calling > primitive operations that require them. -k
[Bug-apl] Assertion failure in index with axis on vector
Hi, Using index with axis on a vector results in assertion failure. It works correctly with arrays of higher dimension or without axis. 1⌷[⎕IO]⍳1 == Assertion failed: IX.value_count() != 1 in Function: index in file: Value.cc:1063 Call stack: -- Stack trace at Value.cc:1063 0x7fc38ee5ab45 __libc_start_main 0x4358f5 main 0x52a46d Workspace::immediate_execution(bool) 0x46d5cdCommand::process_line() 0x46c379 Command::process_line(UCS_string&) 0x4767a8 Executable::execute_body() const 0x4e6630 StateIndicator::run() 0x49b05aPrefix::reduce_statements() 0x497bbe Prefix::reduce_A_F_C_B() 0x4e7a3c StateIndicator::eval_AXB(Token&, Token&, Token&, Token&) 0x4a0c65 Bif_F2_INDEX::eval_AXB(Value_P, Value_P, Value_P) 0x523d46Value::index(IndexExpr const&) const 0x44365f do_Assert(char const*, char const*, char const*, int) SI stack: Depth:0 Exec: 0x960830 Safe ex: no Pmode:◊ 1⌷[⎕IO]⍳1 PC: 7 ENDL Stat: 1⌷[⎕IO]⍳1 err_code: 0x0 thrown: at StateIndicator.cc:41 e_msg_1: 'No Error' e_msg_2: '' e_msg_3: '' == -k
Re: [Bug-apl] Package Manager installation issues and proposal - feedback requested
On 2014-06-05 22:39:52, Elias Mårtenson wrote: > May I also ask that after reading the main config file, the interpreter also > reads $HOME/.gnu-apl.d for load user-level configuration. And finally, it > should also check the commandline so that the paths can be overridden on a > session-basis. Doesn't it already read $HOME/.gnu-apl/ (without .d)? Though, I would prefer this to be put under $HOME/.config/gnu-apl/ and to be configurable through environment (in addition to command line arguments). -k
Re: [Bug-apl] Strange domain error
On 2014-06-10 14:08:47, Blake McBride wrote: > It is funny because I call this function a lot. Sometimes it works, other > times it gives me the domain error. Here are some more facts: > > DOMAIN ERROR > Tmfmt[1] z←(2 0⍕⍉d[,1;]),':',2 0⍕⍉(d←(2⍴100)⊤,d)[,2;] > ^ ^ > d > 2 > 0 I think I know what the problem might be. To confirm, run 2⎕TF'd' which should show you what the values *really* are. I suspect that d contains a complex zero 0J0. When result of encode ⊤ contains zero, sometimes it's returned internally represented as a complex number instead of real. I discovered this in January [1], but concluded that this should not be a problem because for real arguments it will return near-reals anyway (AFAIK the standard doesn't say they can not be complex), and near-reals are for all intents and purposes indistinguishable from reals; therefore I reported it as problem with functions requiring near-reals rather than with encode. It has been fixed in SVN 117 and worked for what I tested. Now, as for dyadic format A⍕B, ISO 13751 contradicts itself (or maybe is just underspecified). First, it contains a note saying that “for complex elements of B, the precision specifier applies to each part of the representation.” And then it gives an evaluation sequence which explicitly states that “if any item of the ravel-list of B is not a real-number, signal domain-error.” Note, that it says “real-number,” not “near-real number.” It seems that behavior of GNU APL matches the evaluation sequence as given by the standard. I'm not sure, whether it should be resolved by changing ⊤ never to return complex numbers for real arguments, or by making ⍕ accept it somehow. Perhaps both. -k [1] https://lists.gnu.org/archive/html/bug-apl/2014-01/msg00116.html
Re: [Bug-apl] Identify function
On 2014-07-02 14:36:37, Juergen Sauermann wrote: > I have added monadic ⊣ and ⊢ see SVN 355. > > Instead of making them identical I though it might be better to do > different things. What I came up with is this: > > ⊢ B returns (a copy of) B as a normal APL value. > ⊣ B also returns a copy of B, but as a committed APL value. It IMO makes a lot more sense than having two primitives doing exactly the same thing. It's also a bit similar to A+ usage where monadic forms are both equivalent to having () as left argument (and where () doesn't produce any output). There is also another use I mentioned earlier when we were discussing rank operator — disambiguating right operand and right argument of derived function. I just compiled SVN 355, and, lo and behold: +⍤1⊢2 3 4 5 2 3 4 5 This actually works in GNU APL now! Thanks. -k
Re: [Bug-apl] Extension proposal: ⍵⍵ to access outer lambda
On 2014-07-09 16:14:32, Juergen Sauermann wrote:
> Hi,
>
> actually - no. I called it OUTER_OMEGA to make clear what it does.
> Maybe you like
>
> { ⍵ + {⍵×WW} 10 ⊣ WW←⍵ } 100
> 1100
>
> imore?
I think the main problem isn't the length of variable's name but the
fact that regular variable is neither lexically scoped nor localized.
Using ⍵⍵ might be confusing for Dyalog users where ⍺⍺ and ⍵⍵ are used
as functional arguments of dfn operators. But since GNU APL uses ⍶
and ⍹ for those and it doesn't localize variables in dfns, using
repeated ⍺/⍵ for nested arguments doesn't sound that bad.
-k
Re: [Bug-apl] Error building on OSX
On 2014-07-08 18:03:21, Juergen Sauermann wrote: > SOL_SOCKET is 1 on linux but according to the man page of TCP(7) SOL_TCP (=6) > should be used. > I have changed the code to use he number 6 instead of SOL_TCP. SVN 368. Acctually, it should be IPPROTO_TCP as both mandated by POSIX and described in tcp(7). Sic; maybe you have outdated manuals? See http://man7.org/linux/man-pages/man7/tcp.7.html for latest version. -k
Re: [Bug-apl] Formal format for function documentation
On 2014-07-14 00:01:13, Elias Mårtenson wrote: > Most modern (and some not-so-modern) languages have a standard way of > attaching > documentation to functions and other symbols. (...) I think the most natural way to describe a function is simply by starting function *body* with a comment: ∇ Z←add1 X ⍝ Add one to the right-hand argument. Z←X+1 ∇ I can't point to any examples right now, but I think I saw this style being used somewhere before. Unlike using a comment *before* definition (Javadoc style), comment inside is actually a part of a function and can be easily extracted from ⎕CR if needed. Something like: ⊃(1,∧\'⍝'=↑¨1↓C)/C←⊂[⎕IO+1]⎕CR'add1' I think that assumption that first comment *on the start of line* documents a function is good enough, but you could also require additional marker like in Javadoc (perhaps '⍝⍝'?) if you like. Using a string makes a lot of sense in Lisp because you can manipulate function's definition directly (code is data). In APL you have no such advantage, you need to parse it out yourself anyway, and you have to additionally supersede its printing using right/left tack or assignment. To me, this seems pointless and more complicated. Except, of course, for dfns where you can't write a comment. But given that dfns in GNU APL can only have single statement, I don't think that's a big problem as you probably wouldn't write any functions that need to be documented as dfns. Using discarded string in dnfs would only result in unnecessarily long lines which, I think, would only make things harder to read, thus worse. -k
Re: [Bug-apl] ⎕ES wrong message
On 2014-07-14 16:15:32, Juergen Sauermann wrote: > Since ⎕ES is not ISO-standard anyhow, I take the freedom to trade performance > for APL2 compatibility. But it is. See sections 11.5.7 and 11.6.5. And standard says it should return nil for empty right argument, which means not returning any value at all. -k
Re: [Bug-apl] ⎕ES wrong message
Whoops, this thread was about the message rather than return value. About that, standard states that event-message is local to a context and that ⎕ES should create an exception in caller's context, but I don't think it's properly specified what does it exactly mean. But the point is, that ⎕ES _is_ a part of the standard, not just APL2. Anyway, regarding the result. On 2014-07-14 10:09:02, Blake McBride wrote: > That "return nil" is clearly a typo and a further reflection of the poor > quality of that spec. Admittedly standard is hard to read and underspecified in many places but this is not the case here. Look at 5.3.4.1: >> – Result: A metaclass containing *nil* and the members of *exception* >> and *value*. Actually "return nil" is not a typo, but *nil* is not a *value*. Every function that terminates returns _something_ in standard's parlance — be it a value or an exception, or just nil — but it has a result. Returning nil is having the same result as that of a defined function whose header doesn't start with Z←, i.e. without return value. > I offer the following as proof that that comment is a > typo: > > 1. Look at the signature of ⎕ES at the beginning of 11.5.7. It says: > > ⎕ES B > > it does not say: > > Z←⎕ES B > > like they do everywhere else when a quad function returns something. Form Z←Something is consistently used when Something returns a value. But ⎕ES never returns any *value* according to the standard so it would be incorrect to write Z←⎕ES B. In fact, it should result in value error. > 2. In IBM APL 2 ⎕ES never returns a value. > > 3. Having ⎕ES return a value did cause me an unnecessary problem. Yes, and the standard is on your and APL2's side here. No value shall be returned, result shall be nil. > > Where they day "return nil", they should have said "return". Look at 5.4.1 which justifies that wording: >> – Return X: An evaluation sequence phrase used to specify that >> evaluation of this evaluation sequence is to stop and that a *token* >> is to be returned to the caller of the evaluation sequence. If X is >> a *token*, then X is returned; if X is an *array*, a *token* of >> class *constant* and content X is returned. Nil is not an array; nil is a token. The standard doesn't say what would "return" without an object mean. The standard consistently uses verb "to return" for all kinds of results, not only values; for example *signaling* an error also means that error is _returned_: >> – Signal X: An evaluation sequence phrase used to specify that >> evaluation of this evaluation sequence is to stop and that a *token* >> whose class is X, where X is an error, is to be returned. -k
[Bug-apl] Equal incorrect for non-real arguments
When either of arguments of = has imaginary part of magnitude greater than comparison tolerance, a domain error is thrown. ⎕CT 1E¯13 0J1 = 0J1 DOMAIN ERROR 0J1=0J1 ^ ^ There are no conditions under which = is allowed to throw a domain error at all so this is serious. When it returns a value, it's still incorrect: 0J¯1E¯15 = 0J1E¯15 1 1E¯15J¯1E¯15 = ¯1E¯15J1E¯15 1 Both should be 0 regardless of ⎕CT because signs differ (arguments are not in the same half-plane). It's handled correctly for reals: ¯1E¯15 = 1E¯15 0 On the other hand: ⎕CT 1E¯13 1J1E¯15 = 1J1E¯14 0 1E¯15J0 = 1E¯14J0 0 1E¯15 = 1E¯14 1 All obviously should be 1. -k
[Bug-apl] 2 Quad TF incorrect for complex numbers
2⎕TF re-uses real part for imaginary part: X←5J0 10⎕CR'X' ◊ 2⎕TF'X' X←5J0 X←5J5 -k
Re: [Bug-apl] Equal incorrect for non-real arguments
On 2014-07-15 20:09:40, Juergen Sauermann wrote: > Except that (not so obviously) : > > > 1E¯15 = 1E¯14 > 0 Sorry, my mistake. You're, of course, right. Current (r376) behaviour seems to be correct with one exception: 1E¯15 = 1E¯14 0 1E¯15J0 = 1E¯14J0 1 Both should be zero, because it's exactly the same number. -k
Re: [Bug-apl] Determining data type...
On 2014-07-31 15:54:44, Peter Teeson wrote:
> Looked in the APL2 IBM manual but do not understand how to determine the data
> type of a variable.
> Neither the primitives nor the Quads sparked the answer in my brain.
> It must be something pretty obvious but not to me right now.
>
> So if I have a function FOO X how do I determine if X is character, integer,
> float, or imaginary?
> Assuming that it is not a nested array of course.
ischar←{''≡0⍴⍵}
isnumeric←{⍬≡0⍴⍵}
⍝ otherwise it's mixed or nested; examine elements
As for distinguishing integers, floats, and imaginary numbers, the
standard explicitly requests that there be no difference in behaviour of
numbers of different representations. You should not need to check what
kind of number they are, instead check explicitly whether their
complex/fractional part is zero.
isint←{0=1|⍵}
isreal←{⍵=|⍵}
Of course, there could be some kind of quad function to tell the internal
representation, but to my best knowledge there isn't one.
Though, in GNU APL, you can also distinguish complex number using ⎕TF.
-k
Re: [Bug-apl] Determining data type...
On 2014-07-31 22:49:06, Peter Teeson wrote: > David used theta as well. Is that also an available symbol? > i.e. a greek letter not otherwise used by the APL language? You're probably refering to ⍬. This is not a theta. This symbol is called zilde and it should look like zero with superimposed tilde. It's not specifically related to lambdas. Zilde stands for a numeric vector of zero length (just like '' is a character vector). You can write (0⍴0) instead of ⍬. -k
Re: [Bug-apl] Determining data type...
On 2014-07-31 22:51:39, Blake McBride wrote: > Never heard of χ. Not on my keyboard. Sounds like I need it. What is the U > code for it? Is it U+03a7 or U+03C7? It's a small chi, u+03c7. No APL kayboards have it because it's indeed unique to GNU APL. -k
[Bug-apl] Some typos
See below. As a side note, you might want to look at warnings that lintian gives for debian package even if most of them can be safely ingored. -k Index: workspaces/APL_CGI.apl === --- workspaces/APL_CGI.apl (revision 413) +++ workspaces/APL_CGI.apl (working copy) @@ -178,7 +178,7 @@ GNU APL compiles under CYGWIN, (see ), -provided that the necessary libraries are installed. HTML∆A 32-bit apl.exe +provided that the necessary libraries are installed. A 32-bit apl.exe that may run under CYGWIN lives in the download area. Use at your own risk and see README-5-WINDOWS for further information. Index: debian/changelog === --- debian/changelog (revision 413) +++ debian/changelog (working copy) @@ -9,5 +9,5 @@ * Native Functions GNU APL 1.2 now supports user defined APL functions written in C++ - -- Jürgen Sauermann Tue, 04 Jan 2014 14:14:00 +0200 + -- Jürgen Sauermann Tue, 14 Jan 2014 14:14:00 +0200 Index: doc/apl.1 === --- doc/apl.1 (revision 413) +++ doc/apl.1 (working copy) @@ -1,6 +1,6 @@ .TH APL 1 "2014 July 28" "apl" "GNU APL" .SH "NAME" -GNU APL - a free APL interpreter +apl - a free APL interpreter .SH SYNOPSIS .B apl [options] @@ -51,7 +51,7 @@ If you want to terminate the APL interpreter after executing the file, then use )OFF as last line in the file. .TP -.B-h, --help\ +.B -h, --help print all command line options with a brief hint what they do. .TP .B --id proc
[Bug-apl] Segfault in rank with empty argument
Using rank operator with empty argument of derived function, results in either assertion failure (for positive right operand) or segmentation fault (for non-positive right operand). It works correctly (resulting in an error) when axis syntax is used instead of standard-mandated numeric right operand. ⊢⍤0⍬ SEGMENTATION FAULT -- Stack trace at main.cc:140 0x7f54435b4b45 __libc_start_main 0x43ad65 main 0x54eab5 Workspace::immediate_execution(bool) 0x47a3d5Command::process_line() 0x473ca8 Command::do_APL_expression(UCS_string&) 0x484988 Executable::execute_body() const 0x4fed80 StateIndicator::run() 0x4afbd4Prefix::reduce_statements() 0x4aefbd Prefix::reduce_MISC_F_B_() 0x48ddc3 DerivedFunction::eval_B(Value_P) 0x462e44 Bif_OPER2_RANK::eval_LRB(Token&, Token&, Value_P) 0x45Bif_OPER2_RANK::do_LyXB(Function*, Shape const*, Value_P, int) 0x45f4f0 Bif_OPER2_RANK::finish_LyXB(EOC_arg&) 0x46d881 Cell::init(Cell const&) 0x7f54452d88d0 0x497d07 ⊢⍤1⍬ == Assertion failed: 0 in Function: init in file: Cell.cc:48 Call stack: -- Stack trace at Cell.cc:48 0x7f1490cb6b45 __libc_start_main 0x43ad65 main 0x54eab5 Workspace::immediate_execution(bool) 0x47a3d5Command::process_line() 0x473ca8 Command::do_APL_expression(UCS_string&) 0x484988 Executable::execute_body() const 0x4fed80 StateIndicator::run() 0x4afbd4Prefix::reduce_statements() 0x4aefbd Prefix::reduce_MISC_F_B_() 0x48ddc3 DerivedFunction::eval_B(Value_P) 0x462e44 Bif_OPER2_RANK::eval_LRB(Token&, Token&, Value_P) 0x45Bif_OPER2_RANK::do_LyXB(Function*, Shape const*, Value_P, int) 0x45f3cf Bif_OPER2_RANK::finish_LyXB(EOC_arg&) 0x4c59ab Bif_F2_RIGHT::eval_B(Value_P) 0x54c45d Value::clone(char const*) const 0x46d7d0Cell::init(Cell const&) 0x449302 do_Assert(char const*, char const*, char const*, int) SI stack: Depth:0 Exec: 0x2752c00 Safe ex: no Pmode:◊ ⊢⍤1⍬ PC: 5 RETURN_STATS Stat: ⊢⍤1⍬ err_code: 0x0 thrown: at StateIndicator.cc:41 e_msg_1: 'No Error' e_msg_2: '' e_msg_3: '' == -k
Re: [Bug-apl] Power Operator
That's interesting thing to see in GNU APL.
Negative exponents are obviously tricky to do, but what about using
boolean functions? It's a quite convenient way to succinctly express
iteration. But right now GNU APL gives somewhat unexpected results:
({2+⍵÷2}⍣≡) 9
9
({2+⍵÷2}⍣=) 9
VALENCE ERROR
(λ1⍣=)9
^^
In both cases Dyalog's answer would be 4, i.e. a fixed point of {2+⍵÷2}.
-k
Re: [Bug-apl] Power Operator
On 2014-08-13 19:42:25, Juergen Sauermann wrote:
> I believe the VALENCE ERROR comes because = is dyadic and
> the lambda is monadic?
>
> In GNU APL (and in the ISO standard) there is no monadic =, is it?
> Maybe in Dyalog APL there is?
No, it was supposed to be dyadic. I'm not sure how GNU APL tries to
interpret that or why the valence of lambda matters.
In Dyalog, if g is a function rather than scalar, then (f⍣g)Y repeatedly
applies Y←f Y until ((f Y) g Y) becomes true. The function g must be dyadic.
This is unrelated to the valence of the left operand f. In Dyalog, the
function that is to be iterated is always single-argument; possible left
argument of the derived function is pre-composed with left operand like this:
X (f⍣g) Y ←→ (X∘f ⍣ g) Y ←→ ({X f ⍵}⍣g) Y
-k
[Bug-apl] Segfault in empty replicate-assignment
(⍬/X)←⍬ ⊣ X←⍬ SEGMENTATION FAULT -- Stack trace at main.cc:140 0x7f4f289fbb45 __libc_start_main 0x43b725 main 0x556c75 Workspace::immediate_execution(bool) 0x480db5Command::process_line() 0x47a735 Command::do_APL_expression(UCS_string&) 0x48b3f5 Executable::execute_body() const 0x5076d0 StateIndicator::run() 0x4b71acPrefix::reduce_statements() 0x4b5bc8 Prefix::reduce_V_RPAR_ASS_B() 0x518c4d Symbol::resolve_lv(char const*) 0x54d9d4 Value::get_cellrefs(char const*) 0x7f4f2a64e8d0 0x49e5c7 -k
[Bug-apl] Assertion failure after indexing ⍺ or ⍵
{1=⍵} ,1
1
{1=⍵[1]} ,1
1
{⍵=1} ,1
1
{⍵[1]=1} ,1
==
Assertion failed: Avec::is_quad(idname[0])
in Function: get_nc
in file: NamedObject.cc:42
Call stack:
-- Stack trace at NamedObject.cc:42
0x7f8f678b2b45 __libc_start_main
0x43b725 main
0x556c75 Workspace::immediate_execution(bool)
0x480db5Command::process_line()
0x47a735 Command::do_APL_expression(UCS_string&)
0x48b3f5 Executable::execute_body() const
0x5076d0 StateIndicator::run()
0x4b71acPrefix::reduce_statements()
0x4b676d Prefix::reduce_MISC_F_B_()
0x4b640b Prefix::value_expected()
0x4a56bd NamedObject::get_nc() const
0x449b30do_Assert(char const*, char const*, char const*, int)
SI stack:
Depth:1
Exec: 0x2198ea8
Safe ex: no
Pmode:∇ λ1[1]
PC: 5 ⍵
Stat: λ←⍵[1]=1
err_code: 0x0
thrown: at StateIndicator.cc:41
e_msg_1: 'No Error'
e_msg_2: ''
e_msg_3: ''
Depth:0
Exec: 0x2197eb0
Safe ex: no
Pmode:◊ {⍵[1]=1} ,1
PC: 4 RETURN_STATS
Stat: {⍵[1]=1} ,1
err_code: 0x0
thrown: at StateIndicator.cc:41
e_msg_1: 'No Error'
e_msg_2: ''
e_msg_3: ''
==
Same thing happens for many other functions, not only for equals.
-k
[Bug-apl] Bad quality of the roll function
Currently GNU APL uses LCG with modulus 2⋆64 and then reduces values modulo desired range. This, beside being slightly biased for ranges not dividing the modulus, yields reduced periods when range is power of two. ?10 16⍴16 11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8 11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8 11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8 11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8 11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8 11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8 11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8 11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8 11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8 11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8 Doesn't look very random to me. -k
Re: [Bug-apl] Bad quality of the roll function
I don't think there is anything to gain by changing the main LCG part
given the constraints. I don't know how good are the parameters used by
GNU APL but they should be okay since those are the ones proposed by Knuth.
LCGs have a number of well known weaknesses, one of which is that their
less significant bits are not so random, and so if you simply mod range
it, the results will be poor (and if range divides LCG's modulus it will
fail spectacularly as it did for me). But it still has a full 64-bit
period and good spectral properties so it's good enough for updating ⎕RL
state and its quality can be improved by adding output transformation,
exactly as you did in r439.
As I see, your transformation is simply a bit reversal. It fixes my case.
Too bad compiler does NOT optimize out that loop! It generates a loop
with a conditional move inside. Yuck, that's awfully slow. Bit reversal
can be done *much* more efficiently with [1]. However, reversing bits is
generally more expensive than needed and it might make serial correlation
even worse. Following the recommendation from Numerical Recipes, I would
suggest permuting output with a single iteration of xorshift instead of
bit reversal. It would be much faster and much better at the same time.
On 2014-08-20 19:32:34, Juergen Sauermann wrote:
> Any suggestions are welcome for this topic.
The only issue left is bias resulting from reducing the range from
original 2⋆64 to some desired one. The simplest idea is to multiply
the random value by the target range divided by the generator's range.
This spreads out bias evenly (rather than making low values more probable
than high as in the case of modulo size, it makes every some-th value
have different probability than others) and is often assumed to be good
enough for non-cryptographic purposes (and roll is obviously not suitable
for those anyway). We can easily do better, though.
Other strategy — and it's the only one that guaranties result to have
uniform distribution — is to re-roll if random value is outside of
the range. If you decide to follow my suggestion of using xorshift
to improve LCG's output, re-rolling can be done very easily without
disturbing ⎕RL simply by further iterating xorshift (which is a good
random generator by itself).
I attached a patch that implements the above. Please review it, and
feel free to use it. (Sorry if it doesn't match your coding style;
I wasn't sure how to properly indent brackets.)
As a historical curiosity, recently I have read in [2] that APL\360
and its descendants used MINSTD generator and then derived results
by multiplying with range divided by modulus. APL2 manual shows some
sequences that confirm it also implemented it exactly the same way and
I just checked that Dyalog also uses the same algorithm. This is also
related to the choice of ⎕RL←16807 as a starting point that was
brought up there on the list last month.
[1] http://graphics.stanford.edu/~seander/bithacks.html#ReverseParallel
[2] https://web.archive.org/web/20120226063645/www.sigapl.org/qqv8n3p42.htm
-k
Index: src/ComplexCell.cc
===
--- src/ComplexCell.cc (revision 439)
+++ src/ComplexCell.cc (working copy)
@@ -219,8 +219,8 @@
const APL_Integer set_size = get_checked_near_int();
if (set_size <= 0) return E_DOMAIN_ERROR;
-const uint64_t rnd = Workspace::get_RL();
- new (Z) IntCell(qio + (rnd % set_size));
+const uint64_t rnd = Workspace::get_RL(set_size);
+ new (Z) IntCell(qio + rnd);
return E_NO_ERROR;
}
//-
Index: src/FloatCell.cc
===
--- src/FloatCell.cc (revision 439)
+++ src/FloatCell.cc (working copy)
@@ -207,8 +207,8 @@
const APL_Integer set_size = get_checked_near_int();
if (set_size <= 0) return E_DOMAIN_ERROR;
-const uint64_t rnd = Workspace::get_RL();
- new (Z) IntCell(qio + (rnd % set_size));
+const uint64_t rnd = Workspace::get_RL(set_size);
+ new (Z) IntCell(qio + rnd);
return E_NO_ERROR;
}
//-
Index: src/IntCell.cc
===
--- src/IntCell.cc (revision 439)
+++ src/IntCell.cc (working copy)
@@ -407,8 +407,8 @@
const APL_Integer set_size = value.ival;
if (set_size <= 0) return E_DOMAIN_ERROR;
-const uint64_t rnd = Workspace::get_RL();
- new (Z) IntCell(qio + (rnd % set_size));
+const uint64_t rnd = Workspace::get_RL(set_size);
+ new (Z) IntCell(qio + rnd);
return E_NO_ERROR;
}
//-
Index: src/ScalarFunction.cc
===
--- src/ScalarFunction.cc (revision 439)
+++ src/ScalarFunction.cc (working copy)
@@ -583,7 +583,7 @@
loop(z, aa)
{
-
Re: [Bug-apl] Bad quality of the roll function
Oh, I see you already fixed the bias exatly the way I wanted you to in r440 even before I posted that :) I still recommend using xorshift premutation instead of bit reversal and iterating ⎕RL only once per output value. -k
[Bug-apl] Assertion failure in evaluated input
When input to ⎕ is empty (just hit enter upon the prompt), it results in assertion failure: ⎕ ⎕: items_allocated = 16 items[0] = idx = 0 == Assertion failed: 0 && "Bad index" in Function: operator[] in file: Simple_string.hh:146 Call stack: -- Stack trace at Simple_string.hh:146 0x7f6758ee9b45 __libc_start_main 0x43c7c5 main 0x55bc95 Workspace::immediate_execution(bool) 0x483165Command::process_line() 0x47ca45 Command::do_APL_expression(UCS_string&) 0x48d795 Executable::execute_body() const 0x50c4d0 StateIndicator::run() 0x4b9901Prefix::reduce_statements() 0x524bcc Quad_Quad::resolve(Token&, bool) 0x4cd614 Bif_F1_EXECUTE::execute_statement(UCS_string&) 0x4bc476 0x44b740do_Assert(char const*, char const*, char const*, int) SI stack: Depth:0 Exec: 0x110c1c0 Safe ex: no Pmode:◊ ⎕ PC: 1 ENDL Stat: ⎕ err_code: 0x0 thrown: at StateIndicator.cc:41 e_msg_1: 'No Error' e_msg_2: '' e_msg_3: '' == -k
[Bug-apl] Segfault in reshape
When used with negative shape as left argument and non-literal array on the right, reshape dies with segmentation fault instead of raising a DOMAIN ERROR. ¯1⍴0,0 SEGMENTATION FAULT -- Stack trace at main.cc:162 0x7fa4d3d4db45 __libc_start_main 0x43f205 main 0x57237d Workspace::immediate_execution(bool) 0x48ad8aCommand::process_line() 0x480738 Command::do_APL_expression(UCS_string&) 0x49565b Executable::execute_body() const 0x51f020 StateIndicator::run() 0x4c5a5cPrefix::reduce_statements() 0x4c0b75 Prefix::reduce_A_F_B_() 0x4ccf2e Bif_F12_RHO::eval_AB(Value_P, Value_P) 0x7fa4d59948d0 0x4abf47 -k
[Bug-apl] segfault when using dyadic rank with empty arrays
1↑⍤0 ⍬ SEGMENTATION FAULT thread: 0x7fb6c6ec2740 thread_contexts_count: 1 busy_worker_count: 0 active_core_count: 1 thread # 0: 0x7fb6c6ec2740 pool sema: 0 RUN job: 0 no-name -- Stack trace at main.cc:165 0x7fb6c5ad8b45 __libc_start_main 0x43f255 main 0x56bb35 Workspace::immediate_execution(bool) 0x48982aCommand::process_line() 0x4898e5 Command::do_APL_expression(UCS_string&) 0x494b55 Executable::execute_body() const 0x51d5c0 StateIndicator::run() 0x4caa99Prefix::reduce_statements() 0x4c5919 Prefix::reduce_A_F_B_() 0x49d9ed DerivedFunction::eval_AB(Value_P, Value_P) 0x46fd29 Bif_OPER2_RANK::eval_ALRB(Value_P, Token&, Token&, Value_P) 0x46e68dBif_OPER2_RANK::do_ALyXB(Value_P, int, Function*, Shape const*, Value_P, int) 0x46d5f1 Bif_OPER2_RANK::finish_ALyXB(EOC_arg&) 0x4cc2a3 PointerCell::PointerCell(Value_P, Value&) 0x7fb6c68a98d0 0x4b13a0 Goodbye. -k
[Bug-apl] Missing info dir entry
Hello, Since some time dpkg has been complaining about missing entry in libapl.info.gz: install-info: warning: no info dir entry in `/usr/share/info/libapl.info.gz' That's just a minor annoyance but I believe it should be easy to fix. Thanks. -k
Re: [Bug-apl] SVN 585 clean build
I just checked out 592 and it failed to build because of missing buildtag.hh. Apparently this is just a typo in configure: cd src source ./buildtag ; cd .. Missing &&. -k
Re: [Bug-apl] using XFRPC11.w3
On Fri, Apr 24, 2015 at 7:23 PM, Juergen Sauermann wrote: > Now, ATF files are what )IN and )OUT read resp, produce. Chances are that > those > ATF files are the same as for IBM APL2. In that case all you need is to > write them in Dyalog and read them back into GNU APL using command )IN. I remember cross-testing reading and writing ATF files between Dyalog, NARS 2000, and GNU APL last year upon discovering some problems GNU APL had with encoding back then. It was certainly possible to transfer workspaces between the three, but, of course, any non-standard feature would cause problems (IIRC something as trivial as use of ⍬ would fail). Sometimes Dyalog may decide to index ⎕AV instead of using ⎕UCS which will also give bad results. -k
Re: [Bug-apl] Something is wrong here (or I may be wrong myself)
On Sat, Apr 25, 2015 at 4:38 AM, Christian Robert wrote: > a←1 0 0 0 0 1 0 0 1 1 0 0 1 1 1 1 0 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0 > b← 26 27 28 > a[b] > 0 0 0 > b⊃a > DOMAIN ERROR > b⊃a > ^ ^ I think this should be rank error rather than domain one. But it should be an error because length of b is higher than rank of a. It's roughly the same as a[26][27][28], not a[26 27 28]. This works: b⊃¨⊂a 0 0 0 -k
Re: [Bug-apl] Not sure
On Sat, Apr 25, 2015 at 3:43 AM, Blake McBride wrote: > Definitely a bug! Or consistent extension! -k
Re: [Bug-apl] HTML∆Assert Value Error
On Fri, May 22, 2015 at 4:03 AM, wrote: > Is there any reason HTML∆attr does not like single characters? It's because 'a' in APL is not a single-element vector as one might expect, but a scalar value. Use: 'left' HTML∆attr ,'a' -k
Re: [Bug-apl] segmentation fault in svn 639
On Sat, Jun 20, 2015 at 12:32 PM, Louis Chretien wrote: > I agree the error message should not be as dire as a segfault, but the basic > intent seems dubious… There's nothing inherently wrong with this. Argument of ⎕EX should be a character array with rows containing identifiers (possibly padded with spaces). For example to expunge both 'A' and 'B' at the same time you can write: ⎕EX 2 1⍴'AB' Now, according to ISO, ⎕EX '3 3' should result in a domain error but it gives 0 instead. -k
[Bug-apl] Circle bugs
There is a number of problems with circle functions. Inverse trigonometric and hyperbolic functions ¯1 ¯2 ¯6 ¯7 as well as function 0 are not properly extended to complex values when given argument is real; they work correctly with real-valued complex cells: 0 ¯1 ¯2 ¯6 ¯7 ∘.○ ¯2 ¯2J0 0.0 0J1.732050808 0.0 ¯1.570796327J1.316957897 0.0 3.141592654J1.316957897 0.0 1.316957897J3.141592654 0.0 ¯0.5493061443J1.570796327 Function ¯4 is incorrect for complex numbers. It's a simple programming error as it falls though to computing function ¯3 and returns that instead; it's correct for real cells: ¯4 ¯3 ∘.○ 1 1J0 00.7853981634 0.7853981634 0.7853981634 Functions 8 and ¯8 seem to choose different branches for real and complex cells. I'm not sure which is correct but it can't be both. 8○ 1 1J0 0J¯1.414213562 0J1.414213562 Finally, function 12, i.e. arc, always returns zero for real cells. It should give ○1 for negative real numbers. -k
[Bug-apl] Unexpected domain error in power
I have no idea how that happens. ¯1J0⋆2 DOMAIN ERROR ¯1⋆2 ^ ^ -k
Re: [Bug-apl] Request for enhancement
On Thu, Jul 23, 2015 at 6:55 PM, Juergen Sauermann wrote: > GNU APL supports the entire Unicode character set to the extent that your > platform supports (= is able to display) it. On Thu, Jul 23, 2015 at 5:59 PM, Fred Weigel wrote: > The current definition of letter includes (...) > 0.3(overbar) could be expanded to 0.33.. (as many as needed to fill > the precision). If I understand correctly, the request was about changes in syntax, not just about being able to use these characters in code in character literals or to manipulate them. > Overline E2 80 BE (UTF-8), complementary to _ (underline) I would like to note that symbol ‘complementary to’ _ underline, in APL world is the high minus which is rendered using ¯ (U+00AF macron). That's why it's allowed in names. There is no specific high minus character in Unicode, nor I see any reason to believe that U+203E overline would be a better fit for it. But perhaps there is some merit in adding it as acceptable alternative just like ∊ (U+220A) and ∈ (U+2208) which are both accepted by GNU APL for epsilon. Supporting underlined alphabetic characters in names by allowing combining low line in them would be interesting. Unicode has no other way to represent them, and lower-case Latin characters are not the same after all. But I'm not sure whether it's a good idea. As for 0.3̅, it's faster to write ÷3 and in most fonts I know it's also much more readable. -k
Re: [Bug-apl] take and drop on matrixes?
On Sun, Aug 30, 2015 at 12:02 AM, Alexey Veretennikov wrote: > Thanks, it looks indeed like I have to specify all sizes in GNU APL. In Dyalog you can use Dyalog's extensions to the standard but in GNU APL, you can use GNU APL's extensions. You don't need to specify all the sizes if you choose an axis — try 2↑[1]XG1. -k
Re: [Bug-apl] Doing without loops
On Mon, Aug 31, 2015 at 2:19 AM, Louis de Forcrand wrote:
> Now, my two questions aren't necessarily bugs, but the
> blog is titled "bugs and discussion". Anyway, how would I go about
> repeating a function using ⍣ until the answer reaches a certain value?
> e.g.:
> FIB ← { 2 ↓ ( { ⍵ , +/ ¯2 ↑ ⍵ } ⍣ ⍵ ) 0 1 }
> FIB 5
> 1 2 3 5 8
(...)
> I keep wanting to do something like:
>
>while ( ( ¯1 ↑ FIB i ) < 1000) {
> i++;
>}
>FIB i
>
> but I know I can't.
> It's not elegant anyway :)
Well, actually you can. Even without using explicit →gotos.
I'm not sure if that's the most elegant solution, but the first thing
that comes to mind is that you can use dyadic predicate for stopping
condition as right operand rather than a number.
In this form (f⍣g)Y iterates until ((f Y) g Y) becomes true; for
example f⍣≡ is a fixed point of f.
{¯1↓3↓({⍵,+/ ¯2 ↑ ⍵ } ⍣ {(↑⍵)<¯1↑⍺} ) ⍵, 0 1} 1000
1 2 3 5 8 13 21 34 55 89 144 233 377 610 987
(I passed the requested limit as (↑⍵) because GNU APL has no lexical
scope in dfns that would allow to name it without spilling it outside.)
-k
Re: [Bug-apl] APL Questions
On Sun, Sep 13, 2015 at 11:53 PM, Louis de Forcrand wrote: > Is it possible to terminate a function while it's running > (eg. when you accidentally set a very large number > as an operand)? Pressing Control-C should signal ATTENTION which should suspend execution of current function. > I read a bit of the APLX online manual just before posting, > and I think ⍞ does this, right? Yes. > Edit a specific line in a function? As of now I'm writing my > long ∇-declared functions in in .txt files and loading them > with -f, otherwise I would have to rewrite (or copy-paste) > them back in line by line in the terminal. > From what I understand, the APLX manual also says that it > is possible to do this with ⍎'∇FN[3]←A+1', for example, which > would change line 3 of function FN to A+1. I don't think this > works in GNU APL though. If you want to manipulate the definition automatically, you can take its S←⎕CR'FN', change it, and then call ⎕FX S. The ∇ editor is an interactive feature and you can't use it in ⍎. APLX Language Manual you mentioned has a chapter briefly describing editor's commands. After you enter the editor with ∇name you can change to desired line with [3] command and then enter the text that should replace that line. You can put the first editor command directly after the header in the same line. Changing 3rd line would look like this in interactive session: ∇FN[3] [3] A+1∇ Hitting enter after header line is required, and the second [3] in the first column is a prompt from the editor. > What does the ⍫ (lock) symbol do to functions, and how do > I use it? When you use ⍫ instead of ∇ to close the editor, the function becomes locked, i.e. you can can't edit it, ⎕CR gives empty array, and any errors encountered when executing that function will be reported as if it were a primitive function without suspending execution inside it or showing you its code. -k
Re: [Bug-apl] APL Questions
By the way, if you start your file with ⍝! or #!, then you will be able to )LOAD or )COPY changes into running session which might be fairly convenient if you prefer to use external editor (which you certainly are; line editors fell out of fashion many years ago) and prefer it not to be Emacs. Following Elias suggestion should make a lot of things easier for you if you don't mind using Emacs. -k
Re: [Bug-apl] Possible typo in "info apl"
On Sun, Sep 20, 2015 at 6:27 PM, wrote: > or do the trailing double colon have significance? That's how cross-references look like in GNU Info. Remove the double colon and it won't be recognized as a link any more. See https://www.gnu.org/software/texinfo/manual/info-stnd/info-stnd.html#Parts-of-an-Xref -k
Re: [Bug-apl] ≡/⍎¨ '5' "5" ⍝returns 1
On Sun, Sep 20, 2015 at 9:57 PM, wrote: > Should the execute primitive include the structure data? I thought that the > phrase in the subject line would return zero. I thought the first element > would return a scalar 5, and the second would return a single element five. > Both evaluate to a scalar five. In some places single-element vectors and scalars are treated equally. That's why ⍎'5' is even allowed in the first place. ⍎ throws domain error if its argument has rank higher than one, but otherwise it doesn't care and executes ravel list of its argument as a single line regardless if it's a vector or scalar. It's always a line of APL program, not data with any kind of structure. And by the rules of APL language, a program consisting of single digit 5 has scalar result. It is still so if you were to put, for example, a space before or after it (necessarily making the code itself a vector; but without changing the result it evaluates to). Distinction between kind of quotes used would matter if they were the part of the line executed by ⍎: ≡/⍎¨'"5"' "'5'" 0 Here "5" and '5' are executed giving a (character) vector and a scalar, respectively, in the result. -k
Re: [Bug-apl] How do you handle the contents of POST in a CGI script
On Sat, Oct 10, 2015 at 3:29 AM, wrote:
> I am struggling to follow our previous conversation. Pretty much, I am
> confused about the source of the POST contents. I believe you mentioned that
> it should come from stdin, and if I understood, it is not possible to use it
> jointly with CGI scripting:
I don't think you will be able to make use of it as real CGI; but to
read from stdin, you can use either ⍞ or FILE_IO functions. Both seem
to work fine for me when used in a separate script file rather than in
interactive session.
Some of your options are thus:
ContentsOfPOST←⍞⍝ get single line of parsed character input
ContentsOfPOST←FIO∆fgets 0 ⍝ get single line of raw bytes
(Note: descriptor of stdin is zero.)
Or something like:
ContentsOfPOST←{⍵, FIO∆fread 0}⍣{⍺⊢FIO∆feof 0}''
to read up everything from stdin in one go (it might add unnecessary 0
at the end if length of input data is a multiple of fread's block size).
As a side note, you probably want to add -s at the end of your #! line.
-k
Re: [Bug-apl] How do you handle the contents of POST in a CGI script
On Mon, Oct 12, 2015 at 5:48 AM, wrote:
> Why do you choose to write it like this?:
> ContentsOfPOST←{⍵, FIO∆fread 0}⍣{⍺⊢FIO∆feof 0}''
>
> This method (in my limited knowledge) seems equivalent:
> ContentsOfPOST←(FIO∆feof 0) FIO∆fread 0
I don't think it is.
FIO∆fread takes as its left argument a number of bytes to read or
assumes 5000 when called monadically. FIO∆feof returns either 1
when end-of-file indicator for the stream is set and 0 otherwise.
So (FIO∆feof 0) FIO∆fread 0 would try to read zero bytes when EOF
is not reached or one byte if it is, and in result it should always
return 0 without reading anything.
The idea was to read and catenate default-sized blocks until FIO∆feof
says we hit the end-of-file and ⍣ allows me to write this succinctly
(forgive me if not very readably).
-k
Re: [Bug-apl] 100?100 hang-up
On Tue, Oct 13, 2015 at 12:17 PM, Elias Mårtenson wrote: > It should be new set_size/8+1 on both the like with new and the subsequent > memset() one. You mean (set_size+7)/8 :) I was almost expecting this to be related to that this algorithm's termination probability converges to 1 very slowly when A is close to B, but 100 is small and 100?100 worked for me from time to time regardless of ⎕RL so that's not it. Good catch, Jay! While this isn't related to the bug reported, this algorithm saves a lot of memory when A << B, but otherwise it doesn't buy us anything because A cells need to be allocated for the result anyway. I think it might be a good idea to switch to standard Fisher-Yates shuffle at some point when A gets close to B (i.e. allocate B IntCells, shuffle in place and return first A of them; this terminates deterministically in linear time). -k
Re: [Bug-apl] Conversion from APL2000 to Gnu APL
On Thu, Oct 22, 2015 at 3:29 PM, Michael Potter wrote: > APL2000 does not appear to have an )OUT command. > > We get: > "INCORRECT COMMAND" in response to: > )OUT > )OUT SOMEFILE > )OUT C:SOMEFILE I think in APL2000 it should be ]OUT starting with square bracket. At least that's what comp.lang.apl FAQ says about it. -k
Re: [Bug-apl] ⎕TRACE usage ?
On Fri, Oct 23, 2015 at 5:45 AM, wrote: > Is there documentation on how to use ⎕TRACE ? I ran info apl | grep ⎕TRACE > and found nothing. It does not look like it is listed in the IBM APL2 manual > either. ⎕STOP and ⎕TRACE are defined in ISO 13751. They are part of optional facility "Trace and Stop control." They allow setting up some lines of defined function to print debug info or to suspend execution when hit. It's essentially the same as S∆ and T∆ which you can find in APL2 manual. The difference is that while in APL2 you assign vector of line numbers to specially named variables S∆fun and T∆fun to set stop or trace on the function named fun, these are regular system commands that take function name as a string argument. Z ← ⎕TRACE 'name' ←→ Z ← T∆name A ⎕TRACE 'name' ←→ T∆name ← A Z ← ⎕STOP 'name'←→ Z ← S∆name A ⎕STOP 'name' ←→ S∆name ← A HOWEVER I just found that GNU APL has arguments reversed in dyadic case (setting lines to trace or stop on). I think that's a bug. -k
[Bug-apl] Segfault when tracing not a function
Using ⎕TRACE or ⎕STOP with some other symbol than user defined function either through T∆/S∆ or directly, either for querying or setting, results in a segmentation fault: A←3 ⎕TRACE'A' SEGMENTATION FAULT -- Stack trace at main.cc:63 0x7f6fa8a8ab45 __libc_start_main 0x443325 main 0x56e57d Workspace::immediate_execution(bool) 0x48a45aCommand::process_line() 0x48a51a Command::do_APL_expression(UCS_string&) 0x4953c5 Executable::execute_body() const 0x51bb80 StateIndicator::run() 0x4c9c58Prefix::reduce_statements() 0x4c8f3e Prefix::reduce_MISC_F_B_() 0x4ea8d7 Quad_TRACE::eval_B(Value_P) 0x4ea4f6 Stop_Trace::locate_fun(Value const&) 0x7f6fa98cb8d0 0x4482d7 Goodbye. -k
Re: [Bug-apl] Segfault when tracing not a function
--- src/QuadFunction.cc (revision 686)
+++ src/QuadFunction.cc (working copy)
@@ -1604,7 +1604,7 @@
}
Function * fun = fun_symbol->get_function();
- if (fun_symbol == 0)
+ if (fun == 0)
{
CERR << "symbol " << fun_name_ucs << " is not a function" << endl;
return 0;
Re: [Bug-apl] Help using the power operator
On Fri, Oct 30, 2015 at 11:01 AM, Elias Mårtenson wrote:
>
> 4×+/{(¯1*⍵+1)÷¯1+2×⍵}¨⍳100
>
> The above expression performs 1 million iterations, but is also allocates a
> 1 million element array to do so.
I don't know GNU APL internals well enough to speak about when and how
memory is allocated, but when I remove each (¨) from the above
expression (it's not needed there, this dfn is a scalar function)
then it runs many times faster but surprisingly seems to take even
more memory.
> Is there a simple and natural way to perform this computation in an
> iterative manner using the power operator (⍣)?
While you can use ⍣ to express any kind of iteration, it doesn't mean
you should. This algorithm is a sum, intrinsically; trying to rewrite
it as an iterated function won't do any good, it can be neither simple
nor natural (and would also be a lot slower). It's natural only for
algorithms that are written as f(f(f(...))).
Your code is good because it reads exactly like, and is immediately
recognizable as the arctangent formula you were trying to implement.
Optimizing interpreter could, however, recognize that this is a simple
sum of scalar function of iota, and that it could be computed in
constant space.
That being said, a straightforward translation to iterative form using
global variable for loop counter may look like this:
i←0 ◊ 4×{⍵+(¯1*i+1)÷¯1+2×i←i+1}⍣100⊢0
In hopefully constant memory, but very slow and not as legible.
Attempting not to use global variables would make it even worse.
So if memory is scarce and must be optimized for, disregarding
legibility, I would try partitioning it into smaller ranges rather
than switching to iterative variant completely:
4×+/{ +/{(¯1*⍵+1)÷¯1+2×⍵} (1000×⍵)+⍳1000 }¨ (⍳1000)-1
This at least saves some of the performance of the original.
-k
Re: [Bug-apl] Help using the power operator
On Fri, Oct 30, 2015 at 2:39 PM, Kacper Gutowski wrote:
> i←0 ◊ 4×{⍵+(¯1*i+1)÷¯1+2×i←i+1}⍣100⊢0
This is slightly faster and doesn't use global variables:
↑{(+/⍵[1],4÷1↓⍵),4 ¯4+1↓⍵}⍣50⊢0 1 ¯3
Nowhere near “simple and natural,” though.
-k
Re: [Bug-apl] Whats a better way to do this?
On Sun, Nov 8, 2015 at 12:05 AM, wrote: > I thought it would have been as simple as b⊂subsections > because they are the same length, but that also yields an error. If I understand your problem correctly, it's simply b⊂¨subsections. -k
Re: [Bug-apl] trunk/support-files/Dyalog-Keyboard/apl.xmodmap alt+tab
On Fri, Jan 15, 2016 at 4:29 AM, wrote: > I was wondering if anyone is familiar enough with xmodmap to know why it > would disable the existing Alt-Tab functionality in xorg (switching between > windows) when the key combination has no apparent use in the interpreter. > I am using this file: > trunk/support-files/Dyalog-Keyboard/apl.xmodmap The relevant lines are: keycode 23 = Tab ISO_Left_Tab keycode 64 = Mode_switch Meta_L The key usually used as Alt_L modifier is hijacked as Mode_switch to make other keys send different keysyms depending on whether it is depressed or not, instead of acting as modifier. Therefore, pressing Alt-Tab, gives just a Tab. There is no way to use Alt at all with that configuration. Note though, that there are several other keys mapped as Mode_switch in the above file. You can change it back to the default keycode 64 = Alt_L Meta_L and then just use Super (Win) key, or right Alt, or any other mentioned as Mode_switch to type APL symbols. On an unrelated note, many systems already ship with APL layout and you can get very similar results using something like: $ setxkbmap 'us,apl(dyalog)' -option grp:lswitch The grp:lswitch option says to hijack left Alt for group switch switching between us and apl(dyalog) layouts (one can use grp:switch for right Alt). -k
Re: [Bug-apl] apl symbols from a file
On Mon, Feb 15, 2016 at 12:08 AM, wrote:
> the system's word count mechanism says length four. APL says length three, I
> thought this was going to be length 1 and the symbol '⍝'. Does anyone know
> what I am doing incorrectly:
>
> a@a:~/aplstuff$ echo "⍝" > txt
> a@a:~/aplstuff$ cat txt
> ⍝
> a@a:~/aplstuff$ wc txt
> 1 1 4 txt
Your file ‘txt’ contains 4 bytes: the character ⍝ (U+235D, which takes
3 bytes encoded in UTF-8: e2 8d 9d), followed by a new line (0a). And
this is what ‘wc’ reports: 1 line, 1 word, and 4 bytes. Use ‘wc -m’
to get the count in characters (under current locale's encoding),
which shall be 2 for that file (newline still counts).
> tie←⎕FIO[3] path
> fontents←{⍵, ⎕FIO[6] tie}⍣{⍺⊢⎕FIO[10] tie}''
⎕FIO[6] reads bytes, not Unicode codepoints. It reads bytes and
returns them as numeric vector, so at this point your fontents should
be a vector of 4 values: 226 141 157 10.
As a side note, this is better written using ⎕FIO[26] which reads the
whole named file (it didn't work with stdin, but there is no reason
not to use it here). Using the trick above, you will get you an
additional zero at the end if the size of file happens to be exact
multiple of the default block size used by ⎕FIO[6] (which is 5000).
⎕FIO[26] doesn't have such problems.
> fontents←⎕ucs⊃,/⍪(~ fontents∊10 11)⊂fontents
> fontents
> â
And you passed this to ⎕UCS which obediently converted each number to
a character of the corresponding Unicode codepoint, i.e. 226 141 157
got turned into U+00E2 U+008D U+009D (â followed by non-printable
characters).
What you probably wanted was to decode the contents as UTF-8-encoded
characters. You can achieve this by using 19 ⎕CR fontents.
In short:
"⍝\n" ≡ 19⎕CR⎕FIO[26]'txt'
1
Note that ⎕FIO[26] returns bytes as character array (similarly to what
you got by using ⎕UCS on numeric array of bytes), and this is exactly
what 19 ⎕CR expects.
-k
Re: [Bug-apl] noise in fomatting ver small numbers
On Sun, Feb 21, 2016 at 10:38 PM, wrote: > it seems that format adds fuzz after a certain point. It's not a “fuzz,” but an artifact of using IEEE 754 double precision floating point numbers. ISO APL leaves a lot of freedom when it comes to representation of numbers, but when using IEEE floats, the results you observed are expected and anything else would be incorrect. You should be able to observe exactly the same results in any language using floating point numbers. > a←0.0001 The number 1E¯44 you requested isn't representable exactly, and the closest representable one is a←8034690221294951×2⋆−199. > '0. '⍕a > 0.0001 > '0.0 '⍕a > 0.5 Format simply prints out its decimal expansion. But it properly rounds that expansion using the usual rules: 99.5 rounds up to 100, but 95.2 rounds down to 95. -k
Re: [Bug-apl] IOTA
On Thu, Mar 3, 2016 at 12:40 PM, Juergen Sauermann wrote: > the IBM APL2 language reference says (page 111): > > If R is a simple scalar, ⊂ R is R. If R is not a simple scalar, the depth of > R is 1+ ≡R. > > And the ISO standard says the same (page 169): > > Z ← ⊂B > Note: If B is a simple-scalar, Z is B. Jay is nevertheless correct, because ⊂x is NOT a simple-scalar according to ISO. On page 21 it has the following definitions: > Simple: An array is simple if each item of its ravel-list is either > a character or a number. > Simple-scalar: A simple array whose rank is zero. The sole item of ⊂x is an enclosed array, not a character or number. -k
Re: [Bug-apl] ⎕fio
On Sat, Mar 5, 2016 at 6:45 AM, Christian Robert wrote: > [0] z←Execute cmd;⎕io;fh > [7] Fini: ⎕FIO[25] fh > [8] ⊃⊃z (...) > I do not understand why it repeat the result twice. one via stdout and one > via boxing as I can guess. The function returns z as indicated in its header, but before doing so, it prints out results of lines 7 and 8. Perhaps you meant something like [8] z←⊃⊃z. -k
Re: [Bug-apl] Feature suggestion: multiple function arguments
On Sun, Mar 13, 2016 at 6:20 PM, Juergen Sauermann wrote: > it actually does create conflicts. > > In IBM APL2 and in GNU APL, the expression > > ⍺ (f g h) ⍵ > > gives a 3 item vector with the items being ⍺, (f g h), and ⍵. > In Dyalog APL it gives (quote): > > (⍺ f ⍵) g (⍺ h ⍵) ⍝ dyadic (fgh) fork I'm not certain whether it does create conflicts or not in general, but I think this particular example is flawed: ⍺ (f g h) ⍵ could be anything depending on what name classes those symbols have (particularly if g were an operator). When f, g, and h are all functions, then it's not a vector, but a syntax error. No conflict here. -k
Re: [Bug-apl] Feature suggestion: multiple function arguments
On Mon, Mar 14, 2016 at 2:03 PM, Juergen Sauermann wrote: > Consider this: > > 1 (+//) 1 2 3 4 > 1 2 3 4 FWIW, Dyalog returns the same, but it certainly does something weird I don't understand here. It treats it as an operator even when it says it is a function: f←/ ⎕NC'f' 3 1(+f f)1 2 3 4 1 2 3 4 All in all while I think tacit definitions are certainly attractive, I'm inclined to agree that it's probably not worth the effort even if it could be done without ugly hacks. On Tue, Mar 15, 2016 at 2:14 PM, Jay Foad wrote: > In APL2 this is not a problem, because / et al are always operators: > > 1 2 /¨ 3 4 ⍝ in APL2 this parses as (1 2 /)¨ 3 4 > 3 3 3 4 4 4 This is interesting. I think this conflicts with ISO, but curiously I can't find each operator in the form table there. While I'm aware that Iverson has written that it's possible to treat / uniformly as an operator, ISO certainly keeps function / and operator / separate requiring ether constant or function on their left, respectively. -k
[Bug-apl] Incorrect logarithm of negative real numbers
Logarithm of negative real number fails to coerce it to complex and results in a malformed value: 2⍟¯1 0.0 2⍟¯1J0 0J4.532360142 -k
