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 LISP function, takes a simple list of numbers as a single parameter, and returns the maximum value in the list.
In article <26176b48.0110221114.7c6ba...@posting.google.com>, Tortolo 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 > LISP function, takes a simple list of numbers as a single parameter, > and returns the maximum value in the list.
> Thanks,
> Tortolo
is this your home work? it realy looks like home work.
In article <26176b48.0110221114.7c6ba...@posting.google.com>,
Tortolo <jcard...@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.
> 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 > LISP function, takes a simple list of numbers as a single parameter, > and returns the maximum value in the list.
jcard...@ecopetrol.com.co (Tortolo) writes: > 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 > LISP function, takes a simple list of numbers as a single parameter, > and returns the maximum value in the list.
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.
> > 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 > > LISP function, takes a simple list of numbers as a single parameter, > > and returns the maximum value in the list.
> 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.
jcard...@ecopetrol.com.co (Tortolo) writes: > j...@itasoftware.com wrote in message <news:g08bzd25.fsf@itasoftware.com>... > > jcard...@ecopetrol.com.co (Tortolo) writes:
> > > 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 > > > LISP function, takes a simple list of numbers as a single parameter, > > > and returns the maximum value in the list.
> > 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.
> My Function is:
> (define maxlist (list) > (apply #'max list))
> (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!)
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
> 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).
Tortolo> I nee a LISP function, which takes two parameters and returns T if 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.
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.
Jeff Mincy <j...@delphioutpost.com> writes: > 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.
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
* Thomas F. Burdick | 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
Erik Naggum <e...@naggum.net> writes: > 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.
* Kent M Pitman <pit...@world.std.com> | 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.
/// -- 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
