Help wiht LISP Function (Newbie)
Tortolo
both parameters are atoms and the value of the first parameter is
greater than the value of the second, otherwise it returns nil. This
LISP function, takes a simple list of numbers as a single parameter,
and returns the maximum value in the list.
Thanks,
Tortolo
Marc Spitzer
is this your home work? it realy looks like home work.
marc
Barry Margolin
Tortolo <jcar...@ecopetrol.com.co> wrote:
>I nee a LISP function, which takes two parameters and returns T if
>both parameters are atoms and the value of the first parameter is
>greater than the value of the second, otherwise it returns nil. This
Not all atoms have an obvious ordering relationship? For instance, if one
atom is a number and the other is a symbol, how do you determine which one
is "greater"? Even if you require both atoms to be the same type, what
about things like 2-dimensional arrays?
Did you really mean "both parameters are numbers"? In that case, isn't the
built-in > function what you want? You can use IGNORE-ERRORS to return NIL
if both parameters aren't numbers.
>LISP function, takes a simple list of numbers as a single parameter,
>and returns the maximum value in the list.
I thought you just needed one function. This seems to be a different
function, although it would make use of the first function. Take a look at
the REDUCE and MAX functions.
BTW, it's considered polite to tell us if you're asking for help with
homework. And if so, you should show what you tried so that we could
critique it, rather than expecting us to simply do your work for you.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Coby Beck
"Tortolo" <jcar...@ecopetrol.com.co> wrote in message
news:26176b48.01102...@posting.google.com...
There isn't one. You'll have to write it.
j...@itasoftware.com
Facetious answer:
(defun weird (a &optional (b nil b-supplied-p))
(ignore-errors
(if (not b-supplied-p)
(reduce #'max a)
(> a b))))
This does what you said, but I doubt it is what you want.
Tortolo
My Function is:
(define maxlist (list)
(apply #'max list))
(maxlist '(1 2 3 4 3 2 1)) => 4
Thanks,
Tortolo
Thomas F. Burdick
First, does the above work in any languge? (define ...) looks like
scheme, but (apply #'max ...) looks like lisp.
Second, assuming you meant (defun ...), that won't work for lists of
arbitrary length:
[1]> (defun maxlist (list) (apply #'max list))
MAXLIST
[2]> (maxlist (loop for x from 1 to (1+ call-arguments-limit)
collect x))
The above will give you an error (although you'll probably run out of
memory first, if you're using CLISP. CALL-ARGUMENTS-LIMIT is
4294967296 in my copy!)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Jeff Mincy
> jcar...@ecopetrol.com.co (Tortolo) writes:
>
> > j...@itasoftware.com wrote in message news:<g08bzd...@itasoftware.com>...
> > My Function is:
> >
> > (define maxlist (list)
> > (apply #'max list))
(reduce #'max list) would be better. Of course, neither of these answer
the original question of having two argument function.
> > (maxlist '(1 2 3 4 3 2 1)) => 4
>
> First, does the above work in any languge? (define ...) looks like
> scheme, but (apply #'max ...) looks like lisp.
>
> Second, assuming you meant (defun ...), that won't work for lists of
> arbitrary length:
>
> [1]> (defun maxlist (list) (apply #'max list))
> MAXLIST
> [2]> (maxlist (loop for x from 1 to (1+ call-arguments-limit)
> collect x))
>
> The above will give you an error (although you'll probably run out of
> memory first, if you're using CLISP. CALL-ARGUMENTS-LIMIT is
> 4294967296 in my copy!)
The call-arguments-limit constant is entirely overrated.
A value of 4294967296 in clisp means that the implementors:
1) probably push arguments on a stack and stacks are addressed with 32
bit ints.
2) did not do anything in the implementation to restrict the number of
arguments.
3) had no idea what to do with this 'constant' because it is really a
function that depends on the current stack depth and the size of
the stack, and what other programs are running on the machine.
4) made up an answer of 2^32 (which is wrong, if they push a return
address on the stack).
-jeff
Christopher Stacy
Tortolo> both parameters are atoms and the value of the first parameter is
Tortolo> greater than the value of the second, otherwise it returns nil. This
Tortolo> LISP function, takes a simple list of numbers as a single parameter,
Tortolo> and returns the maximum value in the list.
Is this your homework?
The problem description is poorly worded, but I think I can guess
what is being asked for. Will you first tell is the name of the
school where this is being taught, what book you're using,
which implementation of Lisp (if you know),
and provide the original problem description?
Meanwhile, I'll comment on the function you provided.
Tortolo> (define maxlist (list)
Tortolo> (apply #'max list))
Calling (APPLY #'F (LIST 1 2 3 4))
is the same as (F 1 2 3 4)
Based on the problem description, I think you're supposed to
be learning about: writing one function that calls another,
certain built-in functions, return values and boolean
truth values, passing arguments, what lists are, and something
about how to do one or more of: mapping, iteration, or recursion.
Thomas F. Burdick
> The call-arguments-limit constant is entirely overrated.
>
> A value of 4294967296 in clisp means that the implementors:
But of course, not every CL has an insanely huge CALL-ARGUMENTS-LIMIT.
I agree that it can be reasonable to assume that you can apply a
sufficiently huge number of arguments, if that's the reasonable way to
solve whatever problem you're solving. In a case where REDUCE is
screaming to be used, though, it's silly not to use it. If you do use
APPLY for something like this, it certainly behooves you do document
the possible limitation so as not to give future porters unnecessary
headaches. And that, to me, sounds like more of a pain in the butt
than just using REDUCE.
Erik Naggum
| But of course, not every CL has an insanely huge CALL-ARGUMENTS-LIMIT.
apply and reduce exhibit the same weird design problem exhibited by Unix
systems that still have ridiculously small argument list limits because
core memory was expensive back in the 1840's or whenever. Especially
Linux, which in this regard still thinks it runs on Linus's first Amgia
or whatever. Most Unices support 64-bit file offsets and 32-bit inode
numbers, some even 32-bit user ids, but several still argue against more
than 128K of argument list space, which makes many otherwise natural
shell wild-card expansions impossible, makes it impossible to use the
output of commands impossible to use as argument lists, etc. I patch
every Linux kernel I install anywhere to increase that limit to 4M, but
it is such a braindamaged thing to make so small.
Common Lisp argument lists are different from shell argument lists in one
crucial respect: You can pass a list as one argument. This obviates the
need for most of the operations that take a huge argument list. Indeed,
it is good coding practice to accept arbitrary-sized lists as lists, not
as &rest arguments, since they would have to be spread and collected, and
really bad coding practice to take some user input and give it to an
internal function that does not do the user-interface error checking that
a consumer of user input should do, but given all this, the value should
at least be so large that a programmer can feel safe when constructing
argument lists in programs.
The standard requires that call-arguments-limit be no smaller than 50.
I would argue that an implementation of Common Lisp that does not allow
at least 500 arguments is useless, so this is a quality-of-implementation
issue, but it is not just call-arguments-limit, lambda-parameters-limit
and multiple-values-limit are also way too small (50 and 20) as specified.
| If you do use APPLY for something like this, it certainly behooves you do
| document the possible limitation so as not to give future porters
| unnecessary headaches. And that, to me, sounds like more of a pain in
| the butt than just using REDUCE.
I think it would be a good idea for an application to document its
requirements on the Common Lisp implementation as far as these limits go,
since they are only _required_ to be really small.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
The purpose of computing is insight, not numbers. -- Richard Hamming
Kent M Pitman
> Common Lisp argument lists are different from shell argument lists in one
> crucial respect: You can pass a list as one argument. This obviates the
> need for most of the operations that take a huge argument list. Indeed,
> it is good coding practice to accept arbitrary-sized lists as lists, not
> as &rest arguments, since they would have to be spread and collected, and
> really bad coding practice to take some user input and give it to an
> internal function that does not do the user-interface error checking that
> a consumer of user input should do, but given all this, the value should
> at least be so large that a programmer can feel safe when constructing
> argument lists in programs.
Actually, for a function that takes an &REST argument, ESPECIALLY one that
takes a SINGLE &REST argument, it seems to me that APPLY should have been
defined to exceed CALL-ARGUMENTS-LIMIT since the list should just be directly
bindable to the rest variable. I don't see spreading it onto the stack and
then re-composing it to a list. It's probably worth testing it for dottedness
and circularity, but that can be done faster than consing.
Erik Naggum
| Actually, for a function that takes an &REST argument, ESPECIALLY one that
| takes a SINGLE &REST argument, it seems to me that APPLY should have been
| defined to exceed CALL-ARGUMENTS-LIMIT since the list should just be directly
| bindable to the rest variable. I don't see spreading it onto the stack and
| then re-composing it to a list.
This is only possible in a context where the compiler knows enough about
the called function when it prepares the call to utilize this information.
To make this generally available functionality would mean that apply
would have to ask (the system about) the function whether it would like
the arguments spread or not, but the function must also be prepared to
accept individual arguments since that would be what a normal function
call would have to provide, unless it went through a more expensive
function call trampoline or something.