bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Outer product problems


From: Juergen Sauermann
Subject: Re: [Bug-apl] Outer product problems
Date: Fri, 06 Mar 2015 21:15:48 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Hi Darek,

a preliminary analysis shows that the EOC (end of context) handler for, say, ∘,FOO is overridden by the
EOC handler for /. Therefore

      (5 2) ∘.FOO (7 6 4)

succeeds while

      ∘.×/ (5 2) (7 6 4)


fails. I will make 
EOC handlers recursive in order to fix that. The problem will occur for all expressions combining
derived functions containing user-defined functions (incl {...}).

/// Jürgen


On 03/06/2015 12:54 PM, Darek Cidlinsky wrote:
Ave,
	I have two problems with outer product in GNU APL; one of them is maybe a bug, the other is nearly definitely a bug.

	If I use the product with a standard function like ×, everything works as it should:

	      ∘.×/ (5 2) (7 6 4)
	 35 30 20 
	 14 12  8 
	
	However, if I replace it with a custom function, it does something different:

	      ∘.{⍺×⍵}/ (5 2) (7 6 4)
	35

	It does the exactly same thing with custom non-lambda functions

	      P ← {⍺×⍵}
	      ∘.P/ (5 2) (7 6 4)
	35


	I have only little experience with APL (30 hours), but I think that all functions are created equal (I hope so!), and the both products above should be same. (If it's a valid behaviour, -- a feature, not a bug -- I'd be grateful if you could explain it to me.)

	[ If I envelope the whole product in a lambda, it works again:

	      {⍺ ∘.{⍺×⍵} ⍵}/ (5 2) (7 6 4)
	 35 30 20 
	 14 12  8 
	
	]

	Now for the sure bug: the _expression_ (for two bit vectors K and L -- it doesn't seem to depend on their contents or shapes)

	K { { ⍺ ∘.{| ⍺ - ⍵ + 0J1} ⍵}/ {⍵/⍳⍴⍵}¨⍺ ⍵} L

	was supposed to get the positions of 1s in both vectors ( {⍵/⍳⍴⍵}¨⍺ ⍵ , and do an outer product of these position lists using a function " sqrt(difference^2 + 1) ". However, it says 

	copying:             '0' at Executable.cc:627
	tidx:                '2' at Executable.cc:628

	----------------------------------------
	-- Stack trace at Executable.cc:629
	----------------------------------------
	0x7f8af60cfb45 __libc_start_main
	0x43b425  main
	0x53909d   Workspace::immediate_execution(bool)
	0x474365    Command::process_line()
	0x46e1d0     Command::do_APL_expression(UCS_string&)
	0x4811c4      StatementList::fix(UCS_string const&, char const*)
	0x480030       Executable::setup_lambdas()
	0x5290af        UserFunction::UserFunction(Fun_signature, UCS_string const&, UCS_string const&, Token_string const&)
	0x480030         Executable::setup_lambdas()
	0x5290af          UserFunction::UserFunction(Fun_signature, UCS_string const&, UCS_string const&, Token_string const&)
	0x47fffe           Executable::setup_lambdas()
	0x47ec2f            Executable::extract_lambda_text(Fun_signature, int) const
	========================================

	and exits (with state of 0). I think it shouldn't do that.

	[ But if I omit the {⍵/⍳⍴⍵}¨⍺ ⍵ and give some vector literals instead, it works as intended:

	      {⍺∘.{|⍺-⍵+0J1}⍵}/ (5 2) (7 6 4)
	 2.236067977 1.414213562 1.414213562 
	 5.099019514 4.123105626 2.236067977 
	]

Optime vale,
	D.

P. S.: This behaviour is exhibited by the Debian package (apl_1.4-1_amd64.deb) as well as by the source in Svn repository.
P. P. S.: I switched on all 41 logging facilites and ran it again. The resulting log should be attached.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]