Hello Juergen,
Is it intentional that the index function ⌷ (squish quad) no longer
accepts near-integer floating point numbers in the left argument? In
the svn 626 version of GNU APL, using near-integer floating points in
the left argument
results in a DOMAIN ERROR. For example
(
gt; thanks again,
>
> Fausto
>
>
>
>
> 2015-04-16 0:01 GMT+02:00 Frederick H. Pitts :
> On Wed, 2015-04-15 at 23:24 +0200, Fausto Saporito wrote:
> Hello Fausto,
>
> Because during the recursion each time
>
o say.
Regards,
Fred
> Hi Fred,
>
>
> thanks a lot.
>
> Now it works... but (maybe it's a stupid question) why that
> change? :-)
>
>
> regards,
>
> Fausto
>
>
>
> 2015-04-15 22:37 GMT+02:00 Frederick H. Pitts
> :
> Faus
Fausto,
Try changing the fourth line to
z←(m-1) ack (m ack (n-1))⋄ →0
Regards,
Fred
On Wed, 2015-04-15 at 21:03 +0200, Fausto Saporito wrote:
> Hello all,
>
>
> I'm trying to implement ackerman function, but I got no luck ... and I
> cannot understand why this code doesn't work:
>
>
> --noCIN).
>
> /// Jürgen
>
>
> On 09/15/2014 06:02 PM, Frederick H. Pitts wrote:
>
> > Hello Juergen,
> >
> > 1) Up until at svn 443, ⍞ references were from the terminal for shell
> > scripts and files processed with 'apl -f'. Sure o
So far everything looks OK, at least on my machine. Of cause you could
> argue
> if reading from stdin was a good choice in the first place. I believe
> it was because:
>
> - you cannot assume to always have a usable terminal
> - testcase files (for testing ⍞ in particular)
>
hello ← from script
> What is your name? Jürgen ← from stdin
> Hello Jürgen
>
> If your box behaves differently then I need more details.
>
> /// Jürgen
>
>
>
> On 09/13/2014 03:31 AM, Frederick H. Pitts wrote:
>
> > Gen
Gentle people,
As of SVN 470, ⍞ references are taking their input from the APL source
file instead of the terminal if there is any source file left to be
read. It appears that the interpreter is starting to execute code
before the interpreter has completely consumed the source file and is
ne into the buffer.
> * if numlock is on, treat KP_Enter like Return and send the line
> to APL.
>
> cm
>
>
> On 08/13/14 17:03, Frederick H. Pitts wrote:
>
> > Hello Chris,
> >
> > Please consider 1) filtering out whether the 'Num
Hello Chris,
Please consider 1) filtering out whether the 'NumLock' is active or not
when you test the key event state is 0 and keyval is GDK_KEY_Return and
2) adding support for a keyval of GDK_KEY_KP_Enter in the same test.
Then using the numeric keypad with aplwrap would be a lot more p
ic !, the result of the Gamma
> function has to be computed which of course is much more expensive.
>
>
> Regards,
> Elias
>
>
> On 7 August 2014 11:15, Frederick H. Pitts
> wrote:
> Hello Juergen,
>
> I reran timing te
re GNU APL calls libm functions
> and replacing them all by more exact versions would be rather tedious.
> There are often speed-precision trade-offs involved. Normally the
> precision of libm functions is good enough. Let's fix issues on a
> case-by-case basis when we find them.
>
Normally the
> precision of libm functions is good enough. Let's fix issues on a
> case-by-case basis when we find them.
>
> /// Jürgen
>
>
> On 08/06/2014 03:06 AM, Frederick H. Pitts wrote:
>
> > Gentle people,
> >
> > Please find attached bi
Gentle people,
Please find attached binom.apl.tgz. It contains the source for BINOM,
a defined function does what the primitive dyadic ! function does but
produces exact results over a larger range.
BINOM produces 1) the same results as ! over the range where !
produces exact int
rade-off. Computing
> N! in 64-bit integer can
> take up to 20 multiplications while the float variant is probably faster.
>
> /// Jürgen
>
>
> On 08/05/2014 06:45 AM, Frederick H. Pitts wrote:
> > Hello Elias,
> >
> > 1) "MOST-NEGATIVE-FIXNUM&
difficult to implement I think. Perhaps I'll try that one
> day unless Jürgen is completely against the idea.
>
>
> Regards,
> Elias
>
>
> On 5 August 2014 09:37, Frederick H. Pitts
> wrote:
> Juergen,
>
> Please co
Juergen,
Please consider the following:
( 62 ⍴ 2 ) ⊤ ⎕ ← 2 ⊥ 53 ⍴ 1
9007199254740991
0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
( 62 ⍴ 2 ) ⊤ ⎕ ← 2 ⊥ 54 ⍴ 1
18014398509481984
0 0 0 0 0 0 0 1
Jurgen,
The last comment in the listing below summarizes the issue. The input
file for the listing is attached.
Regards
Fred
Retired Chemical Engineer
⎕PP ← 16
⍝ Compute first 5, 14th, 15th, 70th and 71th Fibonacci numbers
using
⍝ Binet's formula
(http://www.math.ru
Hello David,
Thanks for the utility.
May I suggest a minor tweak?
' e: show names having any character not in set'
should read
' e: show names having only characters not in set'
The former implies
]nlf e ⍙
would list, for instance, ⍙class, because c,
e a one-line solution that (like David's) is O(n) but does not use
> an explicit loop?
>
>
> Regards,
> Elias
>
>
> On 4 July 2014 09:12, Frederick H. Pitts
> wrote:
> Elias,
>
> While Jurgen's solution is corr
Elias,
While Jurgen's solution is correct for the problem as you stated it,
'Problem 3 - Tell a Fib' in
https://studentcompetitions-general.s3.amazonaws.com/testing-challenge/dyalog/2014%20PhaseI%20Problems.pdf
actually asks for the first n Fibonacci numbers, not the Fibonacci
sequence up
Elias,
My keyboard is configured to have ⍶, ⍹, and ⍷ above ⍺, ⍵ and ∊,
respectively, so that their locations are easy to remember. I would
have
liked to placed ⍙ above ∆ but that location was already occupied by ⍋,
so I placed ⍙ above ⌊ on the 'd' key.
Regards
Fred
On Fri, 2014-06-27 a
Hello Juergen,
For sometime now, I've noticed that the first line of the )DUMP command
output is
#!/usr/local/bin//usr/local/bin --script --
Is this correct?
#!/usr/local/bin/apl --script --
seems more appropriate.
Regards,
Fred
Retired Chemical Engineer
Hello Blake,
Two questions:
1) Should the ' ∆ ' (capital delta) appearing on lines 256, 257, 259,
261, 263, 267, and 271 of Editor.apl be ' ◇ ' (diamond). From the
context, it appears that statement separators are needed, not an
uninitialized variable?
2) Is the first line
Hello David,
FYI, Figure 8, on page 49 of IBM's "APL2 Programming: Language
Reference" (2nd ed, Feb 1994) says an empty character vector displays as
a blank line.
Regards,
Fred
On Tue, 2014-05-27 at 12:32 -0700, David B. Lamkins wrote:
> I find this confusing and counterintuitive.
>
>
Blake,
If you are looking for instant gratification,
⍞ ← (⎕UCS 27), '[2J'
will do the job on any terminal that honors ansi escape sequences.
Regards,
Fred
Retired Chemical Engineer
On Mon, 2014-05-26 at 19:29 -0500, Blake McBride wrote:
> Dear Elias,
>
>
> On one hand, I would still
r
the real part.
Regards,
Fred
On Tue, 2014-05-20 at 18:09 +0200, Juergen Sauermann wrote:
> Hi Fred, Elias,
>
> fixed in SVN 279.
>
> I dared to print the (non-zero) imaginary part even if the standard
> tells otherwise.
>
> /// Jürgen
>
>
> On 05/20/2014 07
to use it.
>
>
> I am sure there are many ways to skin a cat, or solve this problem. I
> think mine is cleaner.
>
>
> Thanks for your input!
>
>
> Blake
>
>
>
>
>
>
> On Mon, May 19, 2014 at 10:34 PM, Frederick H. Pitts
&g
>
>
> Then:
>
>
> Note: Any imaginary-part of the numeric input to
> Numeric-Output-Conversion is simply ignored; only the
> real-part of a complex-number is used.
>
>
> Regards,
> Elias
>
>
> On 20 May 2014 12:24, Frederick
Juergen,
Under "Display of Complex Numbers:" on page 13 of the "APL2
Programming: Language reference", the document says:
"In J notation, the real or imaginary part is not displayed if it is
less than the other by more than ⎕PP orders of magnitude (unless ⎕PP is
at its maximum)".
array, or nested
> array containing anything including ''.
>
>
> Given the above, neither ⊃ and ⊂, nor your code can handle those
> parameters. Box / unbox can.
>
>
> Thanks.
>
>
> Blake
>
>
>
>
>
>
>
>
> On Sun, May
Hello Blake,
After having asked you to present a use case where the behavior of
box/unbox differs from enclose/disclose and you graciously replied, I
felt obligated to spend a little time studying the issue. I did that
and have come to the conclusion that both boxed and nested arrays are
Blake,
Thanks for the detailed response. I understand the issue more clearly
now.
I think I would ask the user to reshape scalar arguments to vectors
(e.g. (1⍴'k')(1⍴'v')). But then, that is as onerous as having to
remember to use box everywhere its required.
Regards,
Fred
On
Hello Blake,
Please present at least one use case where box/unbox behavior differs
from ⊂/⊃ behavior. For all the use cases you present in your email, I
do not believe there is a difference.
Regards,
Fred Pitts
Retired Chemical Engineer
On Tue, 2014-05-13 at 09:00 -0500, Blake McBride
Hello Jürgen,
Web page http://www.gnu.org/software/apl/apl.html#Chapter-3 states Gnu
APL integers are 64-bit wide, thus ranging from -9223372036854775808 to
9223372036854775807.
As a naive user, I expect that to mean I can do accurate integer
addition and subtraction in the above
not get mislead into thinking that they can
perform accurate integer arithmetic on larger or smaller numbers.
Regards,
Fred
On Wed, 2014-03-12 at 01:01 +0100, Kacper Gutowski wrote:
> On 2014-03-11 17:29:08, Frederick H. Pitts wrote:
> > If one executes
> >
> > i
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.
Hope the above helps isolate the problem.
Regards,
Fred
On Tue, 2014-03-11 at 10:54 -0500, Frederick H. Pitts wrote
Gentle people,
And
9223372036854775807 + ¯9223372036854775808
0
is not correct either.
Regards,
Fred
On Tue, 2014-03-11 at 23:32 +0800, Elias Mårtenson wrote:
> Running ⎕SYL shows the following:
>
>
> largest integer 9223372036854775807
>
>
>
Gentle people,
In Gnu APL file file_io.cc, lines 597, 617, and 643, `[]' should be
inserted between the `delete' and `del' to match the `new char
[ bytes ... ]' on lines 591, 612, and 636, respectively.
Regards,
Fred
Retired Chemical Engineer
ED foreground
>
> 'Hello',ESCSEQ,'World'
> HelloWorld
>
> Note that ⎕UCS is more portable than ⎕AV or ⎕AF.
>
> /// Jürgen
>
>
> On 02/14/2014 10:04 PM, Frederick H. Pitts wrote:
>
> > Gentle people,
> >
> > Is ther
Gentle people,
Is there a way for a Gnu APL program to send ANSI escape sequences to
the terminal in which the iterpreter is running?
If not, I wish to propose the following: The ⍞ handling be extended by
implementing an alternative mode where only the content of the last
assign
Gentle people,
Please exercise the attached SHALLIT0.tc.gz to confirm that a DOMAIN
ERROR occurs on the last executable statement. I'm currently using Gnu
APL, svn 117.
It appears that the DOMAIN ERROR occurs when the * function is applied
to
P * 0 1 0
where 0 1 0 is th
Gentle persons,
On page 41 of ISO/IEC 13751:2000(E), the literal-identifier (which is
the same thing as a variable name) is defined to be composed of a letter
followed by zero or more letters, digits, underbars and overbars. The
overbar is also used to distinguish negative numbers per the
Elias,
This approach to optimizating Gnu APL sounds very reasonable to me. I
hope it succeeds. May Conway's "Game of Life" go faster. :-)
Fred
On Sun, 2014-02-02 at 21:19 +0800, Elias Mårtenson wrote:
> I made a test implementation of a performance optimisation for GNU
> APL. The short
Gentle people,
When I attempt to run the attached life.apl.gz (after uncompressing)
with
apl -f life.apl
partial output occurs and then "SYSTEM LIMIT (fun_oper) appears with the
offending apl statement after that. Investigation of the interpreter
source code reveals the "SYSTEM
u use -T -- cool!
>
> Best Regards,
> Juergen
>
>
>
> On 01/29/2014 06:01 AM, Frederick H. Pitts wrote:
> > Gentle people,
> >
> > Please find attached QUADTF.tc.gz. gunzip it and run apl (svn rev 110)
> > thus
> >
> > apl --TM 2 -T QUA
Gentle people,
Please find attached QUADTF.tc.gz. gunzip it and run apl (svn rev 110)
thus
apl --TM 2 -T QUADTF.tc
Examine QUADTF.tc.log and observe that the SCORES variable is not being
reconstructed in the workspace with either the migration or extended
form of the inve
> ad 3)
> I have changed that as you proposed, SVN 111.
>
> And yes, I am interested in bringing down the number of memory leaks.
>
> Best Regards,
> Jürgen
>
>
> On 01/27/2014 10:30 PM, Frederick H. Pitts wrote:
> > Gentle people,
> >
> > v
Gentle people,
[I'm resending this email because I left the `[Bug-apl]' prefix off the
the subject line in the previous email. Also I've added some additional
valgrind detected memory errors.]
valgrind runs with options --leak-check=full
--show-leak-kinds=all --track-origins=yes
Gentle people,
valgrind runs with options --leak-check=full --show-leak-kinds=all
--track-origins=yes --read-var-info=yes against Gnu APL, svn rev. 107,
reveals the following:
1) 'new' invocation on line Value.cc:103 needs to be paired with a
'delete []' invocation on line Value.c
50 matches
Mail list logo
