headers
Stewart Wallace | 2 Nov 2008 03:55

further to all-bidirectional-search-paths

Stewart Wallace <stewart.wallace <at> dictionaryofsydney.org> writes:

Further experimenting suggests that the normal behaviour for this function is to
only return the shortest path - it will return more than one only if there are
several the same length. If there is some way to make it return all paths up to
max-depth n, I would be very interested to know.

I have attempted to use the Prolog equivalent - bidirectional-search-paths - as
an alternative as the doco on it suggested more explicitly that it iterates
through multiple returned paths but I've struck another problem here because it
just seems to return nil paths.  I've set it up as follows:

(setf mn1 (upi !mp1:MajorNode_1))
(setf mn2 (upi !mp1:MajorNode_2))
(?- (bidirectional-search-paths (?? mn1) (?? mn2) (?? nextN) 11))

.. nextN is the generator previously defined in my previous post - (setf nextN
(defsna-generator nextNode () (:undirected :p (!mp1:hasNextNode))))

The exact equivalent lisp version - (all-bidirectional-search-paths
!mp1:MajorNode_1 !mp1:MajorNode_2 nextN 11) - returns at least a path but the
Prolog one just returns nil - can't see what I'm doing wrong.

I've also noticed that AllegroCL doesn't seem to want to recognise some of the
other Prolog functions mentioned in the doco like:

(?- (nodal-neighbors (?? mn1) (?? nextN)))

.. this just gives and unrecognised-function error.  Are all the documented
Prolog SNA functions (those in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Didier Verna | 17 Nov 2008 17:26
X-Face
Face
Picon
Picon
Picon
Picon
Gravatar

make-<some-struct> performance


       Hello,

I have a question regarding the performance of structure making
functions. Suppose I have something simple like this:

(defstruct struct (slot1 1 :type fixnum))

Benchmarking a number of calls to make-struct made me realize that there
is no difference between an optimized version:

(declaim (optimize (speed 3)
		   (compilation-speed 0)
		   (safety 0)
		   (debug 0)))

and a safe version:

(declaim (optimize (speed 0)
		   (compilation-speed 0)
		   (safety 3)
		   (debug 0)))

This is quite different from other implementations I'm testing. I have
also noted that there doesn't seem to be any type checking done in the
safe version, so for instance:

(defstruct struct (slot1 1.5 :type fixnum))
(make-struct)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Duane Rettig | 18 Nov 2008 22:29
Picon
Favicon

Re: [spr35301] make-<some-struct> performance


>>        Hello,

Hi, Didier,

>> I have a question regarding the performance of structure making
>> functions. Suppose I have something simple like this:
>> 
>> (defstruct struct (slot1 1 :type fixnum))
>> 
>> Benchmarking a number of calls to make-struct made me realize that there
>> is no difference between an optimized version:
>> 
>> (declaim (optimize (speed 3)
>> 		   (compilation-speed 0)
>> 		   (safety 0)
>> 		   (debug 0)))
>> 
>> and a safe version:
>> 
>> (declaim (optimize (speed 0)
>> 		   (compilation-speed 0)
>> 		   (safety 3)
>> 		   (debug 0)))
>> 
>> 
>> This is quite different from other implementations I'm testing. I have
>> also noted that there doesn't seem to be any type checking done in the
>> safe version, so for instance:
>>
(Continue reading)

Permalink | Reply | 752 comments |
headers
Didier Verna | 19 Nov 2008 17:58
X-Face
Face
Picon
Picon
Picon
Picon
Gravatar

Re: [spr35301] make-<some-struct> performance

Duane Rettig wrote:

> the spec clearly allows Allegro CL's behavior (the defstruct
> description page is rife with nods to the implementation, and the term
> "implementation dependent" appears in both slot-option descriptions).

  Yup.

 
> If your comment was just an observation, then I would say that yes, we
> do the same high-optimization building of structs under all
> circumstances when it comes to slot options, and thus I would expect
> our make-<struct> constructors to generally be at the top end in terms
> of speed.

  Okay, that's perfectly fine with me. This is what I suspected, and
yes, I was only making an observation, and trying to confirm my
hypothesis.

Thanks for the reply !

--

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France
Tel. +33 (0)1 44 08 01 85       Fax. +33 (0)1 53 14 59 22
(Continue reading)

Permalink | Reply | 0 comments |
headers
Didier Verna | 26 Nov 2008 10:20
X-Face
Face
Picon
Picon
Picon
Picon
Gravatar

Re: [spr35301] make-<some-struct> performance


       Hi again Duane,

Duane Rettig wrote:

> I personally use defstruct quite a bit, but mostly for speed, and it
> has been my observation that most of our customers use defstruct for
> speed as well; when type checking and especially usage of the MOP to
> create special considerations and checking for building lisp objects,
> they tend to use CLOS.
>
> I am not adverse to adding optional checking to slot-options, but it
> simply isn't a very high priority. [...] A workaround is to use CLOS
> objects, at least for the debugging phase of your program

  I'm coming back to you because I'm a bit confused. What you wrote
above made me think that ACL would perform type checking on CLOS
objects'slots, if not on structure slots. But this doesn't seem to be
the case either. For instance, this code doesn't trigger any error (not
when instanciating the class, not when modifying the slot value or
whatever):

| (declaim (optimize (speed 0)
| 		   (compilation-speed 0)
| 		   (safety 3)
| 		   (debug 0)))
| 
| (defclass foo ()
|   ((slot :type single-float :initform "bar")))
(Continue reading)

Permalink | Reply | 751 comments |

Gmane