Re: Probably minor bug

; Project:GNU APL >>>> Version / SVN: 1.8 / 1210 >>>> Build Date: 2019-12-19 17:09:01 UTC >>>> Build OS: Linux 4.19.3-200.fc28.x86_64 x86_64 >>>> config.status: >>>> 'PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/lib/pkgconfig' >>>> Archive SVN:1161 >>>> >>>> [moller@hpbox]~tinkering/gnuapl/trunk% gcc --version >>>> 10:49:35 >>>> gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1) >>>> >>>> [moller@hpbox]~tinkering/gnuapl/trunk% cat /etc/redhat-release >>>> 10:51:45 >>>> Fedora release 32 (Thirty Two) >>>> >>>> [moller@hpbox]~tinkering/gnuapl/trunk% uname -a >>>> 10:52:29 >>>> Linux hpbox 5.6.19-300.fc32.x86_64 #1 SMP Wed Jun 17 16:10:48 UTC 2020 >>>> x86_64 x86_64 x86_64 GNU/Linux >>> >> > --- Louis Chrétien lchret...@mac.com

Re: Mistake in documentation of extended dyadic ⍳

ote: >> https://www.gnu.org/software/apl/apl.html#Generalized-dyadic-_005b_003f_005d >> <https://www.gnu.org/software/apl/apl.html#Generalized-dyadic-_005b_003f_005d> >> says >> different from the monadic case (!) >> should say >> different from the standard case (!) > --- Louis Chrétien lchret...@mac.com

Problem building version 1251 on Mac OS X

[] Bif_F12_DOMINO.cc:242:17: note: allocated with 'new[]' here double * data = new double[end]; if (data == 0) WS_FULL; ^ 1 error generated. make[3]: *** [apl-Bif_F12_DOMINO.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 --- Louis Chrétien lchret...@mac.com

Re: Errors building 1199 on Mac OS 10.14.6

doc > > before make should fix this issue. > > Best Regards, > Jürgen > > > > On 11/6/19 2:15 PM, Louis Chrétien via Bugs and suggestions for GNU APL wrote: >> Tried it with 1200 this morning. >> >> Much better, but i still get those 2 warnings

Re: Errors building 1199 on Mac OS 10.14.6

my box). > I have removed a blank which might have been the culprit. > Please let me know if the problem persists. SVN 1200. > > In the meantime you can simply touch the output tiles (apl.info and apl.html). > > Best Regards, > Jürgen > > > On 11/5/19 7:22 PM, Louis

Errors building 1199 on Mac OS 10.14.6

incorrect sectioning?). /Users/lchretien/Subversion/apl/doc//apl.texi:70: Menu reference to nonexistent node `Chapter 4' (perhaps incorrect sectioning?). makeinfo: Removing output file `apl.html' due to errors; use --force to preserve. --- Louis Chrétien lchret...@mac.com

Re: [Bug-apl] Revision 1155: array subscript is below array bounds

ounds] >{ Assert(r < rho_rho); return rho[r]; } > ^ > cc1plus: all warnings being treated as errors > Makefile:2664: recipe for target 'apl-PrimitiveFunction.o' failed > > Thank you. > --- Louis Chrétien lchret...@mac.com

Re: [Bug-apl] Error compiling on Mac OS X 10.13.6

OS earlier, but I don't >> remember >> anymore what the solution was. Any proposals? >> >> /// Jürgen >> >> >> >> On 4/25/19 2:51 PM, Louis Chrétien wrote: >>> I’ve just tried to compile SVN 1140 on Mac OS X 10.13.6, with XCode 10.1. >&

Re: [Bug-apl] *** Spam *** Error compiling on Mac OS X 10.13.6

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 >> anymore what the solution was. Any

[Bug-apl] Error compiling on Mac OS X 10.13.6

o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 --- Louis Chrétien lchret...@mac.com

[Bug-apl] Example workspaces from "APL An Interactive Approach"

chapters would be great. Thanks in advance, --- Louis Chrétien lchret...@mac.com

Re: [Bug-apl] Improved contribution workflow

tunity > presents itself. Regardless of whether you want to adopt git, you will > encounter useful projects that do present their assets as a git repo; you'd > be well-served to know some basic commands such as switching branches and > viewing the commit log. But I wouln't suggest jumping ship from a system with > which you're already comfortable. > > (That said, I *do* have a recommendation for a GNU Autotools replacement: > Meson and Ninja. I've begun to adopt that build toolchain for my personal and > work projects, and am quite pleased with what I've seen so far. For an > example of a small project built using Meson and Ninja, see the xs shell that > I maintain: <https://github.com/TieDyedDevil/XS > <https://github.com/TieDyedDevil/XS>>.) > > -- > "The chain which can be yanked is not the eternal chain." > -- G. Fitch > > --- Louis Chrétien lchret...@mac.com

Re: [Bug-apl] Modulo or residue function is not generating consistent complete residue systems for some arguments

es >>>>>>>>> calculated by MODJ and the builtin residue function and reports >>>>>>>>> discrepancies. The first column of output is the modulo basis, the >>>>>>>>> second column the right argument to the functions, the third column >>>>>>>>> the MODJ result and the fourth column is the builtin residue function >>>>>>>>> result. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Fred >>>>>>>>> >>>>>>>>> Hello Jürgen, >>>>>>>>> SVN 964 moved us in the right direction but not completely out >>>>>>>>> of the >>>>>>>>> woods. SVN 964 still exhibits errors. For instance >>>>>>>>> 2J6 | 5J5 >>>>>>>>> ¯1J7 >>>>>>>>> 2J6 | ¯1J7 >>>>>>>>> ¯3J1 >>>>>>>>> 2J6 | ¯3J1 >>>>>>>>> ¯3J1 >>>>>>>>> I found this and previous residue function errors using the >>>>>>>>> attached APL >>>>>>>>> code files. The files with base name ending in '0' use the builtin >>>>>>>>> residue >>>>>>>>> function. Those with base name ending in '1' use a residue function >>>>>>>>> implemented >>>>>>>>> in APL. The files with base name beginning with 'CRSOTST' test if >>>>>>>>> the order of >>>>>>>>> the complete residue system (CRS) equals the norm of the modulo >>>>>>>>> basis. That >>>>>>>>> test fails for several modulo bases, 2J6 being one of them, using the >>>>>>>>> builtin >>>>>>>>> residue function. No errors are detected with the APL implementation. >>>>>>>>> The other files >>>>>>>>> can be used to plot the CRS for a given modulo basis where 'a' and >>>>>>>>> 'b' in >>>>>>>>> 'a + b * i' are limited to +15 to -15 range. A full screen terminal >>>>>>>>> window is >>>>>>>>> needed to see the plot. >>>>>>>>> My APL implementation of the residue function is very close to >>>>>>>>> what you >>>>>>>>> described in your previous email. Maybe comparing the two >>>>>>>>> implementations will >>>>>>>>> give insight into why the builtin residue function fails for some >>>>>>>>> modulo bases. >>>>>>>>> I make no assertion that my implementation is correct in all >>>>>>>>> aspects. >>>>>>>>> Regards, >>>>>>>>> Fred >>>>>>>>> On Tue, 2017-06-20 at 14:14 +0200, Juergen Sauermann wrote: >>>>>>>>>> Hi Frederick, >>>>>>>>>> >>>>>>>>>> the algorithm for A ∣ B used in GNU APL is this: >>>>>>>>>> >>>>>>>>>> - compute the quotient Q←B÷A, >>>>>>>>>> - "round down" Q to the next (complex) integer Q1, >>>>>>>>>> - return B - Q1×A >>>>>>>>>> >>>>>>>>>> Now the problem seems to be what is meant by "round down". There are >>>>>>>>>> two candidates: >>>>>>>>>> >>>>>>>>>> Q1 ← ⌊ Q i.e. use APL >>>>>>>>>> floor to round down Q >>>>>>>>>> Q1 ← Complex( floor(Q.real(), floor(Q.imag()) ) i,e, use C/C++ >>>>>>>>>> floor() to round down Q. >>>>>>>>>> >>>>>>>>>> In your 5J3 ∣ 14J5 example, the quotient is 2.5J¯0.5, which gives >>>>>>>>>> different results for the APL floor ⌊ and the C/C++ floor(). >>>>>>>>>> >>>>>>>>>> The APL floor ⌊2.5J¯0.5 is 3J¯1 (a somewhat dubious invention in the >>>>>>>>>> ISO standard on page 19, which I used up to >>>>>>>>>> including SVN 963), while the C/C++ floor() is 2J¯1. The difference >>>>>>>>>> between the APL floor and the C/C++ floor is 1.0 which, >>>>>>>>>> multiplied by the divisor, explains the differences that we see. >>>>>>>>>> >>>>>>>>>> As of SVN 964 I have changed the residue function (∣) to use the >>>>>>>>>> C/C++ floor instead of the APL floor. The APL floor and >>>>>>>>>> Ceiling functions (⌊ and ⌈) are still using the apparently broken >>>>>>>>>> definition in the ISO standard. >>>>>>>>>> >>>>>>>>>> I hope this works better for you. At least I am getting this in SVN >>>>>>>>>> 964: >>>>>>>>>> >>>>>>>>>> 5J3 | 14J5 >>>>>>>>>> 1J4 >>>>>>>>>> 5J3 | 1J4 >>>>>>>>>> 1J4 >>>>>>>>>> >>>>>>>>>> whereas SVN 963 was giving: >>>>>>>>>> >>>>>>>>>> 5J3 | 14J5 >>>>>>>>>> ¯4J1 >>>>>>>>>> 5J3 | 1J4 >>>>>>>>>> ¯4J1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> /// Jürgen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 06/19/2017 07:03 PM, Frederick Pitts wrote: >>>>>>>>>>> Jürgen, >>>>>>>>>>> >>>>>>>>>>> With gnu apl (svn 961 on Fedora 25, Intel(R) Core(TM) i7-6700 >>>>>>>>>>> CPU), the residue function (∣) yields the following: >>>>>>>>>>> >>>>>>>>>>> 5J3 ∣ 14J5 >>>>>>>>>>> 1J4 >>>>>>>>>>> 5J3 | 1J4 >>>>>>>>>>> ¯4J1 >>>>>>>>>>> 5J3 | ¯4J1 >>>>>>>>>>> ¯4J1 >>>>>>>>>>> The above result means that two elements in the complete residue >>>>>>>>>>> system >>>>>>>>>>> (CSR) for mod 5J3 are equal, i.e. 1J4 = ¯4J1 mod 5J3, which is not >>>>>>>>>>> allowed. None of the elements of a CSR can be equal modulo the >>>>>>>>>>> CSR's >>>>>>>>>>> basis. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Fred >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> --- Louis Chrétien lchret...@mac.com

Re: [Bug-apl] Free APL reference documentation, any takers?

use of each function in >> addition to the >> abstract explanation as to what it does. >> >> Now, I feel that this documentation doesn't really belong in the Emacs mode. >> It belongs in >> GNU APL itself. Emacs should simply access this from the APL runtime when >> needed, >> >> Thus, I would like to suggest creating an integrated reference documentation >> inside GNU >> APL itself. We could start with what I have in the Emacs mode, and then add >> more. >> >> The following file contains the current documentation in the Emacs mode: >> >> Each element contains three strings: >> >> * Invocation type (monadic, dyadic, etc) >> * Name of the function >> * One-line summary of the function >> * (optional) Longer description >> >> There are two questions: >> >> 1 Is anybody willing to help out with expanding in the reference >> documentation? >> 2 For Jürgen, are you willing to put this into GNU APL itself instead of >> keeping it in the >> Emacs mode? >> >> Regards, >> Elias >> >> > > -- > Br, > /Alexey --- Louis Chrétien lchret...@mac.com

Re: [Bug-apl] Free APL reference documentation, any takers?

cumentation doesn't really belong in the Emacs mode. >> It belongs in >> GNU APL itself. Emacs should simply access this from the APL runtime when >> needed, >> >> Thus, I would like to suggest creating an integrated reference documentation >> inside GNU >> APL itself. We could start with what I have in the Emacs mode, and then add >> more. >> >> The following file contains the current documentation in the Emacs mode: >> >> Each element contains three strings: >> >> * Invocation type (monadic, dyadic, etc) >> * Name of the function >> * One-line summary of the function >> * (optional) Longer description >> >> There are two questions: >> >> 1 Is anybody willing to help out with expanding in the reference >> documentation? >> 2 For Jürgen, are you willing to put this into GNU APL itself instead of >> keeping it in the >> Emacs mode? >> >> Regards, >> Elias >> >> > > -- > Br, > /Alexey --- Louis Chrétien lchret...@mac.com