How to use grid:slice in LISP? - common-lisp

When I do :
(grid:subgrid #( 1 2 3 4) '(1) '(2))
, i get 3. But when I do:
(grid:subgrid #( 1 2 3 4) '(1) '(* 2 1))
,i get the following error:
#<TYPE-ERROR expected-type: LIST datum: 2>.
Does anyone have a hint?

Apologies; not sure exactly where you're headed, and I don't know what the "grid" package is, so I couldn't test very much.
It looks like you're trying to determine grid coordinates on the fly with '(* 2 1) but it's not working. If that's what you are doing, you could maybe use a backquote comma construct...
(grid:subgrid #(1 2 3 4) '(1) `(,(* 2 1)))
subgrid seems to want args 2 and 3 (rest?) as lists with numbers for elements, and as originally provided, you were sending it the * symbol, which may explain why you were getting a type error.

If this is grid grid from Antik then subgrid parameters for the dimensions are lists
This is the manual. If you use slime just do M-. to look at the function.
Hope that helps

Related

Equality of vectors in clojure

I was trying to solve this problem
https://www.4clojure.com/problem/32
and I realized that this statement gave output as false.
(= (#(into [] (distinct %)) [1 2 3])
'(1 1 2 2 3 3))
It is supposed to be true as the function is also returning the same vector.
Can someone please explain to me why this is false?
The question you ask is irrelevant to the problem you refer to, which your own answer solves. Looking at the question alone ...
As rascio comments, you are applying distinct to the wrong
sequence.
Furthermore, you can apply = to any two sequences. You don't have
to convert the lazy sequence that distinct produces to a vector.
Thus the following suffices ...
(= [1 2 3] (distinct '(1 1 2 2 3 3)))
=> true
From the comments, I found out that I was using the distinct method incorrectly and hence decided to use the repeat method to get the answer which was:
mapcat #(repeat 2 %)

Maximum sum of a tree in Scheme

I am having troubles with an exercise I am trying to do because I'm new to this language and to think in a recursive way is kind of hard to me. I have a tree (not neccesary binary) and I need to find the path that gives the maximum sum. For example I have the tree: ’(1 ((0) (2 ((3) (2))) (5))) given in the image
Example tree
1
0 2 5
3 2
So I have to do a function: (function ’(1 ((0) (2 ((3) (2))) (5)))) and it should return 6 (in this case). There are 2 paths that give the answer: 1 + 2 + 3 = 6 and 1 + 5 = 6. I tried to "translate" a code in python found here, but I have no idea how to do it recursively in Scheme.
The recursion is pretty simple, you just need to check 3 cases:
NUMBER?
NULL?
PAIR?
So in scheme you would structure it like this:
(define (tree-sum t)
(cond ((number? t)
...)
((null? t)
...)
((pair? t)
...)))
The pair? one is the recursive case in which you add up the sums of car and cdr. Hope that helps!

Evaluate the expression CLISP

(+ '(1 2 3 4 5) '(3 4 5 6 7))
Evaluate this expression. I don't know much about CLISP.
It returns an error when I runs it on CLISP.
Explain the reason for error ??
Thanks in advance
It's possible you were expecting this to concatenate
(+ '(1 2 3 4 5) '(3 4 5 6 7)) ==> '(1 2 3 4 5 3 4 5 6 7)
Common Lisp doesn't do this because it wouldn't make sense. In some languages like Python, there are a limited number of infix operators, so overloading + makes a certain amount of sense. However, in Common Lisp, there are infinitely many function names and + is but one of them, so we have different functions, such as append to do this.
It's also possible you were expecting this to add pointwise.
(+ '(1 2 3 4 5) '(3 4 5 6 7)) ==> '(4 6 8 10 12)
It doesn't do this as it's also against Lisp's philosophy. Adding elements pointwise like this is a feature of tacit languages such as APL or J. These languages go to a lot of trouble to get features like this to work in the most general possible cases. As such, they tend not to focus so much on certain other features, such as the object system or metaprogramming.
This is where Lisp shines: Lisp is a metaprogramming language, so rather than spend all their time developing corner cases for mathematical functions, they made a simple function that simply adds numbers together and does nothing more, and then spent the bulk of their development time making a good macro system. Common Lisp in particular adds to this by having one of the best object systems (with fully generic dispatch) that I've seen. Languages aren't good at everything, so the best languages have to define a philosophy and stick to it. Accepting all kinds of input simply isn't Lisp's philosophy; metaprogramming is.
CLISP itself will give you part of the answer:
[1]> (+ '(1 2 3 4 5) '(3 4 5 6 7))
*** - +: (1 2 3 4 5) is not a number
+ is a function that is only defined on numbers, so when the interpreter sees that a list of numbers has been offered as an argument to +, it can't go any further.
The interpreter sees (1 2 3 4 5) as the first argument to + after evaluating '(1 2 3 4 5), i.e. (quote (1 2 3 4 5)), which returns (1 2 3 4 5).
You may be thinking that + is more flexible, sort of like the way that it works in Javascript. No: It's just the math plus function.
(Why doesn't the interpreter complain about (3 4 5 6 7)? Because it stopped when it saw (1 2 3 4 5), and went to the debugger prompt.)
By the way, that error message is CLISP-specific, but any Common Lisp will give you an error on that input.
EDIT: Per #RainerJoswig's comment, it may be that the correct way to describe this is not that interpreter code responds to (1 2 3 4 5) being paired with +, but the + function code that does so, and doesn't bother with the second argument, etc. What I wrote was my best guess about the right way to describe the situation, and partially addresses OP's question, but I am not a Lisp internals expert.

Displaced multidimensional arrays in common lisp

So I have some code that needs a subset of a multidimensional array in such a way that it works a bit more like taking a subsection of a matrix, ideally it would work like a displaced array.
So let's say I have something that looks like this
(defvar *a* (make-array '(3 3) :initial-contents
'((1 2 3) (2 3 1) (3 1 2))
And I want it to be accessible with an array *b*
(defvar *b* (make-array '(2 2) :displaced-to *a* :displaced-index-offset
(array-major-row-index *a* '(1 1)))
Such that *b* will point to
#2a((3 1) (1 2))
instead of
#2a((3 1) (3 1))
I've already written myself a multidimensional slice function that copies the parts of the array I want, but it would be ideal to not need to copy back and forth manually, is there any solution that works like this in vanilla common lisp?
I understand that the way that displaced multidimensional arrays work in a way that coheres directly with (array-major-row-index) (namely that #2a((1 2 3) (2 3 4)) has row indices (0 1 2 3 4 5) and therefore the displaced array at '(1 0) of dimensions '(2 2) will point to #2a((2 3) (2 3)), so I need to wrap the new array such that it refers to specific places in the old one, but so far I don't know how to capture such a reference.
I'm not entirely sure that it is possible to get pointers to places in the array, so I would appreciate if that could be cleared up.
You can't directly do it, but FYI there used to be support for this in Symbolics Lisp Machines.
From Kent Pitman:
What was new with the LispM, and which did not carry into CL (perhaps
because of the lack of microcode assist for speed) was conformally
displaced arrays (I think you said :displaced-conformally t, or some
such) in which case you got a displaced region of the original square
(cube, etc) rather than a region of the linearized storage. This was
useful for displacing to screen memory, especially since the LispM
used DMA (direct memory access) display from a raster array that was,
I think, specially known by the screen to mean "this array's memor IS
the screen" and doing a SETF of AREF into that special array made
something appear on the screen. All windows had conformally displaced
indirect arrays that represented their part of the screen.
As pointed out by Rainer Joswig, there is a video on Youtube, from Kalman Reti, demonstrating conformally displaced arrays. It might be possible for implementations to provide support for this, but I don't know if any current one provides such displaced arrays. But other answers are fine suggesting alternatives.
Multidimensional arrays are stored in memory as a one-dimensional array in row-major order. That is, #2a((1 2 3) (2 3 1) (3 1 2)) is actually the same as #(1 2 3 2 3 1 3 1 2).
CL-USER> (let ((a (make-array '(3 3) :initial-contents
'((1 2 3) (2 3 1) (3 1 2)))))
(make-array 9 :displaced-to a))
#(1 2 3 2 3 1 3 1 2)
A displaced array is a contiguous subset of the actual array (sharing memory with it). Your desired *B* would not be contiguous, since it would have to arbitrarily jump over the last 3 in the array.
*B*
/ \
--- ---
1 2 3 2 3 1 3 1 2
You would have to either include the skipped over 3 in the displaced array, or use two separate displaced arrays.
As explained in the answer of jkiiski you cannot obtain directly what you want, but you could “approximate” such result by using array of arrays, instead of multi-dimensional arrays.
For instance:
(defvar *a* (make-array 3 :initial-contents '(#(1 2 3) #(2 3 1) #(3 1 2))))
and then *b* could be defined as an array whose elements are arrays displaced on the appropriate arrays of *a*:
(defvar *b*
(make-array 2 :initial-contents
(loop for row from 1 to 2
collect (make-array 2 :displaced-to (aref *a1* row) :displaced-index-offset 1))))
The main difference with respect to the multi-dimensional arrays is that instead of using:
(aref *b* 1 1)
you should use:
(aref (aref *b* 1) 1) ; => produces 2 for the example above
And of course you could define macros or reader macros to simplify this notation.

Destructive sorting in lisp

I'm reading Practical Common Lisp. In chapter 11, it says this about sorting:
Typically you won't care about the unsorted version of a sequence after you've sorted it, so it makes sense to allow SORT and STABLE-SORT to destroy the sequence in the course of sorting it. But it does mean you need to remember to write the following:
(setf my-sequence (sort my-sequence #'string<))
I tried the following code:
CL-USER> (defparameter *a* #( 8 4 3 9 5 9 2 3 9 2 9 4 3))
*A*
CL-USER> *a*
#(8 4 3 9 5 9 2 3 9 2 9 4 3)
CL-USER> (sort *a* #'<)
#(2 2 3 3 3 4 4 5 8 9 9 9 9)
CL-USER> *a*
#(2 2 3 3 3 4 4 5 8 9 9 9 9)
In this code we can see that the variable *a* has been changed by the sort function.
Then why do the book say that is necessary to do an assignment?
I'm using SBCL + Ubuntu 14.04 + Emacs + Slime
EDIT:
Following the comment of #Sylwester I add the evaluation of *a* so it's clear that the value has been changed.
It's necessary to do the assignment if you want your variable to contain the proper value of the sorted sequence afterwards. If you don't care about that and only want the return value of sort, you don't need an assignment.
There are two reasons for this. First, an implementation is allowed to use non-destructive copying to implement destructive operations. Secondly, destructive operations on lists can permute the conses such that the value passed into the operation no longer points to the first cons of the sequence.
Here's an example of the second problem (run under SBCL):
(let ((xs (list 4 3 2 1)))
(sort xs '<)
xs)
=> (4)
If we add the assignment:
(let ((xs (list 4 3 2 1)))
(setf xs (sort xs '<))
xs)
=> (1 2 3 4)
The variable can't be changed by the sort function, since the sort function does not know about the variable at all.
All the sort function gets is a vector or a list, but not variables.
In Common Lisp the sort function can be destructive. When it gets a vector for sorting, it can return the same vector or a new one. This is up to the implementation. In one implementation it might return the same vector and in another one it may return a new one. But in any case they will be sorted.
If there is a variable, which points to a sequence and for which the author expects that it will after sorting point to a sorted sequence: set the variable to the result of the sort operation. Otherwise there might be cases, where after potentially destructive sorting, the variable won't point to the SORT result, but still to an unsorted, or otherwise changed, sequence. In case of the vector this CAN be the old and unsorted vector.
REMEMBER
The only thing you can be sure: the SORT function returns a sorted sequence as its value.

Resources