From: Jeremy Smith
Subject: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <Xns96FC151B25F20jeremyalansmithsofth@80.5.182.99>
Hi,

I just ported a Bicubic resizing algorithm (like the default one in 
Photoshop), which was written in C, into Lisp, for my own uses. I decided 
to post it here to anyone who might find it useful, in the generous spirit 
of Lisp. It is very simple to use, and requires no memory allocation or 
fiddling about. You just give it a list of lists, ie:

(list (list 1 2 3) (list 4 5 6) (list 7 8 9))

Is 3 rows of 3 pixels in width.

Then you pass it a magnification value (2 values actually), a smooth 
factor, and it returns the enlarged bitmap of RGB values. Simple!

It's very fast, even in Lisp (though perhaps someone could suggest speed 
improvements), and can be used commercially without credit or permission, 
though credit would be nice (perhaps a link to the author's webpage).

See Michael's website for further details.

    	http://members.bellatlantic.net/~vze2vrva/design.html

I'll be posting it on a website or Cliki, but this posting will archive it 
on Google Groups anyway. I hope it works with the linebreaks, I had to re-
align the hyphenated variable names, as they were broken up by my news 
client (Xnews).

Jeremy.

;Helper functions for bicubic-resize
(defun C0(t2 a)
  (+(* (- a) (* t2(* t2 t2)))(* a (* t2 t2))))

(defun C1(t2 a)
  (+(*(-(+ a 2.0)) (* t2(* t2 t2))) (-(*(+(* a 2.0)3.0) t2 t2)(* a t2))))

(defun C2(t2 a)
  (+(-(* (+ a 2.0) (* t2 t2 t2)) (* (+ a 3.0) t2 t2))1.0))

(defun C3(t2 a)
  (+(-(* a (* t2(* t2 t2))) (* 2.0 a t2 t2)) (* a t2)))

;Not very efficient, but not slow
(defun array-to-list(array)
  (let ((x (first(array-dimensions array))) (y (second(array-dimensions 
array))))
  (let ((retval (list)))
    (dotimes (y1 y)
      (let ((temp-row (list)))
        (dotimes (x1 x)
          (push (aref array x1 y1) temp-row))
        (push (reverse temp-row) retval)))
    (reverse retval))))

(defmacro lbreak ()
  "Break out of a loop, without having to put 'return' which could confuse 
C programmers like me"
  `(return))

(defmacro mywhile (condition &rest body)
  "Does the same as C's 'While(condition) {body}' because frankly the lack 
of it in Lisp was annoying me. The clever bit is the 'not' on the 
condition. Uses lbreak"
  `(loop (if (not ,condition) (lbreak)) ,@body))

;  "Perform an enlargement (or reduction) on a bitmap, which is represented 
as a list of lists. Each list entry is a row of pixel colours. The 
magnification factor is n/d, so n=12 ;and d=2 would increase the bitmap by 
a factor of 6. It returns a 2d array with the enlarged image which will 
need converting back to a list. This hasn't been tested with any ;operation 
but enlargement but should work. f is the input list of rows, for instance 
"(list (list 0 0 1) (list 1 2 3) (list 255 255 255))" is 3 rows of 
grayscale pixel values. a is a value ;from -1 to 0. 
;a is a parameter in the range -1 to 0 which
;affects the trade off between edge enhancement
;and smoothing.  a=-1 results in the most edge
;enhancement, while a=0 results in the most
;smoothing.  If its an "accurate" result you are
;looking for, i.e. if you plan to do further image
;processing on the result, I'd recommend a=-0.5 .
;If crispness of appearance, though, is more
;important than accuracy for you application, then
;consider a=-1 for the most edge enhancement or
;a=-0.75 for some edge enhancement.
;For more information see
;http://members.bellatlantic.net/~vze2vrva/design.html

(defun bicubic-resize(n d f a MAX-PIXEL)
  (let ((MAX-OUT-WIDTH (* (length(first f)) (/ n d))) (MAX-OUT-HEIGHT (* 
(length f) (/ n d))) (MAX-IN-WIDTH (length(first f))) (in-width (length
(first f))) (in-height (length f))(MAX-IN-HEIGHT (length f)))
    (let ((MAX-OUT-DIMENSION (if (> MAX-OUT-WIDTH MAX-OUT-HEIGHT)
 MAX-OUT-WIDTH MAX-OUT-HEIGHT)))
      (let ((out-width MAX-OUT-WIDTH) (out-height MAX-OUT-HEIGHT) (c
 (make-array (list 4 MAX-OUT-DIMENSION))) (h (make-array MAX-IN-WIDTH)) (x) 
(larger-out-dimension))
        (setf larger-out-dimension (if (> out-width out-height) out-width  
out-height))
        (let ((LARRAY (make-array larger-out-dimension)) (x) (g
 (make-array (list MAX-OUT-WIDTH MAX-OUT-HEIGHT))))
          (dotimes (k larger-out-dimension)
            (setf (elt LARRAY k) (floor(/(* k d)n))))
          (dotimes (k n)
            (setf x (/(REM(* k d)n)n))
            (setf (aref c 0 k) (C0 x a))
            (setf (aref c 1 k) (C1 x a))
            (setf (aref c 2 k) (C2 x a))
            (setf (aref c 3 k) (C3 x a)))
			(let ((k n))
          (mywhile (< k larger-out-dimension)
            (dotimes (l 4)
              (setf (aref c l k) (aref c l (REM k n))))
            (incf k)))
          (dotimes (k out-height)
            (dotimes (j in-width)
              (setf (elt h j) 0.0)
              (dotimes (l 4)
                (let ((index (floor(-(+(elt LARRAY k)l)1))))
                  (if-progn (and (>= index 0) (< index in-height))
                    (incf (elt h j) (*(pixat f j index) (aref c (- 3 l) 
k)))))))
            (dotimes (m out-width)
              (setf x 0.5)
              (dotimes (l 4)
                (let ((index (floor(-(+(elt LARRAY m)l)1))))
                  (if-progn (and (>= index 0) (< index in-width))
                    (incf x (* (elt h index) (aref c (- 3 l) m))))))
              ;This is where we write the result to the output array.
              ;(round x) may be best as just x, or (floor x)
              (if (<= x 0.0)
                (setf (aref g m k) 0)
                (if (>= x MAX-PIXEL)
                  (setf (aref g m k) MAX-PIXEL)
                  (setf (aref g m k) (round x))))))
            (array-to-list g))))))

From: Jeremy Smith
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <Xns96FC3FED0CAD9jeremyalansmithsofth@80.5.182.99>
Jeremy Smith <············@decompiler.org> wrote in
·········································@80.5.182.99: 

> Hi,
> 
> I just ported a Bicubic resizing algorithm (like the default one in 
> Photoshop), which was written in C, into Lisp, for my own uses. I
> decided to post it here to anyone who might find it useful, in the
> generous spirit of Lisp. It is very simple to use, and requires no
> memory allocation or fiddling about. You just give it a list of lists,
> ie: 

Oops, I forgot one other helper function. If it was a macro, you could setf 
using it, but I didn't do that in the bicubic resizing function. It would 
be better as a macro though.

It just gets the pixel at x,y on a list of rows. It does no bounds 
checking.

(defun pixat(pixmap x y)
	(elt (elt pixmap y)x))

Cheers,

Jeremy.
From: Marco Antoniotti
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <io78f.51$pa3.20237@typhoon.nyu.edu>
Very quickly!

Jeremy Smith wrote:
> Hi,
> 
> I just ported a Bicubic resizing algorithm (like the default one in 
> Photoshop), which was written in C, into Lisp, for my own uses. I decided 
> to post it here to anyone who might find it useful, in the generous spirit 
> of Lisp. It is very simple to use, and requires no memory allocation or 
> fiddling about. You just give it a list of lists, ie:
> 
> (list (list 1 2 3) (list 4 5 6) (list 7 8 9))
> 
> Is 3 rows of 3 pixels in width.

What's wrong with #2A((1 2 3) (4 5 6) (7 8 9)) ?

> 
> Then you pass it a magnification value (2 values actually), a smooth 
> factor, and it returns the enlarged bitmap of RGB values. Simple!
> 
> It's very fast, even in Lisp (though perhaps someone could suggest speed 
> improvements), and can be used commercially without credit or permission, 
> though credit would be nice (perhaps a link to the author's webpage).
> 
> See Michael's website for further details.
> 
>     	http://members.bellatlantic.net/~vze2vrva/design.html
> 
> I'll be posting it on a website or Cliki, but this posting will archive it 
> on Google Groups anyway. I hope it works with the linebreaks, I had to re-
> align the hyphenated variable names, as they were broken up by my news 
> client (Xnews).
> 
> Jeremy.
> 
> ;Helper functions for bicubic-resize
> (defun C0(t2 a)
>   (+(* (- a) (* t2(* t2 t2)))(* a (* t2 t2))))
> 
> (defun C1(t2 a)
>   (+(*(-(+ a 2.0)) (* t2(* t2 t2))) (-(*(+(* a 2.0)3.0) t2 t2)(* a t2))))
> 
> (defun C2(t2 a)
>   (+(-(* (+ a 2.0) (* t2 t2 t2)) (* (+ a 3.0) t2 t2))1.0))
> 
> (defun C3(t2 a)
>   (+(-(* a (* t2(* t2 t2))) (* 2.0 a t2 t2)) (* a t2)))
> 
> ;Not very efficient, but not slow
> (defun array-to-list(array)
>   (let ((x (first(array-dimensions array))) (y (second(array-dimensions 
> array))))
>   (let ((retval (list)))
>     (dotimes (y1 y)
>       (let ((temp-row (list)))
>         (dotimes (x1 x)
>           (push (aref array x1 y1) temp-row))
>         (push (reverse temp-row) retval)))
>     (reverse retval))))
> 
> (defmacro lbreak ()
>   "Break out of a loop, without having to put 'return' which could confuse 
> C programmers like me"
>   `(return))
> 
> (defmacro mywhile (condition &rest body)
>   "Does the same as C's 'While(condition) {body}' because frankly the lack 
> of it in Lisp was annoying me. The clever bit is the 'not' on the 
> condition. Uses lbreak"
>   `(loop (if (not ,condition) (lbreak)) ,@body))


(loop while <condition> do ...)

Get rid of LBREAK and MYWHILE immediately! :)


Cheers
--
Marco
From: Jeremy Smith
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <Xns96FCC441894F8jeremyalansmithsofth@80.5.182.99>
Marco Antoniotti <·······@cs.nyu.edu> wrote in
·······················@typhoon.nyu.edu: 

> Very quickly!

Okay!

>> (list (list 1 2 3) (list 4 5 6) (list 7 8 9))
>> 
>> Is 3 rows of 3 pixels in width.
> 
> What's wrong with #2A((1 2 3) (4 5 6) (7 8 9)) ?

I prefer using lists for some reason.

>>   `(loop (if (not ,condition) (lbreak)) ,@body))
> 
> 
> (loop while <condition> do ...)
> 
> Get rid of LBREAK and MYWHILE immediately! :)

I'll get rid of them on the next revision, and it will probably go on 
Cliki.

There's also the dastardly if-progn, which I forgot to put in the code 
(again!)

(defmacro if-progn (condition &rest body)
  `(if ,condition (progn ,@body)))

Thanks for the feedback!

Jeremy.
From: Marco Antoniotti
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <gZ88f.53$pa3.19739@typhoon.nyu.edu>
Jeremy Smith wrote:
> Marco Antoniotti <·······@cs.nyu.edu> wrote in
> ·······················@typhoon.nyu.edu: 
> 
> 
>>Very quickly!
> 
> 
> Okay!
> 
> 
>>>(list (list 1 2 3) (list 4 5 6) (list 7 8 9))
>>>
>>>Is 3 rows of 3 pixels in width.
>>
>>What's wrong with #2A((1 2 3) (4 5 6) (7 8 9)) ?
> 
> 
> I prefer using lists for some reason.

Well, you are dealing with 2d arrays.  Use the most appropriate data 
structure.



> 
> 
>>>  `(loop (if (not ,condition) (lbreak)) ,@body))
>>
>>
>>(loop while <condition> do ...)
>>
>>Get rid of LBREAK and MYWHILE immediately! :)
> 
> 
> I'll get rid of them on the next revision, and it will probably go on 
> Cliki.
> 
> There's also the dastardly if-progn, which I forgot to put in the code 
> (again!)
> 
> (defmacro if-progn (condition &rest body)
>   `(if ,condition (progn ,@body)))

What is wrong with WHEN?

Sorry to be blunt, but maybe a little bit of RTMF would help :)

Cheers
--
Marco
From: Zach Beane
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <m38xweepyu.fsf@unnamed.xach.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> Sorry to be blunt, but maybe a little bit of RTMF would help :)

I think Reading The Manual Fast is the problem, not the solution...

Zach
From: Marco Antoniotti
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <KBa8f.55$pa3.20138@typhoon.nyu.edu>
Zach Beane wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
> 
> 
>>Sorry to be blunt, but maybe a little bit of RTMF would help :)
> 
> 
> I think Reading The Manual Fast is the problem, not the solution...
> 

Actually I was going for a bit of the Yoda postfix thingy, but failed I 
have obviously. :)

Cheers
--
Marco
From: ···············@yahoo.com
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <1130507304.025623.182820@g47g2000cwa.googlegroups.com>
I can't read anything while...
From: William Bland
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <pan.2005.10.27.18.22.41.991160@gmail.com>
On Thu, 27 Oct 2005 18:14:43 +0000, Jeremy Smith wrote:

> There's also the dastardly if-progn, which I forgot to put in the code 
> (again!)
> 
> (defmacro if-progn (condition &rest body)
>   `(if ,condition (progn ,@body)))
> 

Sorry if I missed something obvious, but how does IF-PROGN differ from
WHEN?

Best wishes,
	Bill.
From: Albert Reiner
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <vw8wtjyj00d.fsf@berry.phys.ntnu.no>
[Jeremy Smith <············@decompiler.org>, Thu, 27 Oct 2005 18:14:43 GMT]:
> (defmacro if-progn (condition &rest body)
>   `(if ,condition (progn ,@body)))

It's called WHEN.

Albert.
From: Pascal Bourguignon
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <87slumv2lb.fsf@thalassa.informatimago.com>
Jeremy Smith <············@decompiler.org> writes:
> There's also the dastardly if-progn, which I forgot to put in the code 
> (again!)
>
> (defmacro if-progn (condition &rest body)
>   `(if ,condition (progn ,@body)))

It's called WHEN in CLHS.  You should read more CLHS!

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
Litter box not here.
You must have moved it again.
I'll poop in the sink. 
From: Kenny Tilton
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <Tig8f.5073$u43.3144@twister.nyc.rr.com>
Pascal Bourguignon wrote:
> Jeremy Smith <············@decompiler.org> writes:
> 
>>There's also the dastardly if-progn, which I forgot to put in the code 
>>(again!)
>>
>>(defmacro if-progn (condition &rest body)
>>  `(if ,condition (progn ,@body)))
> 
> 
> It's called WHEN in CLHS.  You should read more CLHS!

Nonsense, to every school marm that has sucked their teeth and uttered 
RTFM, or any variant thereof. Books are for the bookish, while the OP's 
wheel reinvention follows a fine, long tradition of newby Lispniks 
blithely tossing off in a minute what might have been found in the 
standard with five minutes of research. This is a clear sign of someone 
who comes to Lisp with Actual Code to write. I know that concept is 
stupefying to most of the denizens of this BS parlour, but anyone trying 
to Actually Do Something with Lisp rapidly gets so hyperaccelerated that 
the last thing they want to do is ruin the fun and start /studying/ fer 
chrissakes.

The correct response here is "Nice job reinventing WHEN!"

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950
From: Pascal Bourguignon
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <87br1auyjx.fsf@thalassa.informatimago.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> Pascal Bourguignon wrote:
>> Jeremy Smith <············@decompiler.org> writes:
>> 
>>> There's also the dastardly if-progn, which I forgot to put in the
>>> code (again!)
>>>
>>>(defmacro if-progn (condition &rest body)
>>>  `(if ,condition (progn ,@body)))
>> It's called WHEN in CLHS.  You should read more CLHS!
>
> Nonsense, to every school marm that has sucked their teeth and uttered
> RTFM, or any variant thereof. Books are for the bookish, while the
> OP's wheel reinvention follows a fine, long tradition of newby
> Lispniks blithely tossing off in a minute what might have been found
> in the standard with five minutes of research. This is a clear sign of
> someone who comes to Lisp with Actual Code to write. I know that
> concept is stupefying to most of the denizens of this BS parlour, but
> anyone trying to Actually Do Something with Lisp rapidly gets so
> hyperaccelerated that the last thing they want to do is ruin the fun
> and start /studying/ fer chrissakes.
>
> The correct response here is "Nice job reinventing WHEN!"

Oops, sorry, I thought we were on comp.lang.lisp, not on comp.lang.scheme. ;-)

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

This is a signature virus.  Add me to your signature and help me to live
From: Jeremy Smith
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <Xns96FD7749120jeremyalansmithsofth@62.253.170.163>
Kenny Tilton <·······@nyc.rr.com> wrote in
························@twister.nyc.rr.com: 

> 
> 
> Pascal Bourguignon wrote:
>> Jeremy Smith <············@decompiler.org> writes:
>> 
>>>There's also the dastardly if-progn, which I forgot to put in the
>>>code (again!)
>>>
>>>(defmacro if-progn (condition &rest body)
>>>  `(if ,condition (progn ,@body)))
>> 
>> 
>> It's called WHEN in CLHS.  You should read more CLHS!
> 
> Nonsense, to every school marm that has sucked their teeth and uttered
> RTFM, or any variant thereof. Books are for the bookish, while the
> OP's wheel reinvention follows a fine, long tradition of newby
> Lispniks blithely tossing off in a minute what might have been found
> in the standard with five minutes of research. This is a clear sign of
> someone who comes to Lisp with Actual Code to write. I know that
> concept is stupefying to most of the denizens of this BS parlour, but
> anyone trying to Actually Do Something with Lisp rapidly gets so
> hyperaccelerated that the last thing they want to do is ruin the fun
> and start /studying/ fer chrissakes.
> 
> The correct response here is "Nice job reinventing WHEN!"
> 

Okay, I'm not amused by all these responses on changing an 8-letter word
to a 4-letter word. 

First off, I tried 'cond' but that didn't work very well.

How come there's an "if" statement in Lisp, which does an If-else, but
if you want to do an If without an Else, you use "when"? I feel that
this is counter-intuitive, and I believe in intuitive behaviour in
computer languages and programs in general. I think it should be either
if-progn or if-no-else. 

As for 'reinventing WHEN', I would say that I was just *renaming* it. I
don't see how that's any worse than using a billion macros to do all
kinds of wacky and bizarre things, that nobody else would understand. 

Finally, I'm disappointed that my attempt to give some code back to the
Lisp community was met with nothing but complaints about my coding
style. I don't think I'll be posting any more code here in future. 

Jeremy.
From: Thomas A. Russ
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <ymi64rhsl1k.fsf@sevak.isi.edu>
Jeremy Smith <············@decompiler.org> writes:

> First off, I tried 'cond' but that didn't work very well.

What didn't work with COND?

> How come there's an "if" statement in Lisp, which does an If-else, but
> if you want to do an If without an Else, you use "when"? I feel that
> this is counter-intuitive, and I believe in intuitive behaviour in
> computer languages and programs in general. I think it should be either
> if-progn or if-no-else. 

I'm not entirely sure about the order in which features were added to
the language, but in the beginning, there was just COND.  (Well, maybe
in Lisp 1.5 there was just IF, but I don't go back quite that far.)
COND was the conditional form.  I think that WHEN and its reverse twin
UNLESS were added next, and IF last of all.

The reason for a different name is that IF takes only a single
expression for its true branch, requiring, as you discovered, that
multiple statements be wrapped in a progn.  So, also paralleling your
thought processes, it was decided that having a specialized macro for
the case where there is a single test where you only do something if the
test succeeds (or fails, for UNLESS) would be A Good Thing(tm).

Aside from saving a bit of typing by using

  (when (test-me foo)
     (do-one-thing foo bar)
     (do-another-thing foo bar))

instead of

   (if (test-me foo)
     (progn (do-one-thing foo bar)
            (do-another-thing foo bar)))

or 

   (cond ((test-me foo)
          (do-one-thing foo bar)
          (do-another-thing foo bar)))

the use of WHEN or UNLESS helps the reader by clearly signalling that
there is only ONE thing that should be done, so that one doesn't need to
look for more clauses in the IF or COND statement.  I miss that feature
when programming in languages like Java, where the only way to tell if
there is no "else" clause is to search the code for it and fail to find
it.  I find it much nicer to be told that upfront, as it were.


-- 
Thomas A. Russ,  USC/Information Sciences Institute
From: Pascal Bourguignon
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <87u0f1ucrb.fsf@thalassa.informatimago.com>
Jeremy Smith <············@decompiler.org> writes:
>> The correct response here is "Nice job reinventing WHEN!"
>> 
>
> Okay, I'm not amused by all these responses on changing an 8-letter word
> to a 4-letter word. 
>
> First off, I tried 'cond' but that didn't work very well.

Can't you read a specification page? (cond (test expr1 expr2 ... exprn))

but we will still argue that:        (when test expr1 expr2 ... exprn) 
is better.


> How come there's an "if" statement in Lisp, which does an If-else, but
> if you want to do an If without an Else, you use "when"? I feel that
> this is counter-intuitive, and I believe in intuitive behaviour in
> computer languages and programs in general. I think it should be either
> if-progn or if-no-else. 
>
> As for 'reinventing WHEN', I would say that I was just *renaming* it. I
> don't see how that's any worse than using a billion macros to do all
> kinds of wacky and bizarre things, that nobody else would understand. 
>
> Finally, I'm disappointed that my attempt to give some code back to the
> Lisp community was met with nothing but complaints about my coding
> style. I don't think I'll be posting any more code here in future. 

If you were programming in Scheme, we would have said nothing.

But the purpose of Common Lisp is exactly to reduce these kinds of
gratuituous variations.

if-progn/if-else is nice, but there are also if/when/unless, (if*
:then :else), if-then/if-then-else, etc.  There was a lot of LISP
implementations all differing slightly in such mundane and unimportant
details and it was a real PITA, so a lot of effort has been invested
to make Common Lisp, taking the _best_ approaches in all these
implementations.  If you don't  want to use Common Lisp, ok, but then
you're in another team, building your own new lisp.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
Small brave carnivores
Kill pine cones and mosquitoes
Fear vacuum cleaner
From: John Thingstad
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <op.szcsjba5pqzri1@mjolner.upc.no>
>
> Finally, I'm disappointed that my attempt to give some code back to the
> Lisp community was met with nothing but complaints about my coding
> style. I don't think I'll be posting any more code here in future.
>
> Jeremy.

I am not surprised. The CL Lisp community is known for being arrogant and
condescending toward beginners. I suggest you don't let it get to you.
After a while here you develop a thick skin.
Then you realize that the Lisp community is very knowledgeable and
more likely to help you when you really need it.
It might not always be entirely pleasant but, with (considerable)
effort, it will make you a better (Lisp) programmer.
Incidentally, they are right, they just love to rub your nose in it.

Take pride in you work! That is what good programmers good.
Just don't assume you know eveything. With a more humble
'newbie looking for improvements in code style' you would
have faired better.

Just in case you deside not to abandon comp.lang.lisp and
CL-Lisp altogether.

Happly lisping!

John.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Kenny Tilton
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <YTr8f.5116$u43.4455@twister.nyc.rr.com>
John Thingstad wrote:

>>
>> Finally, I'm disappointed that my attempt to give some code back to the
>> Lisp community was met with nothing but complaints about my coding
>> style. I don't think I'll be posting any more code here in future.
>>
>> Jeremy.
> 
> 
> I am not surprised. The CL Lisp community is known for being arrogant and
> condescending toward beginners.


Bullshit. Our arrogance and condescension is an instance attribute, not 
class.

> I suggest you don't let it get to you.
> After a while here you develop a thick skin.

The problem is not that the OP needs a thick skin, it is that they are a 
  nutjob. Keep watching.

> Then you realize that the Lisp community is very knowledgeable and
> more likely to help you when you really need it.
> It might not always be entirely pleasant but, with (considerable)
> effort, it will make you a better (Lisp) programmer.

In this case the only hope for the OP is if they become sane. We have 
never pulled that one off, I fear.

> Incidentally, they are right, they just love to rub your nose in it.

OK, come clean, when did we hurt /your/ feelings?


> 
> Take pride in you work! That is what good programmers good.
> Just don't assume you know eveything. With a more humble
> 'newbie looking for improvements in code style' you would
> have faired better.
> 
> Just in case you deside not to abandon comp.lang.lisp and
> CL-Lisp altogether.

Is c.l.l ready for another ilias?

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950
From: Duane Rettig
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <4slulbg3h.fsf@franz.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> John Thingstad wrote:
>
>>>
>>> Finally, I'm disappointed that my attempt to give some code back to the
>>> Lisp community was met with nothing but complaints about my coding
>>> style. I don't think I'll be posting any more code here in future.
>>>
>>> Jeremy.
>> I am not surprised. The CL Lisp community is known for being
>> arrogant and
>> condescending toward beginners.
>
>
> Bullshit. Our arrogance and condescension is an instance attribute,
> not class.

Yes, but the default initarg is T.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Kenny Tilton
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <SAv8f.12759$3A4.2838@news-wrt-01.rdc-nyc.rr.com>
Duane Rettig wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>John Thingstad wrote:
>>
>>
>>>>Finally, I'm disappointed that my attempt to give some code back to the
>>>>Lisp community was met with nothing but complaints about my coding
>>>>style. I don't think I'll be posting any more code here in future.
>>>>
>>>>Jeremy.
>>>
>>>I am not surprised. The CL Lisp community is known for being
>>>arrogant and
>>>condescending toward beginners.
>>
>>
>>Bullshit. Our arrogance and condescension is an instance attribute,
>>not class.
> 
> 
> Yes, but the default initarg is T.
> 

Poppycock! Here is the code:

(defmodel newby (programmer)
    ((cll-post :cell :ephemeral :initform (c-input nil)...)
     (troll-p :cell t
              :initform (c? (or .cache.
                                (deliberately-provocative-p
                                   (^cll-post))))
              ....)
     (iliastic :cell t
               :initform (c? (or .cache.
                                (argues-with-solid-guidance-from-guru-p
                                   (^cll-post)))))

Note that:

-- the state of the pejorative slots is not determined until the first 
cll-post. A newby might be instantiated along with their first post as 
an initarg:

(make-instance 'newby
    :name 'ilias
    :cll-post (c-in "How can I use brackets instead of parens in Lisp?"))

... and thus soon after initialze-instance get classified as an idiot, 
but that is /not/ how default-initargs work.

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950
From: Duane Rettig
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <4k6fxbb5i.fsf@franz.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> Duane Rettig wrote:
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>>John Thingstad wrote:
>>>
>>>
>>>>>Finally, I'm disappointed that my attempt to give some code back to the
>>>>>Lisp community was met with nothing but complaints about my coding
>>>>>style. I don't think I'll be posting any more code here in future.
>>>>>
>>>>>Jeremy.
>>>>
>>>>I am not surprised. The CL Lisp community is known for being
>>>>arrogant and
>>>>condescending toward beginners.
>>>
>>>
>>>Bullshit. Our arrogance and condescension is an instance attribute,
>>>not class.
>> Yes, but the default initarg is T.
>>
>
> Poppycock! Here is the code:

Your whole code is client-side:

> (defmodel newby (programmer)
>     ((cll-post :cell :ephemeral :initform (c-input nil)...)
>      (troll-p :cell t
>               :initform (c? (or .cache.
>                                 (deliberately-provocative-p
>                                    (^cll-post))))
>               ....)
>      (iliastic :cell t
>                :initform (c? (or .cache.
>                                 (argues-with-solid-guidance-from-guru-p
>                                    (^cll-post)))))
>
> Note that:
>
> -- the state of the pejorative slots is not determined until the first
> cll-post. A newby might be instantiated along with their first post as
> an initarg:
>
> (make-instance 'newby
>     :name 'ilias
>     :cll-post (c-in "How can I use brackets instead of parens in Lisp?"))
>
> ... and thus soon after initialze-instance get classified as an idiot,
> but that is /not/ how default-initargs work.

But you were talking about _our_ arrogance (too bad CLOS doesn't have
a "self" variable, so we know about whom we are referring).  A c.l.l.
regular, which serves up the arrogance, has a much different instantiation
model.  And, in true form, I will perform a hand-wave and say that I will
leave the actual coding of the server side model as an exercise for the
reader...

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Arthur Lemmens
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <opszdlv5m9k6vmsw@news.xs4all.nl>
Duane Rettig wrote:

> And, in true form, I will perform a hand-wave and say that I will
> leave the actual coding of the server side model as an exercise for the
> reader..

(defun cll-regular (cll)
  (let ((replies '("Nonsense!" "Poppycock!"  "Bullshit!")))
    (loop (let ((message (read-message cll)))
            (declare (ignore message))
            (write (elt replies (random (length replies)))
                   cll)))))

Untested of course.  But at least it doesn't use eval.
From: Pascal Costanza
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <3sfmprFnv7dfU2@individual.net>
Arthur Lemmens wrote:
> Duane Rettig wrote:
> 
>> And, in true form, I will perform a hand-wave and say that I will
>> leave the actual coding of the server side model as an exercise for the
>> reader..
> 
> 
> (defun cll-regular (cll)
>  (let ((replies '("Nonsense!" "Poppycock!"  "Bullshit!")))
>    (loop (let ((message (read-message cll)))
>            (declare (ignore message))
>            (write (elt replies (random (length replies)))
>                   cll)))))
> 
> Untested of course.  But at least it doesn't use eval.

ROTFLBTC!


Pascal

-- 
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Arthur Lemmens
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <opszdfgsdck6vmsw@news.xs4all.nl>
Duane Rettig wrote:

> Kenny Tilton <·······@nyc.rr.com> writes:
>
>> Bullshit. Our arrogance and condescension is an instance attribute,
>> not class.
>
> Yes, but the default initarg is T.

Hehe.  And it doesn't have any writer methods, does it?
From: Duane Rettig
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <4oe59bbgl.fsf@franz.com>
Arthur Lemmens <········@xs4all.nl> writes:

> Duane Rettig wrote:
>
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>> Bullshit. Our arrogance and condescension is an instance attribute,
>>> not class.
>>
>> Yes, but the default initarg is T.
>
> Hehe.  And it doesn't have any writer methods, does it?

Right. But we do find closure often, though.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: David Steuber
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <87irvhw8ig.fsf@david-steuber.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> In this case the only hope for the OP is if they become sane. We have
> never pulled that one off, I fear.

I can't parse this sentence.  Are you saying that Lisp newbies are
insane?

-- 
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
The lowest click through rate in Google's AdSense program.
----------------------------------------------------------------------
From: Kenny Tilton
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <DmA8f.12912$3A4.389@news-wrt-01.rdc-nyc.rr.com>
David Steuber wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>In this case the only hope for the OP is if they become sane. We have
>>never pulled that one off, I fear.
> 
> 
> I can't parse this sentence.  Are you saying that Lisp newbies are
> insane?
> 

I cannot parse your question <g>, because I clearly refer to just the 
OP. Perhaps it is the "they" which is throwing you off? If so, that is 
the best solution I have seen for a gender-neutral pronoun (OK, I could 
guess from the name, but it would still be subject to error and "they" 
cannot be wrong, so I just type it and get on with my life). I 
understand "they" as a gender-neutral singular pronoun is actually a 
Brit usage pre-dating the problem generated by women's lib.

Speaking of which, a chess book I am reading may have bent over a little 
too far backward on this issue, it just referred to the Black king as 
"she". Hmmm...

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950
From: David Steuber
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <871x25m2k5.fsf@david-steuber.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> David Steuber wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >>In this case the only hope for the OP is if they become sane. We have
> >>never pulled that one off, I fear.
> > I can't parse this sentence.  Are you saying that Lisp newbies are
> > insane?
> >
> 
> I cannot parse your question <g>, because I clearly refer to just the
> OP. Perhaps it is the "they" which is throwing you off? If so, that is
> the best solution I have seen for a gender-neutral pronoun (OK, I
> could guess from the name, but it would still be subject to error and
> "they" cannot be wrong, so I just type it and get on with my life). I
> understand "they" as a gender-neutral singular pronoun is actually a
> Brit usage pre-dating the problem generated by women's lib.

They confused me.  But you make a valid point.

So are you or are you not saying that Lisp newbies are insane?  Or are
you just saying the OP of this thread is insane?

> Speaking of which, a chess book I am reading may have bent over a
> little too far backward on this issue, it just referred to the Black
> king as "she". Hmmm...

That is going too far.

-- 
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
The lowest click through rate in Google's AdSense program.
----------------------------------------------------------------------
From: Kenny Tilton
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <xSE8f.12926$3A4.3008@news-wrt-01.rdc-nyc.rr.com>
David Steuber wrote:

> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>David Steuber wrote:
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>>
>>>>In this case the only hope for the OP is if they become sane. We have
>>>>never pulled that one off, I fear.
>>>
>>>I can't parse this sentence.  Are you saying that Lisp newbies are
>>>insane?
>>>
>>
>>I cannot parse your question <g>, because I clearly refer to just the
>>OP. Perhaps it is the "they" which is throwing you off? If so, that is
>>the best solution I have seen for a gender-neutral pronoun (OK, I
>>could guess from the name, but it would still be subject to error and
>>"they" cannot be wrong, so I just type it and get on with my life). I
>>understand "they" as a gender-neutral singular pronoun is actually a
>>Brit usage pre-dating the problem generated by women's lib.
> 
> 
> They confused me.  But you make a valid point.
> 
> So are you or are you not saying that Lisp newbies are insane?  Or are
> you just saying the OP of this thread is insane?

Well, having now established that what I said was that the OP is a 
whacko (I think a little terminological precision is in order if I am 
going to be taken so seriously on this grave matter), why are you asking 
the first question?

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950
From: David Steuber
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <87y84bj1hd.fsf@david-steuber.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> David Steuber wrote:
> 
> > So are you or are you not saying that Lisp newbies are insane?  Or
> > are you just saying the OP of this thread is insane?
> 
> Well, having now established that what I said was that the OP is a
> whacko (I think a little terminological precision is in order if I am
> going to be taken so seriously on this grave matter), why are you
> asking the first question?

Interrogatories are often used in an attempt to gather factual
information.  This is the case here.  I asked a question in order to
learn your general view of Lisp newbies.  While it is now clear to me
how you feel about the OP, it is not clear to me how you feel about
Lisp newbies in general or newbies who wish to rename well known Lisp
macros to suit their idea of what is and is not intuitive.

Regarding Lisp newbies who wish to rename well known Lisp macros; that
actually was not part of the original question.  I had to ^ up the
thread to remind myself of the context.  Feel free to gather all your
opinions of Lisp newbiehood together and express them in one place.

Any unaddressed issues concerning "why" I leave to the philosophers
who are much more qualified to address such things.

-- 
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
The lowest click through rate in Google's AdSense program.
----------------------------------------------------------------------
From: Kenny Tilton
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <qiX8f.13074$3A4.6661@news-wrt-01.rdc-nyc.rr.com>
With no small delight do I sense that this insanity could drag on for 
weeks. I will do my best to inflame and magnify....

David Steuber wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>David Steuber wrote:
>>
>>
>>>So are you or are you not saying that Lisp newbies are insane?  Or
>>>are you just saying the OP of this thread is insane?
>>
>>Well, having now established that what I said was that the OP is a
>>whacko (I think a little terminological precision is in order if I am
>>going to be taken so seriously on this grave matter), why are you
>>asking the first question?
> 
> 
> Interrogatories are often used in an attempt to gather factual
> information.  This is the case here.

Oh, please, hot on the heels of your misconstruing what I said to be a 
generic slam on newcomers to our shores? as if.

>  I asked a question in order to
> learn your general view of Lisp newbies.  While it is now clear to me
> how you feel about the OP, it is not clear to me how you feel about
> Lisp newbies in general...

You are ignorant then of my "Road to Lisp Survey"?


>... or newbies who wish to rename well known Lisp
> macros to suit their idea of what is and is not intuitive.

You are a careless reader. I did not support if-progn, I castigated the 
school marms ordering the OP to stop having fun and break open the 
books. Note that my own proposed response did provide a gentle hint that 
a wheel was being reinvented.

Who amongst us cannot look back at early code and find all sorts of 
wheel reinventions? I get a kick out of that. It reminds me how big is 
the language, how easy wheels are to reinvent, and how little interest I 
have in studying when I could be working.

> 
> Regarding Lisp newbies who wish to rename well known Lisp macros; that
> actually was not part of the original question.  I had to ^ up the
> thread to remind myself of the context.

How diligent of you. :) I do not think our threadfork deserves it.

>  Feel free to gather all your
> opinions of Lisp newbiehood together and express them in one place.

I think I have just been assigned homework. While I work on that, yours 
is to collect all my prior newby-related posts to Google and compare and 
contrast.

> 
> Any unaddressed issues concerning "why" I leave to the philosophers
> who are much more qualified to address such things.
> 

Sorry, before I prepare my Collected Newby Opinions you will have to 
explain why you are asking, because I cannot otherwise prepare it with 
any confidence of adequately satisfying you and putting an end to this 
idiocy. Hmmm, come to think of it, no, my record on the full taxonomy 
newbies is unmistakeable given my cll opus. What can I say? RTFGA.

:)

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950
From: David Steuber
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <87oe56wj2r.fsf@david-steuber.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> With no small delight do I sense that this insanity could drag on for
> weeks. I will do my best to inflame and magnify....

That's the spirit!  Now if only my attention span was sufficient to
last the duration of a fifteen second television commercial.

> David Steuber wrote:
> > Interrogatories are often used in an attempt to gather factual
> > information.  This is the case here.
> 
> Oh, please, hot on the heels of your misconstruing what I said to be a
> generic slam on newcomers to our shores? as if.

You've got a point here.  Lawyers use interrogatories strictly for
nefarious purposes.

> You are ignorant then of my "Road to Lisp Survey"?

I've been meaning to take a look at that.  I know it exists, but
otherwise yes.

> >... or newbies who wish to rename well known Lisp
> > macros to suit their idea of what is and is not intuitive.
> 
> You are a careless reader. I did not support if-progn, I castigated
> the school marms ordering the OP to stop having fun and break open the
> books. Note that my own proposed response did provide a gentle hint
> that a wheel was being reinvented.

I'm sorry your use of irony had such low ferrous content as to not
divert a compass.  However the pH level did drop below that of lemon
juice, so you deserve full credit there.

> Who amongst us cannot look back at early code and find all sorts of
> wheel reinventions? I get a kick out of that. It reminds me how big is
> the language, how easy wheels are to reinvent, and how little interest
> I have in studying when I could be working.

Certainly not I.  I have observed that the transportation sector is
constantly refining the wheel though.

As a careless reader I got the impression that the 10x upfront
productivity boost of a thirty second macro implementation vs five
minutes to find WHEN in the CLHS was somehow praised by your post.

> > Regarding Lisp newbies who wish to rename well known Lisp macros;
> > that
> > actually was not part of the original question.  I had to ^ up the
> > thread to remind myself of the context.
> 
> How diligent of you. :) I do not think our threadfork deserves it.

And it turns out that you are right.

> >  Feel free to gather all your
> > opinions of Lisp newbiehood together and express them in one place.
> 
> I think I have just been assigned homework. While I work on that,
> yours is to collect all my prior newby-related posts to Google and
> compare and contrast.

It was a simple invitation, not an assignment.  But since you are
working on it...

> > Any unaddressed issues concerning "why" I leave to the philosophers
> > who are much more qualified to address such things.
> >
> 
> Sorry, before I prepare my Collected Newby Opinions you will have to
> explain why you are asking, because I cannot otherwise prepare it with
> any confidence of adequately satisfying you and putting an end to this
> idiocy. Hmmm, come to think of it, no, my record on the full taxonomy
> newbies is unmistakeable given my cll opus. What can I say? RTFGA.

I have collected all your usenet posts, collated them, printed them
out, and now have them fermenting in soft peat.  When they are ready,
I will filter the contents, distill it, and then let it age in fine
French Oak casks that were previously used for a vintage Merlot.  In
12 years it should make a fine whiskey.

-- 
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
The lowest click through rate in Google's AdSense program.
----------------------------------------------------------------------
From: Ulrich Hobelmann
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <3sha5aFo5e8vU1@individual.net>
Kenny Tilton wrote:
> Speaking of which, a chess book I am reading may have bent over a little 
> too far backward on this issue, it just referred to the Black king as 
> "she". Hmmm...

In a Shakespeare play a couple centuries back, the Queen would have been 
played by a "he", so who knows... :D

-- 
The road to hell is paved with good intentions.
From: Rainer Joswig
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <BF87D882.1C3A2%joswig@lisp.de>
Am 28.10.2005 12:40 Uhr schrieb "Jeremy Smith" unter
<············@decompiler.org> in
··································@62.253.170.163:


> Okay, I'm not amused by all these responses on changing an 8-letter word
> to a 4-letter word.
> 
> First off, I tried 'cond' but that didn't work very well.
> 
> How come there's an "if" statement in Lisp, which does an If-else, but
> if you want to do an If without an Else, you use "when"? I feel that
> this is counter-intuitive, and I believe in intuitive behaviour in
> computer languages and programs in general. I think it should be either
> if-progn or if-no-else.
> 
> As for 'reinventing WHEN', I would say that I was just *renaming* it. I
> don't see how that's any worse than using a billion macros to do all
> kinds of wacky and bizarre things, that nobody else would understand.

Learn to live with the language. Understand what it already offers.

> Finally, I'm disappointed that my attempt to give some code back to the
> Lisp community was met with nothing but complaints about my coding
> style. I don't think I'll be posting any more code here in future.

Oh, I thought the purpose of posting code to c.l.l is to get
feedback (even if it is concerned with style). If you
don't want feedback, you should not post here.

Actually posting code here to get feedback is very welcome. It
is definitely more useful than all the stupid
prefix/infix-discussions.

So, don't give up easily. ;-)
From: Jeremy Smith
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <Xns96FDBFD0CE3D9jeremyalansmithsofth@80.5.182.99>
Rainer Joswig <······@lisp.de> wrote in
··························@lisp.de: 

> Am 28.10.2005 12:40 Uhr schrieb "Jeremy Smith" unter
> <············@decompiler.org> in
> ··································@62.253.170.163:
> 
>> Finally, I'm disappointed that my attempt to give some code back to
>> the Lisp community was met with nothing but complaints about my
>> coding style. I don't think I'll be posting any more code here in
>> future. 
> 
> Oh, I thought the purpose of posting code to c.l.l is to get
> feedback (even if it is concerned with style). If you
> don't want feedback, you should not post here.
> 
> Actually posting code here to get feedback is very welcome. It
> is definitely more useful than all the stupid
> prefix/infix-discussions.
> 
> So, don't give up easily. ;-)

Hi,

Well I did take it rather to heart as I gave out the code in good faith,
but it's true that I should find if the macro I'm writing already
exists, at least if the code it's part of, is to be released to the
public. 

However, I wasn't posting the code to get feedback, but just so that
people can use it. 

Jeremy.
From: Pascal Costanza
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <3sf71jFn907bU1@individual.net>
Jeremy Smith wrote:

> However, I wasn't posting the code to get feedback, but just so that
> people can use it. 

In a newsgroup, you never post for yourself alone. Maybe you are not 
interested in feedback, but there are other people reading our postings, 
some of them probably in order to learn Lisp, so the feedback on what is 
more idiomatic than what you have written is probably useful for them.


Pascal

-- 
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Lars Brinkhoff
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <853bmj4cvd.fsf@junk.nocrew.org>
Jeremy Smith <············@decompiler.org> writes:
> I wasn't posting the code to get feedback, but just so that people
> can use it.

There's a mailing list for that:

http://www.hexapodia.net/mailman/listinfo/small-cl-src
From: Juho Snellman
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <slrndm4rsf.4lc.jsnell@sbz-30.cs.Helsinki.FI>
<············@decompiler.org> wrote:
> Finally, I'm disappointed that my attempt to give some code back to the
> Lisp community was met with nothing but complaints about my coding
> style. I don't think I'll be posting any more code here in future. 

Frankly I'm surprised at how little flak you got about your coding
style. That was some of the worst-formatted Lisp code I've ever seen,
and that's saying quite a lot. I also have doubts about it being "very
fast, even in Lisp" as you claim. That code could probably be reworked
to be at least 100x faster. Except that:

  * Your code sucks so much that it'd be less work to start from scratch.
  * It would be a complete waste of time, since you've already decided to go
    home and take your toys with you.

But by all means, feel free to resent the "Lisp community" for not
appreciating your valuable contribution.

-- 
Juho Snellman
"Premature profiling is the root of all evil."
From: Jeremy Smith
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <Xns96FDD3DEE9A72jeremyalansmithsofth@62.253.170.163>
Juho Snellman <······@iki.fi> wrote in
··························@sbz-30.cs.Helsinki.FI: 

> <············@decompiler.org> wrote:
>> Finally, I'm disappointed that my attempt to give some code back to
>> the Lisp community was met with nothing but complaints about my
>> coding style. I don't think I'll be posting any more code here in
>> future. 
> 
> Frankly I'm surprised at how little flak you got about your coding
> style. That was some of the worst-formatted Lisp code I've ever seen,
> and that's saying quite a lot.

Any Lisper would say the formatting doesn't matter, because of the 
parentheses. My formatting merely follows the delineatino of the 
brackets.

> I also have doubts about it being "very
> fast, even in Lisp" as you claim.

Well try telling that to the author, who has written a very fast 
*algorithm*, many times faster than a different bicubic-resizing function 
I ported from C++. I just ported it from C, and I see no advantages of 
fixed typing, as the code is all floating-point based. So if you want to 
improve it, you need to improve the *algorithm*, not the code.

> That code could probably be reworked
> to be at least 100x faster. Except that:
> 
>   * Your code sucks so much that it'd be less work to start from
>   scratch. * It would be a complete waste of time, since you've
>   already decided to go 
>     home and take your toys with you.

I didn't ask you to rewrite it from scratch. I just said it's very fast, 
which it is.

If you want to rewrite the bicubic resizing algorithm "from scratch", 
then you'll either need to:

    	*Read Michael's paper, understand it, code it up, test it, speed it 
up, and maybe use the sample C code as a reference for fixing any bugs

    	*Find another bicubic resizing algorithm, read the paper, understand 
it, code it up, test it, find it's too slow, and give up

> But by all means, feel free to resent the "Lisp community" for not
> appreciating your valuable contribution.

I don't resent the Lisp community, as there's been a lot of good things 
come from it, like the gratis books and compilers, and the enthusiasm of 
the advocates. In fact if I resented anyone, I wouldn't have posted the 
code. I just resent people who deny that free spirit by laying into 
contributions that puts people off being generous.

I think you would be in a good position to criticise my code if you had 
written a bicubic resizing function in Lisp, made it available, and such 
an algorithm was not already available online. If not, then it sounds 
more like a flame than a critique.

Cheers,

Jeremy.
From: Thomas A. Russ
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <ymizmotqcq6.fsf@sevak.isi.edu>
Jeremy Smith <············@decompiler.org> writes:

> Any Lisper would say the formatting doesn't matter, because of the 
> parentheses. My formatting merely follows the delineatino of the 
> brackets.

Au contraire.  It is the compiler that uses the parentheses and couldn't
care less about the formatting.  Lisp users are often quite passionate
about formatting, because the formatting is meant for human users.  The
formatting conveys the structure of the code to humans, who generally
learn to overlook most of the (close) parentheses since they are
redundant with proper formatting.

That said, I don't recall the original code as being poorly formatted.
At least not the section I commented upon.

-- 
Thomas A. Russ,  USC/Information Sciences Institute
From: Juho Snellman
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <slrndm56j0.6ff.jsnell@sbz-30.cs.Helsinki.FI>
<············@decompiler.org> wrote:
> Juho Snellman <······@iki.fi> wrote in
> ··························@sbz-30.cs.Helsinki.FI: 
>> Frankly I'm surprised at how little flak you got about your coding
>> style. That was some of the worst-formatted Lisp code I've ever seen,
>> and that's saying quite a lot.
> 
> Any Lisper would say the formatting doesn't matter, because of the 
> parentheses. My formatting merely follows the delineatino of the 
> brackets.

I think very few Lisp programmers would agree with that. Formatting
the code properly (i.e. indenting correctly, breaking the lines at the
right places and putting whitespace into the correct places) is at
least as important in Lisp as in other languages. This is especially
true for code that's made public.

For example:

>>> (defun bicubic-resize(n d f a MAX-PIXEL)
>>>  (let ((MAX-OUT-WIDTH (* (length(first f)) (/ n d))) (MAX-OUT-HEIGHT (* 
>>> (length f) (/ n d))) (MAX-IN-WIDTH (length(first f))) (in-width (length
>>> (first f))) (in-height (length f))(MAX-IN-HEIGHT (length f)))

Words fail me.

>> I also have doubts about it being "very
>> fast, even in Lisp" as you claim.
> 
> Well try telling that to the author, who has written a very fast 
> *algorithm*, many times faster than a different bicubic-resizing function 
> I ported from C++. I just ported it from C, and I see no advantages of 
> fixed typing, as the code is all floating-point based. 

My observation was on the implementation, not the algorithm. The
algorithm might be float-based, your code isn't. Practically all of
the calculations you're doing are generic. A lot of them are even
using rationals.

> I didn't ask you to rewrite it from scratch. I just said it's very fast, 
> which it is.

Scaling a 512x512 image to 256x256 takes 4.5 seconds on my Athlon 64.
Magnifying it to 1024x1024 takes over 18 seconds. That doesn't seem
very fast. Of course just using a sensible representation for the
images (i.e. a 2d array instead of a list of lists) would speed this
up immensely.

> If you want to rewrite the bicubic resizing algorithm "from scratch", 
> then you'll either need to:
> 
>     	*Read Michael's paper, understand it, code it up, test it, speed it 
> up, and maybe use the sample C code as a reference for fixing any bugs

I expect that transcribing from C to CL would indeed be less trouble
than sorting out your code.

> I don't resent the Lisp community, as there's been a lot of good things 
> come from it, like the gratis books and compilers, and the enthusiasm of 
> the advocates. In fact if I resented anyone, I wouldn't have posted the 
> code. I just resent people who deny that free spirit by laying into 
> contributions that puts people off being generous.

This is the crux of the problem. You aren't actually being generous.
Your code (especially if released on Cliki like you intended to) is a
liability, not an asset.

> I think you would be in a good position to criticise my code if you had 
> written a bicubic resizing function in Lisp, made it available, and such 
> an algorithm was not already available online. 

Ah, the good old "let's see *you* write a better book" fallacy. Sorry,
I have no use for a bicubic resizing function and lots of more
interesting Lisp projects to work on. That doesn't mean that I'm not
qualified to criticize the code.

> If not, then it sounds more like a flame than a critique.

Yes, of course it was a flame. You'd already said that constructive
critique wasn't welcome.

-- 
Juho Snellman
"Premature profiling is the root of all evil."
From: Alain Picard
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <87y84d86am.fsf@memetrics.com>
Jeremy Smith <············@decompiler.org> writes:

> Any Lisper would say the formatting doesn't matter, because of the 
> parentheses. My formatting merely follows the delineatino of the 
> brackets.

Must be freshman time again in the northern hemisphere....  sigh.
From: Jeremy Smith
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <Xns96FDD4EAE4B73jeremyalansmithsofth@62.253.170.163>
Juho Snellman <······@iki.fi> wrote in
··························@sbz-30.cs.Helsinki.FI: 

> That code could probably be reworked
> to be at least 100x faster. Except that:

I didn't want to use up any more bandwidth, but your signature struck me as 
apt:

    	"Premature profiling is the root of all evil."

The code I posted *works*, and I read that the stages of software 
development are: make it work, make it work well, and finally make it work 
fast, which is what your signature says. I'd say 2 out of 3 aren't at all 
bad.

Cheers,

Jeremy.
From: Pascal Bourguignon
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <871x26x5y7.fsf@thalassa.informatimago.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> (loop while <condition> do ...)
> Get rid of LBREAK and MYWHILE immediately! :)

Or at least, write it as:

(defmacro while (condition &body body) `(loop :while ,condition :do ,@body))


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Nobody can fix the economy.  Nobody can be trusted with their finger
on the button.  Nobody's perfect.  VOTE FOR NOBODY.
From: Thomas A. Russ
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <ymi7jbxslho.fsf@sevak.isi.edu>
Jeremy Smith <············@decompiler.org> writes:

> ;Not very efficient, but not slow
> (defun array-to-list(array)
>   (let ((x (first(array-dimensions array))) (y (second(array-dimensions 
> array))))
>   (let ((retval (list)))
>     (dotimes (y1 y)
>       (let ((temp-row (list)))
>         (dotimes (x1 x)
>           (push (aref array x1 y1) temp-row))
>         (push (reverse temp-row) retval)))
>     (reverse retval))))

The loop accumulation could be made faster by using LOOP and the
collection mechanism, which would eliminate the need to REVERSE the
backbones of the lists.  BTW, it would have been safe to use NREVERSE in
the code above, since all of the list structure is newly allocated.

Anyway, the loop version:

(defun array-to-list (array)
  (loop with (x-max y-max) = (array-dimensions array)
        for y below y-max
        collect (loop for x below x-max
                      collect (aref array x y))))

This makes use of destructuring binding and the COLLECT feature.


-- 
Thomas A. Russ,  USC/Information Sciences Institute
From: Jeremy Smith
Subject: Re: Bicubic resizing algorithm for Lisp
Date: 
Message-ID: <Xns96FDCC1E82535jeremyalansmithsofth@62.253.170.163>
···@sevak.isi.edu (Thomas A. Russ) wrote in 
····················@sevak.isi.edu:

> The loop accumulation could be made faster by using LOOP and the
> collection mechanism, which would eliminate the need to REVERSE the
> backbones of the lists.  BTW, it would have been safe to use NREVERSE in
> the code above, since all of the list structure is newly allocated.
> 
> Anyway, the loop version:

Hi,

Thanks for this.

I'm a newbie at Lisp, so all this is new to me. I've got lots more reading 
to do!

Jeremy.