How to write this java code in clojure (tips) - clojure

The question
I'm learning clojure and I love learning languages by example. But I do not like it just get a complete answer without me having to think about it.
So what I want is just some tips on what functions I might need and maybe some other clues.
The answer that I will accept is the one that gave me the necessary building blocks to create this.
public class IntervalMap<K extends Comparable<K>, V> extends
TreeMap<K, V> {
V defaultValue = null;
public IntervalMap(V defaultValue) {
super();
this.defaultValue = defaultValue;
}
/**
*
* Get the value corresponding to the given key
*
* #param key
* #return The value corresponding to the largest key 'k' so that
* " k is the largest value while being smaller than 'key' "
*/
public V getValue(K key) {
// if it is equal to a key in the map, we can already return the
// result
if (containsKey(key))
return super.get(key);
// Find largest key 'k' so that
// " k is the largest value while being smaller than 'key' "
// highest key
K k = lastKey();
while (k.compareTo(key) != -1) {
k = lowerKey(k);
if (k == null)
return defaultValue;
}
return super.get(k);
}
#Override
public V get(Object key) {
return getValue((K) key);
}
}
Update
I want to recreate the functionality of this class
For examples you can go here: Java Code Snippet: IntervalMap

I'd be looking at some combination of:
(sorted-map & key-vals) - will allow you to create a map ordered by keys. you can supply your own comparator to define the order.
(contains? coll key) - tests whether a collection holds an item identified by the argument (this is a common source of confusion when applied to vector, where contains? returns true if there is an element at the given index rather than the given value)
(drop-while pred coll) lets you skip items in a collection while a predicate is true

I would just use a map combined with a function to retrieve the closest value given a certain key. Read about maps and functions if you want to know more.
If you want to be able to mutate the data in the map, store the map in one of clojure's mutable storage facilities, for example an atom or ref. Read about mutable data if you want to know more.
You could use a function that has closed over the default value and/or the map or atom referring to a map. Read about closures if you want to know more.
The use of Protocols might come in handy here too. So, read about that too. Enough to get you going? ;-)

A few things that I used in my implementation of an interval-get function:
contains?, like #sw1nn suggested, is perfect for checking whether a map contains a particular key.
keys can be used to get all of the keys in a map.
filter keeps all of the elements in a sequence meeting some predicate.
sort, as you have have guessed, sorts a sequence.
last returns the last element in a sequence or nil if the sequence is empty.
if-let can be used to bind and act on a value if it is not falsey.
The usage of the resulting function was as follows:
(def m {0 "interval 1", 5 "interval 2"})
(interval-get m 3) ; "interval 1"
(interval-get m 5) ; "interval 2"
(interval-get m -1) ; nil

If you want to implement the code block "conceptually" in clojure then the existing answers already answer your question, but in case you want the code block to be "structurally" same in clojure (i.e the subclassing etc) then have a look at gen-class and proxy in clojure documentation.

Related

Creating a List Specification in Alloy Language

I'm working on defining a List in Alloy but I'm stuck.
This is what I have so far (it acts like a LinkedList):
module List
// The List signature
lone sig List { rootElement: lone Element }
// A list element signature
sig Element { nextElement: lone Element }
// Prevents an Element from referencing itself
fact preventElementLooping {
no ele: Element | ele = ele.nextElement
}
// Zero Element outliers
fact allElementsBelongToOneList {
all ele: Element | one list: List | ele in list.rootElement.*nextElement
}
// Prevents Elements from referencing a Element before it in the List
fact preventCycle {
no ele: Element | ele in ele.^nextElement
}
This all looks good to me and I feel like this is correct.
I'm trying to define 3 predicates for this list definition:
Create: Should create an empty list
Put: Should add an item to the end of the list
Find: Should return all indices in the list that match a given element
pred create(list, list":List) {
list".rootElement = none
}
pred put(list, list":List, ele: Element) {
list".rootElement = ele
}
pred find [list:List, ele: Element] {
ele = list.rootElement or ele in list.rootElement.^nextElement
}
This is what I need help with I feel like I'm missing something in those 3 preds.
My questions:
Am I over complicating things by trying to use a linked list? How would you just do a normal list?
Put is correct for the first put but fails when you need to put again as it just replaces the root element
Find is the big struggle. I need to store the indices somewhere to return them right? Also I thought alloy only had bare bones understanding of Numbers for indexes (I believe only allowing -7 to 8). Should index be its own signature?
Thanks in advance
There are several ways to define a notion of list in Alloy, yours is a possibility, depending no what you expect to do then.
I don't see why you want to make List a lone sig?
Another remark is that your list doesn't contain any data, only "elements" (I would call them cells), perhaps because it's of no use in your spec? Anyhow, you could make your module generic and store data in cells, e.g.:
module List[Data]
sig List { rootElement: lone Element }
sig Element { data: one Data, nextElement: lone Element }
Your facts can also be improved:
By having only one fact rejecting all forms of cycles.
By only asking for elements to belong to some list rather than exactly one.
Finally, regarding operations, I suggest you take a look at how the standard library models lists and operations:
util/seqrel specifies lists as relations
util/sequence specifies lists as signatures holding elements
util/sequniv is like util/seqrel but relies on builtin integer indices and is implemented in an ad hoc concrete syntax based on the seq keyword.

seq function caveats in clojure

In the docstring of clojure's seq function, it mentions:
Note that seqs cache values, thus seq
should not be used on any Iterable whose iterator repeatedly
returns the same mutable object.
What does this sentence mean? Why emphasize the same mutable object?
The comment was added later and mentions this ticket:
Some Java libraries return iterators that return the same mutable object on every call:
Hadoop ReduceContextImpl$ValueIterator
Mahout DenseVector$AllIterator/NonDefaultIterator
LensKit FastIterators
While careful usage of seq or iterator-seq over these iterators worked in the past, that is no longer true as of the changes in CLJ-1669 - iterator-seq now produces a chunked sequence. Because next() is called 32 times on the iterator before the first value can be retrieved from the seq, and the same mutable object is returned every time, code on iterators like this now receives different (incorrect) results.
Approach: Sequences cache values and are thus incompatible with holding mutable and mutating Java objects. We will add some clarification about this to seq and iterator-seq docstrings. For those iterators above, it is recommended to either process those iterators in a loop/recur or to wrap them in a lazy-seq that transforms each re-returned mutable object into a proper value prior to caching.
The Clojure's seq function can create sequences from many types of objects like collections and arrays. seq also works on any object that implements the java.util.Iterable interface from the Java Collections framework. Unfortunately, the semantics of Clojure sequences and java.util.Iterator (which is used with the Iterable) are not 100% compatible as pointed out in the answer from #cfrick.
It is, or at some point was, considered ok for each invocation of the next method of the Iterator to return the same (mutable) object. This works only as long as the return value of next is used and discarded prior to the subsequent call to next. However, if return values of next are retained and used later, undefined behavior can result. This is exactly what happens in some implementations of Clojure sequences.
Let me illustrate. The following is a toy implementation of a range of integers in Java. Notice how the implementation of the method next always returns the same object.
package foo.bar;
import java.util.*;
public class MyRange implements Iterable<MyRange.Num> {
public static class Num {
private int n;
public int get() { return n; }
public String toString() { return String.valueOf(n); }
}
private int max;
public MyRange(int max) { this.max = max; }
// Implementation of Iterable
public Iterator<Num> iterator() {
return new Iterator<Num> () {
private int at = 0;
private Num num = new Num();
public boolean hasNext() {
return at < max;
}
public Num next() {
num.n = at++;
return num;
}
};
}
}
This code works fine when consumed in a way intended by the designers of the Java Collections framework. For example:
(loop [i (.iterator (MyRange. 3))]
(when (.hasNext i)
(print (str (.next i) " "))
(recur i)))
;;=> 0 1 2
But once we bring Clojure sequence into the mix, things go wrong:
(map #(.get %) (MyRange. 3))
;;=> (2 2 2)
We got (2 2 2) instead of (0 1 2). This is exactly the type of an issue that the warning in seq is concerned about.
If memory serves, the implementation of the Iterator for EnumhMap in Java 6 used the mutable object implementation in the name of efficiency. Such implementation does not allocate memory on every iteration, so it is faster and does not create garbage. But this "technique" was problematic not only for Clojure but for some Java users as well. So the behavior was changed in Java 7.

3D Hash with no collisions on close values

I need a hash function for 3D vectors with no collisions between close key values.
The key is a 3d vector of integers. I want no collisions within roughly a 64 * 64 * 64 "area" or larger.
Does anyone know of any hashing functions suited for this purpose, or even better, how would you go about designing a hash for this?
If it's necessary to know, I will be implementing it in C++.
Why not create a Map<int,Map<int,Map<int,Object>>> for your objects? Where each int is x,y,z or whatever you're labeling your axis.
Here's an example of how you could use it.
int x,y,z;
map<int,map<int,map<int,string>>> Vectors = map<int,map<int,map<int,string>>>();
/*give x, y and z a real value*/
Vectors[x][y][z] = "value";
/*more code*/
string ValueAtXYZ = Vectors[x][y][z];
Just to explain because its not super obvious.
The Vectors[x] returns a map<int,map<int,string>>.
I then immediately use that maps [] operator with [y].
That then returns (you guessed it) a map<int,string>.
I immediately use that maps [] operator with [z] and can now set the string.
Note: Just be sure to loop through it using iterates and not a for(int x = 0; /*bad code*/;x++) loop because [] adds an element at every location it's used to look up. Here's an example of a loop and Here's and example of an unexpected add.
Edit:
If you want to make sure that you're not overriding an existing value you could do this.
string saveOldValue;
if(Vectors[x][y][z] != ""/*this is the default value of a string*/)
{
/*There was a string in that vector so store the old Value*/
saveOldValue = Vectors[x][y][z];
}
Vectors[x][y][z] = "Value";
If you use [] on a key that isn't in the map the map creates a default object there. For strings this would be the empty string "".
Or
if( Vectors.find(x)!=Vectors.end()
&& Vectors[x].find(y)!=Vectors[x].end()
&& Vectors[x][y].find(z)!=Vectors[x][y].end())
{
/* Vectors[x][y][z] has something in it*/
}else
{
/*Theres nothing at Vectors[x][y][z] so go for it*/
Vectors[x][y][z] ="value";
}
This uses the find(value) function which returns an iterator to the location of the key "value" OR and iterator that points to map::end() if that key is not int the current map.
If you don't have a default value for your thing being stored then use the second check to do your inserts. This greatly increases the useability of this answer and unclutters your code.
The insert function has it's place but in this example it would be very hard to use.

Returning elements of a row in a list using Scala

I need to write a method that will return the contents of a particular row (index of it is inputted as method parameter). I have to use recursion and no loops.
So far I have attempted this uncompleted code (and I have no idea how to continue it):
class Sudoku(val grid: List[List[Int]]) {
def r(r: Int): Set[Int] = {
if (grid.isEmpty) Set()
else
}
}
I also do not know how Set works. Any help would be really appreciated. PS: I am not asking for complete code, an algorithm explanation would be more than enough!
This is the answer to the literal interpretation of the question:
class Sudoku(val grid: List[List[Int]]) {
def row(n: Int): List[Int] =
if (grid.size > n) grid(n) else Nil
}
The apply method on List, here applied on the value grid, which can be written either grid apply n, or simply grid(n) returns the n'th element of the list. If that element does not exist (e.g. grid(1000000)), it throws an exception, therefore we check the size of the list first.
I have no idea why you should return a Set, but you could simple call .toSet on the result. A Set is a collection with distinct elements (each element only occurs once) with no guarantee of ordering.
I also don't know why you would need recursion for this, so I reckon the question is part of a larger problem.

How is the C++ multimap container implemented?

For example a C++ vector is implemented using a dynamic array where each element uses consecutive memory spaces.
I know that a C++ multimap is a one to many relationship but what is the internal structure?
The C++ standard does not define how the standard containers should be implemented, it only gives certain constraints like the one you say for vectors.
multimaps have certain runtime complexity (O(lg n) for the interesting operations) and other guarantees, and can be implemented as red-black trees. This is how they are implemented in the GNU standard C++ library.
Very often, a red-black tree. See e.g. STL's Red-Black Trees from Dr. Dobb's.
Addition to the "preferred" answer, because SO won't let me comment:
Given a key with values B, C, D, the behavior of iterators is a lot easier to implement if each element has it's own node. Find() is defined to return the first result in the series, and subsequent iteration takes you across the remaining elements. The de facto difference between a map and a multimap is that multimap is sorted using < over the entire value_type, where the map use < over only the key_type
Correction: the C++11 standard is explicit that new (key, mapping) pairs are inserted at the end of any existing values having the same key. This raises a question I hadn't considered: can a multimap contain two nodes in which both the key and the mapped target are the same. The standard doesn't seem to take a clear position on this, but it's noteworthy that no comparison operator is required on the mapped type. If you write a test program, you will find that a multimap can map X to 1, 2, 1. That is: "1" can appear multiple times as a target and the two instances will not be merged. For some algorithms that's a deficiency.
This article from Dr. Dobbs talks about the underlying rb-tree implementation that is commonly used. The main point to note is that the re-balance operation actually doesn't care about the keys at all, which is why you can build an rb-tree that admits duplicated keys.
The multimap just like it's simpler version i.e the std::map, is mostly built using red black trees. C++ standard itself does not specify the implementation. But in most of the cases ( I personally checked SGI STL) red black trees are used. Red Black trees are height balanced trees and hence fetch / read operation on them is always guaranteed to be O(log(n)) time. But if you are wondering on how values of the key are stored. each key->pair is saved as a separate node in the red black tree ( Even though the same key might appear multiple times just like in the case of key 'b' below). Key is used to lookup/ search the rb-tree. Once the key is found, it's value stored in the node is returned.
std::multimap<char,int> mmp;
mmp.insert(std::pair<char,int>('a',10));
mmp.insert(std::pair<char,int>('b',20));
mmp.insert(std::pair<char,int>('b',10));
mmp.insert(std::pair<char,int>('b',15));
mmp.insert(std::pair<char,int>('b',20));
mmp.insert(std::pair<char,int>('c',25));
mmp.insert(std::pair<char,int>('a',15));
mmp.insert(std::pair<char,int>('a',7));
for (std::multimap<char,int>::iterator it=mmp.begin(); it!=mmp.end(); ++it){
std::cout << (*it).first << " => " << (*it).second << " . Address of (*it).second = " << &((*it).second) << '\n';
}
Output :
a => 10 . Address of (*it).second = 0x96cca24
a => 15 . Address of (*it).second = 0x96ccae4
a => 7 . Address of (*it).second = 0x96ccb04
b => 20 . Address of (*it).second = 0x96cca44
b => 10 . Address of (*it).second = 0x96cca64
b => 15 . Address of (*it).second = 0x96cca84
b => 20 . Address of (*it).second = 0x96ccaa4
c => 25 . Address of (*it).second = 0x96ccac4
Initially I thought the values of a single key like 'b' might be stored in a std::vector .
template <class K, class V>
struct Node {
K key;
std::vector<V> values;
struct Node* left;
struct Node* right;
}
But later I realized that would violate the guaranteed fetch time of O(log(n)). Moreover, printing out the addresses of the values confirms that values with a common key are not contiguous.
They keys are inserted using operator<, so values with the same keys are stored in the order in which they are inserted.
So if we insert first
(key = 'b', value = 20)
and then
(key = 'b', value = 10)
The insertion is done using operator< , since the second 'b' is NOT lesser than the first inserted 'b', it is inserted in the 'right branch of a binary tree'.
The compiler I have used is gcc-5.1 ( C++14).