[Bug-apl] GNU APL port for OpenBSD

[Giuseppe Cocomazzi]

Hi list,
I have ported GNU APL to the OpenBSD operating system, and I kindly ask
you to consider the possibility of merging the following changes to the
source tree, in order to enable a better support for the OS. As you can
see, only few lines are needed.

Also, I recollected some info about the steps needed to configure
the environment (fonts, keyboard), not necessarily addressed
at users of this OS but of any Unix-like system in general:

http://sbudella.altervista.org/blog/20170821-apl-openbsd.html

And here are the two patches:

--- configure.orig  Fri Mar 17 16:03:06 2017
+++ configure   Mon Jul 17 17:11:15 2017
@@ -21413,7 +21413,7 @@ echo
 #
 echo "configure: creating $srcdir/src//buildtag.hh"
 rm -f $srcdir/src/buildtag.hh
-cd $srcdir/src ; source ./buildtag ; cd ..
+cd $srcdir/src ; . ./buildtag ; cd ..

 # create src/makefile.h
 #

--- src/Common.cc.orig  Fri Mar 17 15:46:53 2017
+++ src/Common.cc   Mon Jul 17 16:37:56 2017
@@ -81,6 +81,11 @@ void
 init_1(const char * argv0, bool log_startup)
 {
 rlimit rl;
+
+#ifndef RLIMIT_AS
+# define RLIMIT_AS RLIMIT_DATA
+#endif
+
getrlimit(RLIMIT_AS, &rl);
total_memory = rl.rlim_cur;


--
Giuseppe Cocomazzi
My self is steam

http://sbudella.altervista.org

Re: [Bug-apl] GNU APL port for OpenBSD

[Juergen Sauermann]

  
  
Hi Giuseppe,
  
  thanks for submitting the patches. I have included them into SVN
1001.
  
  The first patch is now in Makefile.am as opposed to configure.
  That suggests that you
  are using an older version of the GNU APL sources. Maybe the one
  from the GNU APL
  home page at gnu.org or a gnu mirror. The "official" GNU
  APL releases happen quite
  rarely (like every one or two years) and therefore they quickly
  become outdated. If you
  are porting GNU APL then it is better to check out the latest
  version from SVN.
  
  Regarding your web link below, I wonder how persistent it is? If
  the link is supposed to
  last for a longer period, then we could point to it from out community
  web page
  http://www.gnu.org/software/apl/Community.html
  and/or mention it in our README-6-porting
  file.
  
  Best Regards,
  /// Jürgen Sauermann
  

On 08/28/2017 10:44 AM, Giuseppe
  Cocomazzi wrote:


  Hi list,
I have ported GNU APL to the OpenBSD operating system, and I kindly ask
you to consider the possibility of merging the following changes to the
source tree, in order to enable a better support for the OS. As you can
see, only few lines are needed.

Also, I recollected some info about the steps needed to configure
the environment (fonts, keyboard), not necessarily addressed
at users of this OS but of any Unix-like system in general:

http://sbudella.altervista.org/blog/20170821-apl-openbsd.html

And here are the two patches:

--- configure.orig  Fri Mar 17 16:03:06 2017
+++ configure   Mon Jul 17 17:11:15 2017
@@ -21413,7 +21413,7 @@ echo
 #
 echo "configure: creating $srcdir/src//buildtag.hh"
 rm -f $srcdir/src/buildtag.hh
-cd $srcdir/src ; source ./buildtag ; cd ..
+cd $srcdir/src ; . ./buildtag ; cd ..

 # create src/makefile.h
 #

--- src/Common.cc.orig  Fri Mar 17 15:46:53 2017
+++ src/Common.cc   Mon Jul 17 16:37:56 2017
@@ -81,6 +81,11 @@ void
 init_1(const char * argv0, bool log_startup)
 {
 rlimit rl;
+
+#ifndef RLIMIT_AS
+# define RLIMIT_AS RLIMIT_DATA
+#endif
+
getrlimit(RLIMIT_AS, &rl);
total_memory = rl.rlim_cur;


--
Giuseppe Cocomazzi
My self is steam

http://sbudella.altervista.org





  

[Bug-apl] )help text displayed for encode and decode functions

[Frederick Pitts]

Hello all,

Gnu-APL (svn 996) yields the following:

  )help ⊤
dyadic function:  Z ← A ⊤ B  (Encode)
Z is the representation of A in the number system whose radices are
B

and

  )help ⊥
dyadic function:  Z ← A ⊥ B  (Decode)
Z is the values of array A evaluated in a number system with
radices B

The 'A' and 'B' in the second line of each )help output needs
to be swapped to be consistent with "APL2 Programming:
Language Reference", page 90 and 116.

Regards

Fred

Re: [Bug-apl] )help text displayed for encode and decode functions

[Juergen Sauermann]

  
  
Hi Fred,
  
  thanks, fixed in SVN 1002.

/// Jürgen


On 08/28/2017 05:42 PM, Frederick Pitts
  wrote:


  Hello all,

	Gnu-APL (svn 996) yields the following:

  )help ⊤
dyadic function:  Z ← A ⊤ B  (Encode)
Z is the representation of A in the number system whose radices are
B

and

  )help ⊥
dyadic function:  Z ← A ⊥ B  (Decode)
Z is the values of array A evaluated in a number system with
radices B

	The 'A' and 'B' in the second line of each )help output needs
to be swapped to be consistent with "APL2 Programming:
Language Reference", page 90 and 116.

Regards

Fred





  

Re: [Bug-apl] Assertion failed

[Ala'a Mohammad]

Hi,

I do not know if this is the same cause, but the assertion seems to be the same

in a new session do the following
- write an incorrect name like 'x.y'
- edit a function like 'z'
- save the function
- edit the z function again, and you get the failed assertion

I'm running the latest APL version from svn:
: apl --version
BUILDTAG:
-
Project:GNU APL
Version / SVN:  1.7 / 1003M
Build Date: 2017-08-28 18:02:08 UTC
Build OS:   Linux 3.13.0-37-generic x86_64
config.status:  'RATIONAL_NUMBERS_WANTED=yes'
Archive SVN:989

Here is a session sample:
--

  x.y
VALUE ERROR
  x.y
^
  ∇z
  ∇z

==
Assertion failed: items
in Function:  at
in file:  ../Simple_string.hh:277

Call stack:


-- Stack trace at ../Simple_string.hh:277

0x7F2ECE271184
0x7F2EC8FF0BDE  connection_loop(void*)
0x7F2EC8FF40FE   NetworkConnection::run()
0x7F2EC8FF30CBNetworkConnection::process_command(std::string const&)
0x7F2EC8FECCA7 FnCommand::run_command(NetworkConnection&,
std::vector > const&)
0x45EA0F  do_Assert(char const*, char const*, char const*, int)


SI stack:

Depth:  0
Exec:   0xbaf770
Safe exec:  0
Pmode:  ◊  x.y
PC: 0 (5) 'y
Stat:   x.y
err_code:   0x30001
thrown at:  Symbol.cc:683
e_msg_1:'VALUE ERROR'
e_msg_2:'  x.y'
e_msg_3:'^'


==
terminate called after throwing an instance of 'ErrorCode'

Process apl aborted


Hope It Helps

Regards,

Ala'a





On Tue, Aug 8, 2017 at 2:18 PM, Elias Mårtenson  wrote:
> If that's the case, then you are indeed right. It's possible that the
> std::string constructor will work, but that would be more out of luck than
> anything else.
>
> Regards,
> Elias
>
> On 8 August 2017 at 18:11, Juergen Sauermann 
> wrote:
>>
>> Hi Elias,
>>
>> correct, except that an UCS8_string is not a string, despite of its name.
>> UCS8_strings have no terminating 0 byte; the 0-byte is only appended if
>> the UCS8_string is converted to a C string with function c_str().
>>
>> /// Jürgen
>>
>>
>> On 08/08/2017 09:28 AM, Elias Mårtenson wrote:
>>
>> Sorry for not replying earlier, I forgot about this message.
>>
>> ucs[0] should be OK for an empty string, as that will still refer to the
>> terminating NUL byte at the end of the string. Note that an empty string is
>> differetn from a NULL pointer (the former is a valid string, and the other
>> is not).
>>
>> Regards,
>> Elias
>>
>> On 1 August 2017 at 19:04, Juergen Sauermann
>>  wrote:
>>>
>>> Hi Elias,
>>>
>>> I don't know what Ala'a did. However, looking at:
>>>
>>> /// return a UTF8 encoded std:string
>>> inline std::string to_string(const UCS_string & ucs)
>>> {
>>> const UTF8_string utf(ucs);
>>> return string((const char *)&utf[0], utf.size());
>>> }
>>>
>>> I am not sure what happens if string ucs is empty (in that case ucs[0]
>>> does not
>>> exist and may be makes &ucs[0] also 0. The std::string constructor then
>>> looks
>>> for the terminating 0 character in a 0-pointer. Using
>>> UTF8:string::c_str() might
>>> be better.
>>>
>>> Also converting a UCS or UTF8 string to std::string just for outputting
>>> it with << may be
>>> an overkill, since ostream << often (read: after #include
>>> "PrintOperator.hh") understands
>>> UCF and UCS strings directly.
>>>
>>> /// Jürgen
>>>
>>>
>>> On 07/31/2017 02:31 AM, Elias Mårtenson wrote:
>>>
>>> Can you tell me exactly what you are doing in order to reproduce the
>>> problem?
>>>
>>> Regards,
>>> Elias
>>>
>>>
>>
>>
>

Re: [Bug-apl] GNU APL port for OpenBSD

[Giuseppe Cocomazzi]

Hi Jürgen,
thanks for your reply.
Ported software on OpenBSD is submitted for inclusion in the so-called
"port tree", basically a set of custom Makefiles by means of which
ports can be automatically downloaded, built, packaged and installed
with a single "make" command. The port tree is part of the operating
system, and importing rolling releases from SVN is not an option.
Therefore, the official releases on the GNU mirrors are perfectly fine
for the goal. Furthermore, I feel more comfortable in submitting
stable and mature releases, as another goal of the OS is stability,
security and cleanliness.

As I am also the maintainer of the port/package, I will update the
port's Makefile every time a major release is announced.

As for the link to my blog/notebook, I have been actively maintaining
my homepage for 8 years, my hosting service is quite stable and I have
intention to keep the page away from oblivion. I think then it is
reasonably safe to refer to it.

Thank you very much.

On Mon, Aug 28, 2017 at 3:09 PM, Juergen Sauermann
 wrote:
> Hi Giuseppe,
>
> thanks for submitting the patches. I have included them into SVN 1001.
>
> The first patch is now in Makefile.am as opposed to configure. That suggests
> that you
> are using an older version of the GNU APL sources. Maybe the one from the
> GNU APL
> home page at gnu.org or a gnu mirror. The "official" GNU APL releases happen
> quite
> rarely (like every one or two years) and therefore they quickly become
> outdated. If you
> are porting GNU APL then it is better to check out the latest version from
> SVN.
>
> Regarding your web link below, I wonder how persistent it is? If the link is
> supposed to
> last for a longer period, then we could point to it from out community web
> page
> http://www.gnu.org/software/apl/Community.html and/or mention it in our
> README-6-porting
> file.
>
> Best Regards,
> /// Jürgen Sauermann
>
>
> On 08/28/2017 10:44 AM, Giuseppe Cocomazzi wrote:
>
> Hi list,
> I have ported GNU APL to the OpenBSD operating system, and I kindly ask
> you to consider the possibility of merging the following changes to the
> source tree, in order to enable a better support for the OS. As you can
> see, only few lines are needed.
>
> Also, I recollected some info about the steps needed to configure
> the environment (fonts, keyboard), not necessarily addressed
> at users of this OS but of any Unix-like system in general:
>
> http://sbudella.altervista.org/blog/20170821-apl-openbsd.html
>
> And here are the two patches:
>
> --- configure.orig  Fri Mar 17 16:03:06 2017
> +++ configure   Mon Jul 17 17:11:15 2017
> @@ -21413,7 +21413,7 @@ echo
>  #
>  echo "configure: creating $srcdir/src//buildtag.hh"
>  rm -f $srcdir/src/buildtag.hh
> -cd $srcdir/src ; source ./buildtag ; cd ..
> +cd $srcdir/src ; . ./buildtag ; cd ..
>
>  # create src/makefile.h
>  #
>
> --- src/Common.cc.orig  Fri Mar 17 15:46:53 2017
> +++ src/Common.cc   Mon Jul 17 16:37:56 2017
> @@ -81,6 +81,11 @@ void
>  init_1(const char * argv0, bool log_startup)
>  {
>  rlimit rl;
> +
> +#ifndef RLIMIT_AS
> +# define RLIMIT_AS RLIMIT_DATA
> +#endif
> +
> getrlimit(RLIMIT_AS, &rl);
> total_memory = rl.rlim_cur;
>
>
> --
> Giuseppe Cocomazzi
> My self is steam
>
> http://sbudella.altervista.org
>
>
>



-- 
Giuseppe Cocomazzi
My self is steam.

http://sbudella.altervista.org

Re: [Bug-apl] Assertion failed

[Ala'a Mohammad]

Hi,

Trying to reduce the steps above to 'define, save, define' gives the
same thing above. This only happens when the defined function is saved
without a body (saved only with the header).

Network listener started. Connection information: mode:tcp addr:35039
  ∇x
  ∇x

==
Assertion failed: items
in Function:  at
in file:  ../Simple_string.hh:277

Call stack:


-- Stack trace at ../Simple_string.hh:277

0x7F2D7FEEC184
0x7F2D7AC6BBDE  connection_loop(void*)
0x7F2D7AC6F0FE   NetworkConnection::run()
0x7F2D7AC6E0CBNetworkConnection::process_command(std::string const&)
0x7F2D7AC67CA7 FnCommand::run_command(NetworkConnection&,
std::vector > const&)
0x45EA0F  do_Assert(char const*, char const*, char const*, int)


SI stack:


==
terminate called after throwing an instance of 'ErrorCode'

Process apl aborted


On Mon, Aug 28, 2017 at 10:10 PM, Ala'a Mohammad  wrote:
> Hi,
>
> I do not know if this is the same cause, but the assertion seems to be the 
> same
>
> in a new session do the following
> - write an incorrect name like 'x.y'
> - edit a function like 'z'
> - save the function
> - edit the z function again, and you get the failed assertion
>
> I'm running the latest APL version from svn:
> : apl --version
> BUILDTAG:
> -
> Project:GNU APL
> Version / SVN:  1.7 / 1003M
> Build Date: 2017-08-28 18:02:08 UTC
> Build OS:   Linux 3.13.0-37-generic x86_64
> config.status:  'RATIONAL_NUMBERS_WANTED=yes'
> Archive SVN:989
>
> Here is a session sample:
> --
>
>   x.y
> VALUE ERROR
>   x.y
> ^
>   ∇z
>   ∇z
>
> ==
> Assertion failed: items
> in Function:  at
> in file:  ../Simple_string.hh:277
>
> Call stack:
>
> 
> -- Stack trace at ../Simple_string.hh:277
> 
> 0x7F2ECE271184
> 0x7F2EC8FF0BDE  connection_loop(void*)
> 0x7F2EC8FF40FE   NetworkConnection::run()
> 0x7F2EC8FF30CBNetworkConnection::process_command(std::string const&)
> 0x7F2EC8FECCA7 FnCommand::run_command(NetworkConnection&,
> std::vector > const&)
> 0x45EA0F  do_Assert(char const*, char const*, char const*, int)
> 
>
> SI stack:
>
> Depth:  0
> Exec:   0xbaf770
> Safe exec:  0
> Pmode:  ◊  x.y
> PC: 0 (5) 'y
> Stat:   x.y
> err_code:   0x30001
> thrown at:  Symbol.cc:683
> e_msg_1:'VALUE ERROR'
> e_msg_2:'  x.y'
> e_msg_3:'^'
>
>
> ==
> terminate called after throwing an instance of 'ErrorCode'
>
> Process apl aborted
>
>
> Hope It Helps
>
> Regards,
>
> Ala'a
>
>
>
>
>
> On Tue, Aug 8, 2017 at 2:18 PM, Elias Mårtenson  wrote:
>> If that's the case, then you are indeed right. It's possible that the
>> std::string constructor will work, but that would be more out of luck than
>> anything else.
>>
>> Regards,
>> Elias
>>
>> On 8 August 2017 at 18:11, Juergen Sauermann 
>> wrote:
>>>
>>> Hi Elias,
>>>
>>> correct, except that an UCS8_string is not a string, despite of its name.
>>> UCS8_strings have no terminating 0 byte; the 0-byte is only appended if
>>> the UCS8_string is converted to a C string with function c_str().
>>>
>>> /// Jürgen
>>>
>>>
>>> On 08/08/2017 09:28 AM, Elias Mårtenson wrote:
>>>
>>> Sorry for not replying earlier, I forgot about this message.
>>>
>>> ucs[0] should be OK for an empty string, as that will still refer to the
>>> terminating NUL byte at the end of the string. Note that an empty string is
>>> differetn from a NULL pointer (the former is a valid string, and the other
>>> is not).
>>>
>>> Regards,
>>> Elias
>>>
>>> On 1 August 2017 at 19:04, Juergen Sauermann
>>>  wrote:

 Hi Elias,

 I don't know what Ala'a did. However, looking at:

 /// return a UTF8 encoded std:string
 inline std::string to_string(const UCS_string & ucs)
 {
 const UTF8_string utf(ucs);
 return string((const char *)&utf[0], utf.size());
 }

 I am not sure what happens if string ucs is empty (in that case ucs[0]
 does not
 exist and may be makes &ucs[0] also 0. The std::string constructor then
 looks
 for the terminating 0 character in a 0-pointer. Using
 UTF8:string::c_str() might
 be better.

 Also converting a UCS or UTF8 string to std::string just for outputting
 it with << may be
 an overkill, since ostream << often (read: after #include
 "PrintOperator.hh") understands
 UCF and UCS strings directly.

Re: [Bug-apl] )help text displayed for encode and decode functions

[Frederick Pitts]

Hello again,

Please ignore the previous email.  I now see corrections were
made somewhere between svn 996 and 1003.  My bad.

Regards,

Fred

On Mon, 2017-08-28 at 10:42 -0500, Frederick Pitts wrote:
> Hello all,
> 
>   Gnu-APL (svn 996) yields the following:
> 
>   )help ⊤
> dyadic function:  Z ← A ⊤ B  (Encode)
> Z is the representation of A in the number system whose radices
> are
> B
> 
> and
> 
>   )help ⊥
> dyadic function:  Z ← A ⊥ B  (Decode)
> Z is the values of array A evaluated in a number system with
> radices B
> 
>   The 'A' and 'B' in the second line of each )help output needs
> to be swapped to be consistent with "APL2 Programming:
> Language Reference", page 90 and 116.
> 
> Regards
> 
> Fred
> 

[Bug-apl] Access to rational number numerator and denominator

[Frederick Pitts]

Hello,

Is there an existing mechanism for accessing rational number
numerator and denominator parts analogous to that for accessing complex
number real and imaginary parts?  If yes, please let me know how.  If
no, can a mechanism be implemented?

Respectfully,

Fred

Re: [Bug-apl] Access to rational number numerator and denominator

[Louis de Forcrand]

Hi,

No APL kb with me right now, sorry :(

1 LCM n

gives the numerator of a fraction (floating or exact). If you need the 
denominator, do the same with the inverse of n. If you need both, for example:

1 LCM n POW 1 _1

Cheers,
Louis

> On 28 Aug 2017, at 23:24, Frederick Pitts  wrote:
> 
> Hello,
> 
>Is there an existing mechanism for accessing rational number
> numerator and denominator parts analogous to that for accessing complex
> number real and imaginary parts?  If yes, please let me know how.  If
> no, can a mechanism be implemented?
> 
> Respectfully,
> 
> Fred
> 

Re: [Bug-apl] Access to rational number numerator and denominator

[Frederick Pitts]

Louis,

Thanks for the quick response.

After working with the technique a bit, I observe that as long
as the rational number denominator is well within the range of integers
representable by floating numbers, 1 ∧ n returns the correct result.
But if the absolute value of the denominator exceeds 2 ⋆ 35, the
technique returns incorrect results.  For instance,

  fiMax ← × / 53 ⍴ 2 ⍝ largest integer 53-bit f.p. mantissa holds
  fiMax
╔╗
║9007199254740992║
╚╝
  1 ∧ fiMax ⍝ Correct result for fiMax
╔╗
║9007199254740992║
╚╝
  1 ∧ ÷ fiMax ⍝ Incorrect result. 1 is numerator of reciprocal.
╔═╗
║0║
╚═╝

I was hoping to be able to access correct rational number parts
even when they approach the ⎕SYL[20;2] limit of 920.
It seems a shame to loose so much of the integer range because floating
point operations are sneaking into the numerator and denominator access
methods.

Regards,

Fred

On Tue, 2017-08-29 at 00:08 +0200, Louis de Forcrand wrote:
> Hi,
> 
> No APL kb with me right now, sorry :(
> 
> 1 LCM n
> 
> gives the numerator of a fraction (floating or exact). If you need
> the denominator, do the same with the inverse of n. If you need both,
> for example:
> 
> 1 LCM n POW 1 _1
> 
> Cheers,
> Louis
> 
> > On 28 Aug 2017, at 23:24, Frederick Pitts 
> > wrote:
> > 
> > Hello,
> > 
> >Is there an existing mechanism for accessing rational number
> > numerator and denominator parts analogous to that for accessing
> > complex
> > number real and imaginary parts?  If yes, please let me know
> > how.  If
> > no, can a mechanism be implemented?
> > 
> > Respectfully,
> > 
> > Fred
> > 
> 
> 

Re: [Bug-apl] GNU APL port for OpenBSD

[Elias Mårtenson]

Perhaps it's time for a new release? Or should it be delayed until the
rational number support is stable enough to be default?

On 29 Aug 2017 02:22, "Giuseppe Cocomazzi"  wrote:

> Hi Jürgen,
> thanks for your reply.
> Ported software on OpenBSD is submitted for inclusion in the so-called
> "port tree", basically a set of custom Makefiles by means of which
> ports can be automatically downloaded, built, packaged and installed
> with a single "make" command. The port tree is part of the operating
> system, and importing rolling releases from SVN is not an option.
> Therefore, the official releases on the GNU mirrors are perfectly fine
> for the goal. Furthermore, I feel more comfortable in submitting
> stable and mature releases, as another goal of the OS is stability,
> security and cleanliness.
>
> As I am also the maintainer of the port/package, I will update the
> port's Makefile every time a major release is announced.
>
> As for the link to my blog/notebook, I have been actively maintaining
> my homepage for 8 years, my hosting service is quite stable and I have
> intention to keep the page away from oblivion. I think then it is
> reasonably safe to refer to it.
>
> Thank you very much.
>
> On Mon, Aug 28, 2017 at 3:09 PM, Juergen Sauermann
>  wrote:
> > Hi Giuseppe,
> >
> > thanks for submitting the patches. I have included them into SVN 1001.
> >
> > The first patch is now in Makefile.am as opposed to configure. That
> suggests
> > that you
> > are using an older version of the GNU APL sources. Maybe the one from the
> > GNU APL
> > home page at gnu.org or a gnu mirror. The "official" GNU APL releases
> happen
> > quite
> > rarely (like every one or two years) and therefore they quickly become
> > outdated. If you
> > are porting GNU APL then it is better to check out the latest version
> from
> > SVN.
> >
> > Regarding your web link below, I wonder how persistent it is? If the
> link is
> > supposed to
> > last for a longer period, then we could point to it from out community
> web
> > page
> > http://www.gnu.org/software/apl/Community.html and/or mention it in our
> > README-6-porting
> > file.
> >
> > Best Regards,
> > /// Jürgen Sauermann
> >
> >
> > On 08/28/2017 10:44 AM, Giuseppe Cocomazzi wrote:
> >
> > Hi list,
> > I have ported GNU APL to the OpenBSD operating system, and I kindly ask
> > you to consider the possibility of merging the following changes to the
> > source tree, in order to enable a better support for the OS. As you can
> > see, only few lines are needed.
> >
> > Also, I recollected some info about the steps needed to configure
> > the environment (fonts, keyboard), not necessarily addressed
> > at users of this OS but of any Unix-like system in general:
> >
> > http://sbudella.altervista.org/blog/20170821-apl-openbsd.html
> >
> > And here are the two patches:
> >
> > --- configure.orig  Fri Mar 17 16:03:06 2017
> > +++ configure   Mon Jul 17 17:11:15 2017
> > @@ -21413,7 +21413,7 @@ echo
> >  #
> >  echo "configure: creating $srcdir/src//buildtag.hh"
> >  rm -f $srcdir/src/buildtag.hh
> > -cd $srcdir/src ; source ./buildtag ; cd ..
> > +cd $srcdir/src ; . ./buildtag ; cd ..
> >
> >  # create src/makefile.h
> >  #
> >
> > --- src/Common.cc.orig  Fri Mar 17 15:46:53 2017
> > +++ src/Common.cc   Mon Jul 17 16:37:56 2017
> > @@ -81,6 +81,11 @@ void
> >  init_1(const char * argv0, bool log_startup)
> >  {
> >  rlimit rl;
> > +
> > +#ifndef RLIMIT_AS
> > +# define RLIMIT_AS RLIMIT_DATA
> > +#endif
> > +
> > getrlimit(RLIMIT_AS, &rl);
> > total_memory = rl.rlim_cur;
> >
> >
> > --
> > Giuseppe Cocomazzi
> > My self is steam
> >
> > http://sbudella.altervista.org
> >
> >
> >
>
>
>
> --
> Giuseppe Cocomazzi
> My self is steam.
>
> http://sbudella.altervista.org
>
>

Re: [Bug-apl] Access to rational number numerator and denominator

[Elias Mårtenson]

The true benefit of rational numbers is realised once there is support for
bigints. Jürgen has suggested that that is planned, and personally I can't
wait.

Regards,
Elias

On 29 August 2017 at 08:59, Frederick Pitts  wrote:

> Louis,
>
> Thanks for the quick response.
>
> After working with the technique a bit, I observe that as long
> as the rational number denominator is well within the range of integers
> representable by floating numbers, 1 ∧ n returns the correct result.
> But if the absolute value of the denominator exceeds 2 ⋆ 35, the
> technique returns incorrect results.  For instance,
>
>   fiMax ← × / 53 ⍴ 2 ⍝ largest integer 53-bit f.p. mantissa holds
>   fiMax
> ╔╗
> ║9007199254740992║
> ╚╝
>   1 ∧ fiMax ⍝ Correct result for fiMax
> ╔╗
> ║9007199254740992║
> ╚╝
>   1 ∧ ÷ fiMax ⍝ Incorrect result. 1 is numerator of reciprocal.
> ╔═╗
> ║0║
> ╚═╝
>
> I was hoping to be able to access correct rational number parts
> even when they approach the ⎕SYL[20;2] limit of 920.
> It seems a shame to loose so much of the integer range because floating
> point operations are sneaking into the numerator and denominator access
> methods.
>
> Regards,
>
> Fred
>
> On Tue, 2017-08-29 at 00:08 +0200, Louis de Forcrand wrote:
> > Hi,
> >
> > No APL kb with me right now, sorry :(
> >
> > 1 LCM n
> >
> > gives the numerator of a fraction (floating or exact). If you need
> > the denominator, do the same with the inverse of n. If you need both,
> > for example:
> >
> > 1 LCM n POW 1 _1
> >
> > Cheers,
> > Louis
> >
> > > On 28 Aug 2017, at 23:24, Frederick Pitts 
> > > wrote:
> > >
> > > Hello,
> > >
> > >Is there an existing mechanism for accessing rational number
> > > numerator and denominator parts analogous to that for accessing
> > > complex
> > > number real and imaginary parts?  If yes, please let me know
> > > how.  If
> > > no, can a mechanism be implemented?
> > >
> > > Respectfully,
> > >
> > > Fred
> > >
> >
> >
>
>

Re: [Bug-apl] Access to rational number numerator and denominator

[Christian Robert]

what is "bigints" ?

larger than ~62 bits or 920 ?

If so, I would agree 100%. Having a limit that is less than exact 64 bits 
(signed or unsigned)
is wrong. encode & decode can't manage more than ~62-~63 bits limit.


my 2 cents,
Xtian.

On 2017-08-28 22:33, Elias Mårtenson wrote:

The true benefit of rational numbers is realised once there is support for 
bigints. Jürgen has suggested that that is planned, and personally I can't wait.

Regards,
Elias

On 29 August 2017 at 08:59, Frederick Pitts mailto:fred.pit...@comcast.net>> wrote:

Louis,

         Thanks for the quick response.

         After working with the technique a bit, I observe that as long
as the rational number denominator is well within the range of integers
representable by floating numbers, 1 ∧ n returns the correct result.
But if the absolute value of the denominator exceeds 2 ⋆ 35, the
technique returns incorrect results.  For instance,

       fiMax ← × / 53 ⍴ 2 ⍝ largest integer 53-bit f.p. mantissa holds
       fiMax
╔╗
║9007199254740992║
╚╝
       1 ∧ fiMax ⍝ Correct result for fiMax
╔╗
║9007199254740992║
╚╝
       1 ∧ ÷ fiMax ⍝ Incorrect result. 1 is numerator of reciprocal.
╔═╗
║0║
╚═╝

         I was hoping to be able to access correct rational number parts
even when they approach the ⎕SYL[20;2] limit of 920.
It seems a shame to loose so much of the integer range because floating
point operations are sneaking into the numerator and denominator access
methods.

Regards,

Fred

On Tue, 2017-08-29 at 00:08 +0200, Louis de Forcrand wrote:
 > Hi,
 >
 > No APL kb with me right now, sorry :(
 >
 > 1 LCM n
 >
 > gives the numerator of a fraction (floating or exact). If you need
 > the denominator, do the same with the inverse of n. If you need both,
 > for example:
 >
 > 1 LCM n POW 1 _1
 >
 > Cheers,
 > Louis
 >
 > > On 28 Aug 2017, at 23:24, Frederick Pitts mailto:fred.pit...@comcast.net>>
 > > wrote:
 > >
 > > Hello,
 > >
 > >    Is there an existing mechanism for accessing rational number
 > > numerator and denominator parts analogous to that for accessing
 > > complex
 > > number real and imaginary parts?  If yes, please let me know
 > > how.  If
 > > no, can a mechanism be implemented?
 > >
 > > Respectfully,
 > >
 > > Fred
 > >
 >
 >

Re: [Bug-apl] Access to rational number numerator and denominator

[Elias Mårtenson]

A bigint is an arbitrary-precision integer. Such as what is provided in
Lisp:

In Lisp, I get the correct rational number:

CL> *(/ (expt 2 1000) 3)*
10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069376/3

In GNU APL:

*  ⎕PS←1 0*
*  3÷⍨2⋆1000*
3.571695357E300

With bigints, the APL result would be similar to that of Lisp.

Regards,
Elias


On 29 August 2017 at 10:48, Christian Robert 
wrote:

> what is "bigints" ?
>
> larger than ~62 bits or 920 ?
>
> If so, I would agree 100%. Having a limit that is less than exact 64 bits
> (signed or unsigned)
> is wrong. encode & decode can't manage more than ~62-~63 bits limit.
>
>
> my 2 cents,
> Xtian.
>
> On 2017-08-28 22:33, Elias Mårtenson wrote:
>
>> The true benefit of rational numbers is realised once there is support
>> for bigints. Jürgen has suggested that that is planned, and personally I
>> can't wait.
>>
>> Regards,
>> Elias
>>
>> On 29 August 2017 at 08:59, Frederick Pitts > > wrote:
>>
>> Louis,
>>
>>  Thanks for the quick response.
>>
>>  After working with the technique a bit, I observe that as
>> long
>> as the rational number denominator is well within the range of
>> integers
>> representable by floating numbers, 1 ∧ n returns the correct result.
>> But if the absolute value of the denominator exceeds 2 ⋆ 35, the
>> technique returns incorrect results.  For instance,
>>
>>fiMax ← × / 53 ⍴ 2 ⍝ largest integer 53-bit f.p. mantissa holds
>>fiMax
>> ╔╗
>> ║9007199254740992║
>> ╚╝
>>1 ∧ fiMax ⍝ Correct result for fiMax
>> ╔╗
>> ║9007199254740992║
>> ╚╝
>>1 ∧ ÷ fiMax ⍝ Incorrect result. 1 is numerator of reciprocal.
>> ╔═╗
>> ║0║
>> ╚═╝
>>
>>  I was hoping to be able to access correct rational number
>> parts
>> even when they approach the ⎕SYL[20;2] limit of 920.
>> It seems a shame to loose so much of the integer range because
>> floating
>> point operations are sneaking into the numerator and denominator
>> access
>> methods.
>>
>> Regards,
>>
>> Fred
>>
>> On Tue, 2017-08-29 at 00:08 +0200, Louis de Forcrand wrote:
>>  > Hi,
>>  >
>>  > No APL kb with me right now, sorry :(
>>  >
>>  > 1 LCM n
>>  >
>>  > gives the numerator of a fraction (floating or exact). If you need
>>  > the denominator, do the same with the inverse of n. If you need
>> both,
>>  > for example:
>>  >
>>  > 1 LCM n POW 1 _1
>>  >
>>  > Cheers,
>>  > Louis
>>  >
>>  > > On 28 Aug 2017, at 23:24, Frederick Pitts <
>> fred.pit...@comcast.net >
>>  > > wrote:
>>  > >
>>  > > Hello,
>>  > >
>>  > >Is there an existing mechanism for accessing rational number
>>  > > numerator and denominator parts analogous to that for accessing
>>  > > complex
>>  > > number real and imaginary parts?  If yes, please let me know
>>  > > how.  If
>>  > > no, can a mechanism be implemented?
>>  > >
>>  > > Respectfully,
>>  > >
>>  > > Fred
>>  > >
>>  >
>>  >
>>
>>
>>
>