ea of what an APL
> layout would look like, in which case "setxkbmap us,apl" should also work.
> Unfortunately this is apparently not the case with my setup. The man page for
> xkeyboard-config(7) does not mention an apl layout.
>
> Best Regards,
>
> Alexander
Below is what I have for FreeBSD. It uses xkeyboard-config.
8<
$ cat /usr/local/etc/X11/xorg.conf.d/kbd-layout-dvp-apl.conf
Section "InputClass"
Identifier "KeyboardDefaults"
MatchIsKeyboard "on"
Option "XkbLayout" "us,apl"
Option "XkbModel" "pc104"
Compare with Dyalog,
]runtime +/⍳100
* Benchmarking "+/⍳100"
(ms)
CPU (avg): 1
Elapsed: 1
]runtime {⍺+⍵}/⍳100
* Benchmarking "{⍺+⍵}/⍳100"
(ms)
CPU (avg): 270
Elapsed: 279
> On Mar 30, 2020
For comparison, here is J,
JVERSION
Engine: j901/j64avx2/darwin
Release-e: commercial/2020-01-29T12:41:32
Library: 9.01.21
Platform: Darwin 64
Installer: J901 install
InstallPath: /applications/j901
Contact: www.jsoftware.com
timex'+/i.100'
0.00184
plus=:4 :'x+y'
timex'plus/i.1
CPU cache is the reason for a JIT compilation/conversion of APL expressions, in
order to fuse local operations together.
If you are in to CPU cache aspects of HPC, the blis papers would be interesting
to you. See the citations at https://github.com/flame/blis
> On Oct 17, 2019, at 10:03 AM, Ro
This is what I use for configure
CXXFLAGS="-march=native -I/opt/local/include -Wno-deprecated-declarations
-Wno-old-style-cast"
> On Apr 25, 2019, at 8:45 AM, Dr. Jürgen Sauermann
> wrote:
>
> Hi Louis,
>
> I vaguely remember that we had that problem on MacOS earlier, but I don't
> remember
Hi,
I just updated my install to the svn r1138.
Below is what I needed to change for building on macOS.
I believe that those `delete[]` should be applied for other systems, too.
% svn diff
Index: src/PrimitiveFunction.cc
===
--- src/
EINTR could happen in many situations.
The usual resolution for EINTR is to retry whatever system call that failed
because of EINTR.
Here, we should call fgetc again.
Best,
Xiao-Yong
> On Jul 29, 2018, at 4:10 PM, Chris Moller wrote:
>
> Hi, Jürgen,
>
> So far as I can tell, after all the t
I haven't checked.
But having lib_file_io.dylib instead of lib_file_io.so might create problems
with ⎕FX which uses dlopen.
Can you check
'lib_file_io.so' ⎕FX 'FILE_IO'
and subsequent FILE_IO functionalities still work or not?
> On Jun 30, 2018, at 5:33 PM, Peter Teeson wrote:
>
> Hi J
You need a dylib to link against at compile time.
Passing `-dynamiclib` to the compiler should to the trick to generate a dylib.
We need something like:
g++ -dynamiclib -o libapl.dylib all_the_o_files.o ...
A bundle is what a so file is, which in general is generated by the compiler
when `-bu
0
>>>> 0 0 0 0
>>>>
>>>>
>>>> /// Jürgen
>>>>
>>>>
>>>>
>>>> TOn 01/08/2018 10:29 AM, Jay Foad wrote:
>>>>> Thanks. At r1034 I get:
>>>>>
>>>>
1e¯200|1e200 hangs on my mac.
> On Jan 5, 2018, at 6:57 AM, Juergen Sauermann
> wrote:
>
> Hi Jay,
>
> hmm, interesting. I am getting this:
>
> A←(-⌽A),0,A←1e¯200 1e¯100 1 1e100 1e200
> A∘.|A
> 0E00E00 0E0 0E00 0E00E00 0E0 0E0
> 0E00E00 0E0
> On Sep 20, 2017, at 9:19 PM, Peter Teeson wrote:
>
> (These days performance can hardly be a compelling argument
> with multiple many-core CPU chips.)
This kind of argument for APL is exactly why Fortran is still alive and well.
> On Sep 20, 2017, at 3:36 PM, Xiao-Yong Jin wrote:
>
> reinterpret_cast works from smaller sizes to larger sizes.
>
> So simply
> reinterpret_cast(thread)
Sorry, I meant
reinterpret_cast(thread)
>
> should work for both of our machines (size_t is uint64_t for
ridiculous to me that replacing a good old C-style cast
>> that worked fine for the
>> last 10 years cannot be replaced by one of the 3 members of the C++ zoo of
>> casts in a portable way?
>>
>> Maybe some intermediate cast to const void * can be done on your
that worked fine for the
> last 10 years cannot be replaced by one of the 3 members of the C++ zoo of
> casts in a portable way?
>
> Maybe some intermediate cast to const void * can be done on your machine?
>
> Best Regards,
> Jürgen
>
>
> On 09/19/2017 11:44 PM,
An APL wrapper (⎕regexp[OP]) of a simple API like this would be great, (rune
means unicode)
https://9fans.github.io/plan9port/man/man3/regexp.html
One can build more APL functions out of these without much performance penalty.
On the other hand, if there is an DFA implementation provided by APL
dentify a
> thread and
> to distinguish it from other threads for debugging purposes. So as long as the
> compiler does not complain about the cast everything is fine. Cast to void *
> instead of
> int would also be an option.
>
> /// Jürgen
>
>
> On 09/11/2017 0
gt;
> thanks, maybe fixed in SVN 1011.
> Problem with that error is that the casted type is not a pointer, at least on
> my machine.
>
> /// Jürgen
>
>
> On 09/11/2017 06:55 PM, Xiao-Yong Jin wrote:
>> At revision 1010
>>
>> Thread_context.cc:7
At revision 1010
Thread_context.cc:72:65: error: cast from pointer to smaller type 'int' loses
information
out << "thread #" << setw(2) << N << ":" << setw(16) << int(thread)
I guess APL standard is really bad in this regard.
Dyalog APL gives the following:
Dyalog APL/S-64 Version 15.0.27700
Unicode Edition
Tue Jun 20 10:46:08 2017
5J3|14J5
1J4
5J3|1J4
¯4J1
5J3|¯4J1
¯4J1
which coincides with the previous gnu apl result.
> On Jun 20, 2017, at 3:02 AM,
If shared variables can go through SHMEM, you can probably interface
cuda that way without much bottle neck.
But with the way GNU APL is implemented now, there are just too many
other limitations on performance with arrays of such size.
> On Apr 28, 2017, at 9:19 PM, Fred Weigel wrote:
>
> Jeurg
The last thing we want is to add one more implementation dependent
feature to an already fractured APL ecosystem.
If our developers prefer a set of strict rules of doxygen style
documents, you can make your own simple documentation list with
awk. The following one liner should do the trick. I've
r-case).
> I suppose *⍥* is German middle-case then :-).
>
> /// Jürgen
>
>
> On 04/17/2017 09:18 PM, Xiao-Yong Jin wrote:
>>> On Apr 17, 2017, at 1:06 PM, Juergen Sauermann
>>> wrote:
>>>
>>> dyadic function: Z ← A ⌹ B (Matrix divide)
>>>
> On Apr 17, 2017, at 1:06 PM, Juergen Sauermann
> wrote:
>
> dyadic function: Z ← A ⌹ B (Matrix divide)
> Solution to system of linear equations Ax = B
That should be "A = Bx"
It seems that ⍤ and ⍣ are not in the list.
I guess that's because they are not in APL2?
Thus 3[1 2] is evaluated first, giving the RANK ERROR.
>
> /// Jürgen
>
>
> On 02/15/2017 09:14 PM, Xiao-Yong Jin wrote:
>> Feature or bug?
>>
>> 1 2 3[2 1 3]
>> RANK ERROR
>> 1 2 3[2 1 3]
>> ^^
>> )sic
>> (1 2 3)[2 1 3]
>> 2 1 3
>>
>>
>>
>>
>
Feature or bug?
1 2 3[2 1 3]
RANK ERROR
1 2 3[2 1 3]
^^
)sic
(1 2 3)[2 1 3]
2 1 3
n help here. It's designed
>>> to assist when creating an FFI for something like GNU APL. I recommend
>>> anyone who considers taking up this project to investigate it.
>>>
>>> libffi can be found here: https://github.com/libffi/libffi
>>>
>>>
eved by a single "master"-native
>> function which then loads the
>> actual DLL as specified by the arguments of the master function.
>> Referring to the example in
>> link you gave below:
>>
>> *a=: 'kernel32 GetProfileStringA
It would be nice if one doesn't need to write wrappers and the APL system can
do the
structure conversions within the APL interpreter. In J, you can dlopen a
library
and pass J values directly without writing and compiling C, see
http://www.jsoftware.com/help/user/call_procedure.htm
and the
the rest of the document.
> On Feb 6, 2017, at 2:06 PM, Juergen Sauermann
> wrote:
>
> Hi Xiao-Yong,
>
> thanks a lot for this explanation!
>
> /// Jürgen
>
>
> On 02/06/2017 08:25 PM, Xiao-Yong Jin wrote:
>> I would guess he is using zsh instead of bash
I would guess he is using zsh instead of bash.
zsh allows interpreter after #! without an absolute path, irrelevant of the OS
kernel.
Try running the following script under zsh:
SCRIPT BEGIN
#!bash
echo 'this will fail'
SCRIPT END
You will get
OUTPUT BEGIN
bash: e
t;
> thanks, fixed in SVN 852.
>
> /// Jürgen
>
>
> On 01/17/2017 02:56 AM, Xiao-Yong Jin wrote:
>> Looks like a gcc loop unrolling bug.
>>
>> I ha
get less confused.
> *SVN 854*.
>
> If the warning remains then it is definitely bogus.
>
> Also, I can't really see why iteration 255 should behave differently than all
> the others.
>
> /// Jürgen
>
>
> On 01/17/2017 05:10 AM, Xiao-Yong Jin wrote:
&
rement)
^
> On Jan 13, 2017, at 5:52 AM, Juergen Sauermann
> wrote:
>
> Hi Xiao-Yong,
>
> thanks, fixed in SVN 849.
>
> /// Jürgen
>
>
> On 01/12/2017 11:30 PM, Xiao-Yong Jin wrote:
>> OSAtomicAdd32Barrier is deprecated i
I always feel GNU APL kind of slow compared to Dyalog, but I never really
compared two in large dataset.
I'm mostly using J now for large dataset.
If Elias has the optimized code for GNU APL and a reproducible way to measure
timing, I'd like to compare it with Dyalog and J.
> On Jan 17, 2017, at
loop
#define loop(v, e) for (ShapeItem v = 0; v < ShapeItem(e); ++v)
SymbolTable.cc:493:4: note: in expansion of macro ‘loop’
loop(hash, SYMBOL_HASH_TABLE_SIZE) clear_slot(out, hash);
^~~~
cc1plus: all warnings being treated as errors
> On Jan 16, 2017, at 8:05 PM, Xiao-Yong Jin
Not sure if it's another gcc unrolling bug.
Using gcc 6.2.0
g++ -DHAVE_CONFIG_H -I. -I..-Werror -Wall -I sql -I/sandbox/pkg/lib/include
-I/sandbox/pkg/include -rdynamic -march=native -O3 -pipe
-I/sandbox/pkg/include -MT apl-Bif_F12_SORT.o -MD -MP -MF .deps/ap
l-Bif_F12_SORT.Tpo -c -o apl-Bi
on in the loop() macto is between two int64_ts. And has
> nothing to do with array subscripts.
>
> /// Jürgen
>
>
> On 01/16/2017 07:18 PM, Xiao-Yong Jin wrote:
>> I'm seeing the same array subscript errors with gcc 4.4.7 here.
>>
>> g++ -DHAVE_CONFIG_
I'm seeing the same array subscript errors with gcc 4.4.7 here.
g++ -DHAVE_CONFIG_H -I. -I..-Werror -Wall -I sql -I/usr/include -rdynamic
-mcpu=power7 -mtune=power7 -O3 -fno-math-errno -funsafe-math-optimizations
-fno-rounding-math -fno-signaling-nans -fcx-limited-range -pipe -MT
apl-Arra
OSAtomicAdd32Barrier is deprecated in macOS 10.12
/usr/bin/clang++ -DHAVE_CONFIG_H -I. -I..-Werror -Wall -I sql
-I/opt/local//include-march=native -O3 -pipe -MT apl-Assert.o -MD -MP -MF
.deps/apl-Assert.Tpo -c -o apl-Assert.o `test -f 'Assert.cc' || echo
'./'`Assert.cc
In file included
> On Jan 5, 2017, at 8:36 PM, Christian Robert
> wrote:
>
> First of all, ⎕FIO does not exist in any other APL interpreter I know of.
> Portability of what ?
Portability of any workspace/package that uses FILE_IO workspace. If you have
a package/workspace that uses FILE_IO workspace, you ca
I think the point is portability. Axis notation in function definition
(especially using an character array as an axis) is not in any standard, afaik,
so it's impossible to hack such a function in any other APL implementation. An
workspace/package uses this FIO function wouldn't be able to fun
Seems like a good motivation to support quad equal: ⌸
See the key operator in dyalog:
http://help.dyalog.com/15.0/Content/Language/Primitive%20Operators/Key.htm
On the other hand, pattern matching A[n]←x for
in-place operation seems a good way to go.
Not sure if it’s possible in GNU APL.
> On Sep
>>
>> or better
>>
>> #include
>>
>> things in double quotes are searched in local directory by default and not
>> in system.
>>
>> Xtian.
>>
>>
>> On 2016-08-28 23:42, Xiao-Yong Jin wrote:
>> LApack.cc:
LApack.cc:21:20: fatal error: malloc.h: No such file or directory
#include "malloc.h"
^
compilation terminated.
Under OS X, it’s in /usr/include/malloc/malloc.h
Is it actually needed? The code compiles fine without the #include.
Best,
Xiao-Yong
gt; functions is wrong or
> that the 80-core machine we used is performance-wise not even near the PRAM
> model. My best
> guess is the latter.
>
> /// Jürgen
>
>
> On 08/26/2016 08:41 PM, Xiao-Yong Jin wrote:
>>> On Aug 26, 2016, at 1:12 PM, enz...@gmx.com
&g
> On Aug 26, 2016, at 1:12 PM, enz...@gmx.com wrote:
>
> finally a computer just perfect for gnuapl
>
> http://thehackernews.com/2016/08/powerful-multicore-processor.html
Now is the perfect time to invest your time and effort in improving parallel
efficiency in gnu-apl.
This should work,
(2 3 5 4⍴⍳24)(+⍤1⍤¯1)(2 4⍴⍳8)
VALUE ERROR
μ-Z__A_LO_RANK_X7_B[4] →(μ-X7≢¯1)⍴μ-WITH_AXES
^
You could use the axis operator generically
(2 3 5 4⍴⍳24){⍺+[1,(⍴⍴⍺)⌈⍴⍴⍵]⍵}(2 4⍴⍳8)
but the rank operator seems cleaner.
Best,
Xiao-Yong
This shouldn’t be an error:
⍎¨'0' ' '
VALUE ERROR
μ-Z__LO_EACH_B[2] μ-Z[μ-N]←⊂μ-LO⊃μ-B[μ-N]
^
The following from GNU APL,
(⊂[1]⍳2 3)+.+.+⊂[1]10×⍳2 3
209 198
(⊂[1]⍳2 3)(+.+).+⊂[1]10×⍳2 3
209 198
(⊂[1]⍳2 3)+.(+.+)⊂[1]10×⍳2 3
33 66 66 66
do not agree with Dyalog APL,
⎕ML
3
(⊂[1]⍳2 3)+.+.+⊂[1]10×⍳2 3
165 242
(⊂[1]⍳2 3)(+.+).+⊂[1]10×⍳2 3
165
Hi, here goes another micro error.
2 3+.{⍺×⍵}2 3
LENGTH ERROR
μ-Z__A_LO_INNER_RO_B[5] (μ-IA μ-IB)←⊃μ-I[μ-N]
^ ^
)reset
2 3{⍺+⍵}.{⍺×⍵}2 3
LENGTH ERROR
μ-Z__A_LO_INNER_RO_B[5] (μ-IA μ-IB)←⊃μ-I[μ-N]
^ ^
)r
That’s the version of the Archive.cc. See
$ sed -n '10,11p' src/buildtag
ARCHIVE_SVNINFO=`svn info Archive.cc | grep "Last Changed Rev" \
| awk -F : '{print $2;}'`
> On Jun 28, 2016, at 9:34 PM, Blake McBride wrote:
>
> Why does it say "but is now being )LOA
out left-to-right or right-to-left associativity of APL
>> operators. I personally
>> would find it counter-intuitive if functions are evaluated left-to-right
>> while operators are
>> evaluated right-to-left.
>>
>> /// Jürgen
>>
>>
>> On 06/27/2016
Here is a peculiar case,
⎕PP
17
{⍕'PI',○2}
PI 6.2831853071795862
{⍕'PI' '2PI',[1.5]○1 2}
PI 3.141592654
2PI 6.283185307
'PI' '2PI',[1.5]○1 2
PI 3.1415926535897931
2PI 6.2831853071795862
> On Jun 23, 2016, at 7:07 AM, Louis Chretien wrote:
>
> R←{X} (A ⎕R B) Y
The line on the title? It’s not really the language syntax. It’s their way to
tell you that ⎕R is an operator that receives required left and right operands
A and B, and creates a ambivalent function that applies on r
gt;
>> * "^([a-z]+):([0-9]+)$" regex∆scan "foo:123"*
>> ┏→━━┓
>> ┃"foo" "123"┃
>> ┗∊━━┛
>>
>> Regards,
>> Elias
>>
>> On 22 June 2016 at 10:35, Xiao-Yong Jin > <mailto:jinxiaoy...@gmail.com>
At some point I really wanted to implement the simplest editor, namely ed (it
would be much better than any APL system has offered), in APL, but I never
finished the regex part. Perhaps it would be a nice exercise for someone who’s
interested in learning APL to actually implement some of the mo
Jürgen, I can confirm that loop problem is fixed.
Christian, that “function” is an operator, same as each (¨). You would find it
listed in )ops, similar to ⎕NL 4, and ⎕NC'FE' would return 4 (as an operator).
In gnu apl you can use )nms to list all the )vars )fns and )ops.
Best,
Xiao-Yong
> On
Hi,
In my script I was using ⍎¨ on a vector of character vector from each line of a
file. After some testing, I guess it is not really the ⍎, that is slow. The
time scaling is strange.
In the following, the first row and the third row (using ¨ and ⍣ respectively)
scales like n*3, while the p
The *1 ⎕TF* record format is fairly simple (record type (N) followed by the
> variable name (R in the example) , rank, and shape of the value).
> The inverse *1 ⎕TF* tokenizes the string but does, unlike *⍎*, neither parse
> nor execute it.
>
> Please use *SVN 745* since I have
> On Jun 16, 2016, at 8:09 AM, Juergen Sauermann
> wrote:
>
> Hi,
>
> dyadic ? needs a set for filtering out already produced values (the result
> must
> not return duplicate random numbers).
>
> The DOMAIN error is thrown if the size of the set (= right argument of ?)
> becomes
> too large
10
1E10
1E10
1E9×1E9
1E18
?1E10
3942470777
2?1E10
DOMAIN ERROR
2?1E10
^^
Wouldn't anything below 9E18 be parsed as an integer?
Best,
Xiao-Yong
> On Jun 13, 2016, at 9:24 AM, Xiao-Yong Jin wrote:
>
> Yes, they work. Thanks.
>
&
Hi Alex,
It is correct. You need nested vectors to see the effect.
Try the following.
(⊂[2]2 3⍴⍳6)∘.{⍺∘.{⍺+⍵⊣⎕←⍺,'I',⍵}⍵⊣⎕←⍺,'O',⍵}(⊂[2]10×2 3⍴⍳6)
Best,
Xiao-Yong
> On Jun 14, 2016, at 6:39 PM, Alex Weiner wrote:
>
> Hi Bug-APL,
>
> Surely this is not correct:
>
> 5∘.∘.+9
> 14
Hello,
I guess the c++ code is calling the wrong macro.
Before r740:
(⊂'abc'){⍺ ⍵}¨3⍴1
abc 1abc 1abc 1
(⊂'abc'){⍺ ⍵}¨4⍴1
abc 1abc 1abc 1abc 1
After r740:
(⊂'abc'){⍺ ⍵}¨3⍴1
a 1 b 1 c 1
(⊂'abc'){⍺ ⍵}¨4⍴1
INDEX ERROR+
μ-Z__vA_LO_EACH_vB[2] μ-Z[μ-N]←
*before* svn 740 ?
>
> On 2016-06-13 22:11, Xiao-Yong Jin wrote:
>> Hello,
>>
>> It breaks when the left argument is 1. In addition, with the internal
>> macros, the si stack is polluted.
>>
>> 1+/⍳5
>> 1 2 3 4 5
>
> NARS2000 give the
Hello,
It breaks when the left argument is 1. In addition, with the internal macros,
the si stack is polluted.
1+/⍳5
1 2 3 4 5
1{⍺+⍵}/⍳5
INDEX ERROR
μ-Z__pA_LO_REDUCE_X_B[5] μ-T←⊂(⊃μ-B1[μ-H;μ-a-μ-M;μ-L])μ-LO⊃μ-T
^ ^
)si
OAD and )IN).
>
> /// Jürgen
>
>
> On 06/10/2016 10:34 PM, Xiao-Yong Jin wrote:
>> Hi Jürgen,
>>
>> Thanks. I found more floating point reproduction issues.
>>
>> ⎕PP←17
>> x-y←x←○3 4
>> 0 0
>> x-⍎⍕x
>>
Hi Jüergen and Christian,
> On Jun 12, 2016, at 4:28 AM, Juergen Sauermann
> wrote:
>
> the reason is that the arguments of the right function argument of ⍣
> have different lengths and are therefore always unequal:
>
> FIB←{ 3↓ {⍵,+/¯2↑⍵}⍣{(↑⍵)≤¯3+⍴⍺ ⊣ ⎕←'debug:' (⍴⍵) 'vs' (⍴¯3+⍴⍺)} ⊢ ⍵
auermann
> wrote:
>
> Hi Xiao-Yong,
>
> OK - SVN 739.
>
> /// Jürgen
>
>
> On 06/07/2016 08:16 PM, Xiao-Yong Jin wrote:
>> Hi Jürgen,
>>
>> Thanks, though the current behavior still does not give the exact number bit
>> by bit. Can yo
ann
> wrote:
>
> Hi Xiao-Yong,
>
> thanks, fixed in SVN 738.
>
> /// Jürgen
>
>
> On 06/07/2016 08:13 AM, Xiao-Yong Jin wrote:
>> Hello,
>>
>> Is the following behavior intended? Note the x value after load.
>>
>> )cle
Hello,
Is the following behavior intended? Note the x value after load.
)clear
CLEAR WS
x←.12345678901234567890
⎕pp←16
x
0.1234567890123457
)wsid tmp
WAS CLEAR WS
)save tmp
2016-06-07 01:09:15 (GMT-5)
)clear
CLEAR WS
)load tmp
SAVED 2016-06-07 01:
Hi,
I accidentally found this in gnu apl:
(2 3⍴.1×⍳6)+[1]2 3⍴⍳6
1.1 1.2 1.3
4.4 4.5 4.6
I would expect a rank error. Bug or feature?
Hello, perhaps it’s another dfun bug.
)clear
CLEAR WS
∇z←x f y
[1] x{⍺ g ⍵}y
[2] →0
[3] ∇
items_allocated = 16
items[7] = 'yUSER-F2 λ1'xENDLVALUE3«0»→ENDL
idx = 7
==
Assertion failed: 0 && "Bad index"
in Func
Hi Juergen,
Thanks for the script trick. The script in my previous email
works for all the cases when bash is in different places (your
bash script still requires /bin/bash which fails in *BSD, but
/usr/bin/env actually exists for all the systems I have). I
wanted to ask if it is OK for you to c
Hi,
I have trouble passing arguments to script. It seems I have to add '--' to the
command line for the additional argument to be registered without apl
complaining about unknown arguments. In addition, the requirement of
'--script' makes
'/usr/bin/env’ trick (begin the file with '#!/usr/bin
>
> On 05/18/2016 07:29 PM, Kacper Gutowski wrote:
>> On Wed, May 18, 2016 at 5:09 PM, Xiao-Yong Jin wrote:
>> (...)
>>> relying on ¯1=2⊥64⍴1 (always a 64-bit signed integer), for which Dyalog
>>> does differently.
>> I think this is a bug.
>>
>> -k
>>
>
;convert between integers and bit vectors
>>too often (like in bit∆mult) and pre-compute constants like
>>*(⌽¯1+⍳64)* beforehand.
>>
>>/// Jürgen
>>
>>
>>On 05/18/2016 05:44 PM, Elias Mårtenson wrote:
>>>How about implementing
n also call into C/C++ libraries from GNU APL using native functions.
>
> /// Jürgen
>
>
>
>
> On 05/17/2016 07:44 PM, Xiao-Yong Jin wrote:
>> Hi,
>>
>>
>>> On May 17, 2016, at 12:06 PM, Juergen Sauermann
>>>
>>> wrote:
>>
gt; 2
> DOMAIN ERROR
> hook[1] λ←⍵ ⍶ ⍹ ⍵⊣⎕←⍵⊣⎕←⍶⊣⎕←⍹⊣⎕←⍵
> ^^
> please explain the principle to a newbie.
>
> I really want a working examples.
>
>
> Xtian.
>
>
> On 2016-05-17 22:30, Xiao-Yong Jin wrote:
>> They are for direct function (operator?) definitions.
They are for direct function (operator?) definitions. Try:
hook←{⍵⍶⍹⍵}
+hook÷2
2.5
> On May 17, 2016, at 8:24 PM, Christian Robert
> wrote:
>
> hi,
>
> in the result of "]help" I can see:
>
>
> λ { ... } result
> ⍺ { ... } left value argument
> ⍵
ons in implementing a good RNG in APL, please let me know.
>
> c++11 is currently not an option because I would like to not reduce the
> portability of GNU APL onto different platforms.
>
> I'll have a look at the % usage.
>
> /// Jürgen
>
>
>
>
> On 0
Hi,
The LCG used for roll may be fine for some casual uses, but I would really like
to see a higher quality RNG adopted here. Since speed may not be the main
concern here, employing the use of c++11 and preferably using the
std::mt19937_64 seems to be much better for any monte carlo type calc
'a
>
> On Sat, May 14, 2016 at 10:31 PM, Xiao-Yong Jin wrote:
>>
>>> On May 14, 2016, at 7:51 AM, David Tran wrote:
>>>
>>> Hi,
>>>
>>> Newbie study "MasteringDyalogAPL"; got error on page #388 example:
>>>
>
> On May 14, 2016, at 7:51 AM, David Tran wrote:
>
> Hi,
>
> Newbie study "MasteringDyalogAPL"; got error on page #388 example:
>
> 3 0 2 ∘./ 5 1 7
> SYNTAX ERROR
> 3 0 2∘./5 1 7
> ^ ^
>
> bug? ( or this is a specify feature of Dyalog and not APL2 ? )
It’s documented i
> On Apr 13, 2016, at 7:03 PM, Kacper Gutowski wrote:
>
> On Thu, Apr 14, 2016 at 1:54 AM, Xiao-Yong Jin wrote:
>> Exactly so. ‘-Ofast -fno-finite-math-only’ gives correct results.
>> What’s going on here? I don’t expect this has anything to do with NaN or
>> Inf.
Exactly so. ‘-Ofast -fno-finite-math-only’ gives correct results.
What’s going on here? I don’t expect this has anything to do with NaN or Inf.
> On Apr 13, 2016, at 2:13 PM, Jay Foad wrote:
>
> I'd guess -ffinite-math-only.
>
> Jay.
>
> On 13 April 2016 at 1
> * 8 ¯8⋆÷3
> 2 1J1.732050808*
>
> /// Jürgwn
>
>
> On 04/13/2016 03:42 AM, Xiao-Yong Jin wrote:
>> Hi,
>>
>> With the svn version 719,
>>
>> 8 ¯8⋆÷3
>> 2 0.0
>>
>> but with the release version 1.5,
>>
>> 8 ¯8⋆÷3
>> 2 1J1.732050808
>>
>> Best,
>> Xiao-Yong
>>
>>
>>
>
Hi,
With the svn version 719,
8 ¯8⋆÷3
2 0.0
but with the release version 1.5,
8 ¯8⋆÷3
2 1J1.732050808
Best,
Xiao-Yong
89 matches
Mail list logo
