Hi Blake,
thanks, fixed in SVN 440.
Single ^C aborts ⍞ and double ^C raises an interrupt.
/// Jürgen
On 08/14/2014 01:08 AM, Blake McBride
wrote:
)CLEAR
CLEAR WS
∇test;x
Hi Peter,
good, take your time.
I am not very familiar with Macs but I suppose you can add an
external USB keyboard? In that case I would leave the ⍙ on
AltShift-.
because the default keyboard shown by the ]KEYBOARD command has
is there and on AltShift-H
Looks great. Thanks!
On Thu, Aug 21, 2014 at 8:02 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi Blake,
>
> thanks, fixed in SVN 440.
> Single ^C aborts ⍞ and double ^C raises an interrupt.
>
> /// Jürgen
>
>
> On 08/14/2014 01:08 AM, Blake McBride wrote:
>
>)CLEAR
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 si
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
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:
I've been puzzled by the interaction between GNU APL and aplwrap, in which
⎕ and ⍞ output doesn't appear until APL prompts for input. This behavior is
bad for the case where the program tries to emit periodic progress messages
during long computations.
It turns out that the C++ std lib is responsi
Oops. Here's the same patch, but inquiring about the correct file
descriptor.
(It'll work either way in some cases...)
On Thu, Aug 21, 2014 at 8:06 PM, David Lamkins wrote:
> I've been puzzled by the interaction between GNU APL and aplwrap, in which
> ⎕ and ⍞ output doesn't appear until APL pr
