can `shuffle-vector' be moved?

can `shuffle-vector' be moved?

[Ted Zlatanov]

I don't know where it should live, but cookie1.el doesn't seem like the
right place.

It should be documented in "(elisp) Vector Functions" as well.

Let me know if I should do this, please.

Also this loop call from Pascal Bourguignon is a nice CL alternative to
`shuffle-vector', though it uses the same algorithm:

(defun shuffle (vector)
  "Re-orders randomly the vector."
  (loop
      for i from (1-  (length vector)) downto 1
      do (rotatef (aref vector i) (aref vector (random i)))))

Can it go into cl-macs.el?

Thanks
Ted

Re: can `shuffle-vector' be moved?

[Leo]

On 2011-05-13 03:58 +0800, Ted Zlatanov wrote:
> I don't know where it should live, but cookie1.el doesn't seem like the
> right place.
>
> It should be documented in "(elisp) Vector Functions" as well.
>
> Let me know if I should do this, please.
>
> Also this loop call from Pascal Bourguignon is a nice CL alternative to
> `shuffle-vector', though it uses the same algorithm:
>
> (defun shuffle (vector)
>   "Re-orders randomly the vector."
>   (loop
>       for i from (1-  (length vector)) downto 1
>       do (rotatef (aref vector i) (aref vector (random i)))))
>
> Can it go into cl-macs.el?

We should have one version and not in cl-macs.el. `shuffle' is not in
common lisp.

>
> Thanks
> Ted

Leo

Re: can `shuffle-vector' be moved?

[Stefan Monnier]

>> I don't know where it should live, but cookie1.el doesn't seem like the
>> right place.

OTOH I don't see anything similar used anywhere else.


        Stefan

Re: can `shuffle-vector' be moved?

[Ted Zlatanov]

On Thu, 12 May 2011 23:10:21 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>> I don't know where it should live, but cookie1.el doesn't seem like the
>>> right place.

SM> OTOH I don't see anything similar used anywhere else.

True, but if it's mentioned in the Info manual it will be much easier to
find and use.

Ted

Re: can `shuffle-vector' be moved?

[Stefan Monnier]

>>>> I don't know where it should live, but cookie1.el doesn't seem like the
>>>> right place.
SM> OTOH I don't see anything similar used anywhere else.
> True, but if it's mentioned in the Info manual it will be much easier to
> find and use.

I really meant "similar": if no other code uses this functionality,
advertising its existence is not going to increase its use.


        Stefan

Re: can `shuffle-vector' be moved?

[Ted Zlatanov]

On Fri, 13 May 2011 10:03:57 +0800 Leo <sdl.web@gmail.com> wrote: 

L> On 2011-05-13 03:58 +0800, Ted Zlatanov wrote:
>> Also this loop call from Pascal Bourguignon is a nice CL alternative to
>> `shuffle-vector', though it uses the same algorithm:
>> 
>> (defun shuffle (vector)
>> "Re-orders randomly the vector."
>> (loop
>> for i from (1-  (length vector)) downto 1
>> do (rotatef (aref vector i) (aref vector (random i)))))
>> 
>> Can it go into cl-macs.el?

L> We should have one version and not in cl-macs.el. 

Why?  There are many functions in cl-macs.el that have analogues in
plain ELisp.  If anything I would drop `shuffle-vector' :)

L> `shuffle' is not in common lisp.

I didn't say it was.  cl-macs.el is not Common Lisp by any means and IMO
should not be treated as a clone of it.

Ted

Re: can `shuffle-vector' be moved?

[Kevin Rodgers]

On 5/12/11 9:53 PM, Ted Zlatanov wrote:
> On Fri, 13 May 2011 10:03:57 +0800 Leo<sdl.web@gmail.com>  wrote:
>
> L>  On 2011-05-13 03:58 +0800, Ted Zlatanov wrote:
>>> Also this loop call from Pascal Bourguignon is a nice CL alternative to
>>> `shuffle-vector', though it uses the same algorithm:
>>>
>>> (defun shuffle (vector)
>>> "Re-orders randomly the vector."
>>> (loop
>>> for i from (1-  (length vector)) downto 1
>>> do (rotatef (aref vector i) (aref vector (random i)))))
>>>
>>> Can it go into cl-macs.el?
>
> L>  We should have one version and not in cl-macs.el.
>
> Why?  There are many functions in cl-macs.el that have analogues in
> plain ELisp.  If anything I would drop `shuffle-vector' :)
>
> L>  `shuffle' is not in common lisp.
>
> I didn't say it was.  cl-macs.el is not Common Lisp by any means and IMO
> should not be treated as a clone of it.

 From cl-macs.el:

;; These are extensions to Emacs Lisp that provide a degree of
;; Common Lisp compatibility, beyond what is already built-in
;; in Emacs Lisp.
...
;; This file contains the portions of the Common Lisp extensions
;; package which should be autoloaded, but need only be present
;; if the compiler or interpreter is used---this file is not
;; necessary for executing compiled code.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: can `shuffle-vector' be moved?

[Ted Zlatanov]

On Fri, 13 May 2011 00:00:53 -0600 Kevin Rodgers <kevin.d.rodgers@gmail.com> wrote: 

KR> On 5/12/11 9:53 PM, Ted Zlatanov wrote:
>> On Fri, 13 May 2011 10:03:57 +0800 Leo<sdl.web@gmail.com>  wrote:
L> `shuffle' is not in common lisp.
>> 
>> I didn't say it was.  cl-macs.el is not Common Lisp by any means and IMO
>> should not be treated as a clone of it.

KR> From cl-macs.el:

KR> ;; These are extensions to Emacs Lisp that provide a degree of
KR> ;; Common Lisp compatibility, beyond what is already built-in
KR> ;; in Emacs Lisp.

OK.  Can there be a cl-macs-extras.el for "general cl-macs based code
that is safe to include in ELisp code"?

On Fri, 13 May 2011 10:57:58 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>>>> I don't know where it should live, but cookie1.el doesn't seem like the
>>>>> right place.
SM> OTOH I don't see anything similar used anywhere else.
>> True, but if it's mentioned in the Info manual it will be much easier to
>> find and use.

SM> I really meant "similar": if no other code uses this functionality,
SM> advertising its existence is not going to increase its use.

I also see lisp/calc/calc-comb.el:math-shuffle-list but you're right,
it's not commonly needed.  I still don't think it belongs in cookie1.el,
if only because the name is general and not library-specific, but that's
an inconsistency all the cookie1.el functions have.

Ted

Re: can `shuffle-vector' be moved?

[Stefan Monnier]

KR> ;; These are extensions to Emacs Lisp that provide a degree of
KR> ;; Common Lisp compatibility, beyond what is already built-in
KR> ;; in Emacs Lisp.

> OK.  Can there be a cl-macs-extras.el for "general cl-macs based code
> that is safe to include in ELisp code"?

I really have no idea why you want it in cl-macs:
1- the "macs" part refers to "macros", your function isn't one.
2- it does not provide a CL-style function.
3- using a CL macro in its definition is a property share by a lot more
   code than just the CL code.  And actually, the cl*.el files tend not
   to use CL features, to avoid circular dependencies.

SM> I really meant "similar": if no other code uses this functionality,
SM> advertising its existence is not going to increase its use.
> I also see lisp/calc/calc-comb.el:math-shuffle-list but you're right,
> it's not commonly needed.  I still don't think it belongs in cookie1.el,
> if only because the name is general and not library-specific,

It should probably be called cookie-shuffle-vector, indeed.

> but that's an inconsistency all the cookie1.el functions have.

The only other function I see in cookie1.el that does not use the
"cookie-" prefix is "read-cookie", which is borderline acceptable (we
have a few such "shared prefixes" like "turn-on-").  So,
`shuffle-vector' does indeed stand out.  And the fact that it's
autoloaded is a clear sign it is intended to be used by other packages.
But I see no good place to put it right now, and I don't think it
deserves creating a "misc-lib.el" for itself (although some of the
functions in subr.el might be good candidates for such a new package).


        Stefan

Re: can `shuffle-vector' be moved?

[Ted Zlatanov]

On Fri, 13 May 2011 12:26:34 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>> OK.  Can there be a cl-macs-extras.el for "general cl-macs based code
>> that is safe to include in ELisp code"?

SM> I really have no idea why you want it in cl-macs:
SM> 1- the "macs" part refers to "macros", your function isn't one.
SM> 2- it does not provide a CL-style function.
SM> 3- using a CL macro in its definition is a property share by a lot more
SM>    code than just the CL code.  And actually, the cl*.el files tend not
SM>    to use CL features, to avoid circular dependencies.

I was trying to say "miscellaneous functions that require cl-macs.el."
I think the value of the loop-based `shuffle' is code brevity and
clarity; otherwise it's no better than `shuffle-vector' and has a
startup penalty if you don't have cl-macs.el loaded.  So if you don't
think it's worth keeping it around for those qualities, I have no
problem with dropping it.

>> but that's an inconsistency all the cookie1.el functions have.

SM> The only other function I see in cookie1.el that does not use the
SM> "cookie-" prefix is "read-cookie", which is borderline acceptable (we
SM> have a few such "shared prefixes" like "turn-on-").

I mean that they all have the "cookie-" prefix while the package is
called cookie1.el.

SM> So, `shuffle-vector' does indeed stand out.  And the fact that it's
SM> autoloaded is a clear sign it is intended to be used by other
SM> packages.  But I see no good place to put it right now, and I don't
SM> think it deserves creating a "misc-lib.el" for itself (although some
SM> of the functions in subr.el might be good candidates for such a new
SM> package).

Yes, maybe we're at the tipping point where it's worth breaking up
subr.el into subr-vec.el, subr-list.el, subr-alist.el, etc.  OTOH it's
nice to have them in one place.

Ted

Re: can `shuffle-vector' be moved?

[Stefan Monnier]

> I was trying to say "miscellaneous functions that require cl-macs.el."
> I think the value of the loop-based `shuffle' is code brevity and
> clarity;

Since I'm not very intimate with `loop', the while form is clearer for
me, tho not enough to justify preferring one over the other.

> I mean that they all have the "cookie-" prefix while the package is
> called cookie1.el.

That's OK: the main rule is "use a prefix", if the prefix is exactly the
same as the file-name it's best, but it's not crucial.

> Yes, maybe we're at the tipping point where it's worth breaking up
> subr.el into subr-vec.el, subr-list.el, subr-alist.el, etc.  OTOH it's
> nice to have them in one place.

No, the main reason for a misc-lib.el would be for it to not be
preloaded, so the division wouldn't be based on the kind of
functionality provided but on whether those functions/macros are used
often or rarely.


        Stefan

Re: can `shuffle-vector' be moved?

[Ted Zlatanov]

On Fri, 13 May 2011 13:47:47 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I mean that they all have the "cookie-" prefix while the package is
>> called cookie1.el.

SM> That's OK: the main rule is "use a prefix", if the prefix is exactly the
SM> same as the file-name it's best, but it's not crucial.

Oh, OK.  Thanks for explaining.

>> Yes, maybe we're at the tipping point where it's worth breaking up
>> subr.el into subr-vec.el, subr-list.el, subr-alist.el, etc.  OTOH it's
>> nice to have them in one place.

SM> No, the main reason for a misc-lib.el would be for it to not be
SM> preloaded, so the division wouldn't be based on the kind of
SM> functionality provided but on whether those functions/macros are used
SM> often or rarely.

OK, you and Chong will have to make the choice then :)

Thanks
Ted

Re: can `shuffle-vector' be moved?

[Thierry Volpiatto]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I don't know where it should live, but cookie1.el doesn't seem like the
> right place.
>
> It should be documented in "(elisp) Vector Functions" as well.
>
> Let me know if I should do this, please.
>
> Also this loop call from Pascal Bourguignon is a nice CL alternative to
> `shuffle-vector', though it uses the same algorithm:
>
> (defun shuffle (vector)
>   "Re-orders randomly the vector."
>   (loop
>       for i from (1-  (length vector)) downto 1
>       do (rotatef (aref vector i) (aref vector (random i)))))

Nice.
Why is this limited to vectors? with elt it could work also with lists.

> Can it go into cl-macs.el?
>
> Thanks
> Ted
>
>
>

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: can `shuffle-vector' be moved?

[Stefan Monnier]

>> I don't know where it should live, but cookie1.el doesn't seem like the
>> right place.
>> 
>> It should be documented in "(elisp) Vector Functions" as well.
>> 
>> Let me know if I should do this, please.
>> 
>> Also this loop call from Pascal Bourguignon is a nice CL alternative to
>> `shuffle-vector', though it uses the same algorithm:
>> 
>> (defun shuffle (vector)
>> "Re-orders randomly the vector."
>> (loop
>> for i from (1-  (length vector)) downto 1
>> do (rotatef (aref vector i) (aref vector (random i)))))

> Nice.
> Why is this limited to vectors? with elt it could work also with lists.

Its algorithmic performance on lists would be poor (O(N²)).
You want a different algorithm for lists.


        Stefan

Re: can `shuffle-vector' be moved?

[Ted Zlatanov]

On Fri, 13 May 2011 11:00:10 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>> (loop
>>> for i from (1-  (length vector)) downto 1
>>> do (rotatef (aref vector i) (aref vector (random i)))))

>> Why is this limited to vectors? with elt it could work also with lists.

SM> Its algorithmic performance on lists would be poor (O(N²)).
SM> You want a different algorithm for lists.

I think the performance would not be bad if the list was put into a
vector, shuffled, then put back--just O(N) with twice the memory usage.
That could be a wrapper around the vector shuffle so it can handle
general sequences.

Ted

Re: can `shuffle-vector' be moved?

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I don't know where it should live, but cookie1.el doesn't seem like the
>>> right place.
>>> 
>>> It should be documented in "(elisp) Vector Functions" as well.
>>> 
>>> Let me know if I should do this, please.
>>> 
>>> Also this loop call from Pascal Bourguignon is a nice CL alternative to
>>> `shuffle-vector', though it uses the same algorithm:
>>> 
>>> (defun shuffle (vector)
>>> "Re-orders randomly the vector."
>>> (loop
>>> for i from (1-  (length vector)) downto 1
>>> do (rotatef (aref vector i) (aref vector (random i)))))
>
>> Nice.
>> Why is this limited to vectors? with elt it could work also with lists.
>
> Its algorithmic performance on lists would be poor (O(N²)).
> You want a different algorithm for lists.
Ok. Thanks.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997