Hello,
I have this piece of code:
(defun f(x) (declare (optimize speed debug safety) (special N) (type
(simple-array fixnum 10) N) (fixnum x)) (* (+ (aref N 1) 2) (- x 1)))
I got lots of notes under SBCL: unable to optimize *'s, +'s etc. What
is the correct way to place the's inside this code? Can typing be
saved with use of macros?
On 2 ÉÀÎ, 13:55, zoav1602 <········@gmail.com> wrote:
> Hello,
> I have this piece of code:
>
> (defun f(x) (declare (optimize speed debug safety) (special N) (type
> (simple-array fixnum 10) N) (fixnum x)) (* (+ (aref N 1) 2) (- x 1)))
>
> I got lots of notes under SBCL: unable to optimize *'s, +'s etc. What
> is the correct way to place the's inside this code? Can typing be
> saved with use of macros?
Problem with optimization is because while sbcl knows that (aref N 1)
is a fixnum, twice this value might be out of range. So, every
arithmetic operation should be wrapped with (the 'expected-type expr).
Or you can explicitly declare (type (simple-array (unsigned-byte XXX)
10) N) ((unsigned-byte XXX) x)), and sbcl should be able to derive by
itself that results of operations will fit into fixnum (without
explicitly using the's).
zoav1602 <········@gmail.com> writes:
> Hello,
> I have this piece of code:
>
> (defun f(x) (declare (optimize speed debug safety) (special N) (type
> (simple-array fixnum 10) N) (fixnum x)) (* (+ (aref N 1) 2) (- x 1)))
It's hard to read Lisp code that isn't indented properly.
Is N really a ten-dimensional array of fixnums?
> I got lots of notes under SBCL: unable to optimize *'s, +'s etc. What
> is the correct way to place the's inside this code? Can typing be
> saved with use of macros?
You would probably have better luck using something other than
fixnum. If, for example, you know your result fits in 32 bits, or you
want wraparound instead of bignums, you can use (UNSIGNED-BYTE 32) as
the type, and sprinkle in something like
(LOGAND #xFFFFFFFF <the computation>) to get some pretty fast inline
modular arithmetic.
Zach
On Tue, 02 Jun 2009 02:55:56 -0700, zoav1602 wrote:
> Hello,
> I have this piece of code:
>
> (defun f(x) (declare (optimize speed debug safety) (special N) (type
> (simple-array fixnum 10) N) (fixnum x)) (* (+ (aref N 1) 2) (- x 1)))
>
> I got lots of notes under SBCL: unable to optimize *'s, +'s etc. What is
> the correct way to place the's inside this code? Can typing be saved
> with use of macros?
Maybe if you gave more context, it would be easier to get help.
Depending on what you are doing, you could inline this function, or
use closures either over N or even (aref N 1), assigning the latter to
a variable.
It is meaningless to ask for optimization advice on one-liners out of
context.
Tamas
zoav1602 <········@gmail.com> writes:
> The solution I came upon so far, is
> #+sbcl(declaim (sb-ext:muffle-conditions sb-ext:compiler-note))
> which just hides all disturbing notes ;)
That works when a doctor is trying to give you bad news, too. You can
stick your fingers in your ears and say "nyaaa, nyaaa, nyaaa" and at the
end of the visit you will feel perfectly fine.
Zach
On 3 ÉÀÎ, 01:45, Zach Beane <····@xach.com> wrote:
> zoav1602 <········@gmail.com> writes:
> > The solution I came upon so far, is
> > #+sbcl(declaim (sb-ext:muffle-conditions sb-ext:compiler-note))
> > which just hides all disturbing notes ;)
>
> That works when a doctor is trying to give you bad news, too. You can
> stick your fingers in your ears and say "nyaaa, nyaaa, nyaaa" and at the
> end of the visit you will feel perfectly fine.
>
> Zach
Yeah, I know :)
In fact, replacing fixnum with (signed-byte 32) works well too, thanks
for the advice.
Graham in his "ANSI Common Lisp", p.219 puts (the fixnum ...)
everywhere. He seems to like fixnums. Alas, this doesn't make sbcl not
to complain.
zoav1602 <········@gmail.com> writes:
> Graham in his "ANSI Common Lisp", p.219 puts (the fixnum ...)
> everywhere. He seems to like fixnums. Alas, this doesn't make sbcl not
> to complain.
Paul Graham is not, in general, a good source of Common Lisp advice.
Zach
On Jun 3, 2:39 am, Zach Beane <····@xach.com> wrote:
> zoav1602 <········@gmail.com> writes:
> > Graham in his "ANSI Common Lisp", p.219 puts (the fixnum ...)
> > everywhere. He seems to like fixnums. Alas, this doesn't make sbcl not
> > to complain.
>
> Paul Graham is not, in general, a good source of Common Lisp advice.
>
> Zach
In what sense do you mean this? I was under the impression that he has
very good ideas. His books ANSI CL and On Lisp seem to be in high
regard as well... so I'm a bit confused as to what exactly you mean --
could you please clarify a bit?
Thanks,
Adlai
On 3 Jun., 04:11, Adlai <·········@gmail.com> wrote:
> On Jun 3, 2:39 am, Zach Beane <····@xach.com> wrote:
>
> > zoav1602 <········@gmail.com> writes:
> > > Graham in his "ANSI Common Lisp", p.219 puts (the fixnum ...)
> > > everywhere. He seems to like fixnums. Alas, this doesn't make sbcl not
> > > to complain.
>
> > Paul Graham is not, in general, a good source of Common Lisp advice.
>
> > Zach
>
> In what sense do you mean this? I was under the impression that he has
> very good ideas. His books ANSI CL and On Lisp seem to be in high
> regard as well... so I'm a bit confused as to what exactly you mean --
> could you please clarify a bit?
>
> Thanks,
> Adlai
Both are older books. 'ANSI CL' is a bit dry and without much passion
(compare 'Practical Common Lisp'). 'On Lisp' is a lot about certain
programming techniques (lots of stuff on macros). Some other
programming
techniques are mostly not covered - like OOP. The books are not enough
to understand much of the Common Lisp code that is out there.
Both books are useful, but don't give a complete overview of CL
and its usage. From reading 'On Lisp' you get a good impression
of his (PG) favored programming styles.
Since several years he turned into a Common Lisp hater/cynic/critic.
He criticizes Common Lisp for its design and for the size
of some of the code written with it. He is designing/implementing
his own Lisp dialect, Arc, that should allow to write much
shorter programs for the domains he seems to be interested in.
The advice you get from him nowadays is mostly not in favor
of CL.
Not that he is necessarily wrong about what he was/is saying,
but he was very vocal about it and it created high
expectations for his Arc dialect of Lisp - which it kind of failed
to match then... It looked like an arbitrary Lisp dialect
with short identifiers. If you read his example code
in the Arc distribution, it does not look too bad, though.
Looks like 'On Lisp' applied.
Just a few days ago a new Arc version was published:
http://www.arclanguage.org/item?id=9383
Adlai <·········@gmail.com> writes:
> On Jun 3, 2:39 am, Zach Beane <····@xach.com> wrote:
>> zoav1602 <········@gmail.com> writes:
>> > Graham in his "ANSI Common Lisp", p.219 puts (the fixnum ...)
>> > everywhere. He seems to like fixnums. Alas, this doesn't make sbcl not
>> > to complain.
>>
>> Paul Graham is not, in general, a good source of Common Lisp advice.
>>
>> Zach
>
> In what sense do you mean this?
Let's take ANSI Common Lisp for example. If you look in the index under
"packages", you will find "packages, grossness of". The explanation so
indexed does not provide a helpful description of how to use packages,
and I think they're an essential part of writing Common Lisp software
that can be used by others.
CLOS gets similar, if slightly less shabby, treatment. After a cursory
explanation of CLOS, he develops his own tiny closure-based object
system and rhetorically asks if the elephantine bulk of CLOS is really
needed, and isn't object-oriented programming just a fancy way to write
unmaintainable spaghetti code anyway? That's not my experience with CLOS
at all, and I think a book that shows the novel and helpful ways to use
CLOS instead would serve any CL user better. Practical Common Lisp is an
example.
He has described the book ANSI Common Lisp as not really about Common
Lisp style, but about an ideal Lisp style. That isn't helpful for people
who want to write specifically in the Common Lisp style. (It's easy to
spot people who have read only ANSI Common Lisp for learning Common
Lisp, because they name variables "lst".)
http://www.cs.northwestern.edu/academics/courses/325/readings/graham/graham-notes.html
has some more information about what might be considered odd in the ANSI
Common Lisp book.
> I was under the impression that he has very good ideas.
Some of his ideas about Lisp are expressed in Arc. I haven't found it to
be very exciting or interesting. You can decide for yourself by
reviewing the Lisp code in http://www.ycombinator.com/arc/arc3.tar.
> His books ANSI CL and On Lisp seem to be in high regard as well...
ANSI Common Lisp is the first Common Lisp book I read, and at the time I
thought it was quite innovative. After reading other books, like
Paradigms of AI Programming by Peter Norvig and Practical Common Lisp by
Peter Seibel, and reading the source code of Common Lisp libraries and
applications, I found ANSI Common Lisp too unusual and out-of-sync with
regular Common Lisp to use it as a reference or guidebook.
I didn't have a good impression of On Lisp when I read it last, but it
was a long time ago and other people seem to enjoy it. YMMV.
> so I'm a bit confused as to what exactly you mean -- could you please
> clarify a bit?
It seems to me that Paul Graham finds Common Lisp unpleasant. I'd rather
learn about Common Lisp from someone who uses it joyfully than someone
who holds his nose while using it.
I'm reminded of Nikodemus Siivola's recent observation:
I think many people who were around for the ANSI standardization
process have a distinctly different view of Common Lisp than those who
came in later: the first group of people have a tendency to see it as
a historical accident [where] they didn't get some things right — whereas
I (and I believe many others too) see CL as something that did get
many things right. These aren't mutually exclusive of course, but is a
different emphasis.
http://random-state.net/log/3452867927.html
Zach