May I know is there a way to dequeue an item from a certain index in a circular array?
Example
Imagine this is a circular array...
1---2--3---4-5---6--7-8
|11|76|45|32|32|16|21|8|
dequeue index 3
1---2--3---4-5---6--7-8
|11|76|45|32|32|16|21|8|
1---2--3---4-5---6--7-8
|11|76|EM|32|32|16|21|8|
EM stands for empty.
dequeue index 8
1---2--3---4-5---6---7--8
|11|76|EM|32|32|16|21|EM|
Is there a way? Or do I need to shift all of them together then it will work?
Thank you.
In most programming languages, when you'd like to remove an element, you have to shift all the subsequent elements. However, most programming languages don't provide a concept like "circular arrays".
If instead of arrays, a linked list is being used, then the link in the element prior to the one being dequeued can be changed to point to the subsequent element (after the one being dequeued). This will work both for a linear linked list and a circular linked list.
Related
By function-call/procedure-call pairs, I mean pairs of functions that do the same thing, except one returns it's result whereas the other alters it's argument(s) to be the result. For example the pair List/Apply.
List(list, func) Returns the list resulting from applying the function func to every value of list.
Apply(list, func) Applies the function func to every value of a mutable list list, changing list.
I've become annoyed of writing my own functions to find that GAP already had a built in version I should be using, so it'd help to know these pairs. Like, does Filtered have a procedural counterpart I don't know about? Or do I need to write my own? If a function does have a counterpart will it necessarily be listed in the documentation for that function? The only other such pair that I can think of right now is Concatenation/Append. What are other such pairs of functions/procedures in GAP?
Although this may be of little help, as Alexander Hulpke explained in https://math.stackexchange.com/questions/3704518, "The general language convention is that verbs do something to an object, while nouns create a new object with the desired characteristics." GAP naming conventions are described in the GAP Reference Manual here.
So, a counterpart to Filtered would likely be called Filter - but there is no such function (and Filter has another meaning in GAP). We do try to mention counterparts in corresponding manual sections - if you find them missing, then please suggest improvements to the GAP documentation, preferably at the GAP repository on GitHub.
In the TypoScript Reference, the data type for some properties is defined as "array" or "array of ... with stdWrap" or something similar.
In the list of data types in the TSRef however, "array" is nowhere to be found.
I know, essentially it really is an array when converted to PHP, but what does data type array mean exactly in this context?
There are further arrays (like array of cObjects for subparts and marks in templates)
They all define another level of elements in your typoscript. The kind of array may give you a hint what index and what kind of values are expected.
Sometimes the index is ordered for evaluation (e.g. COA, layoutRootPaths), sometimes it does not matter (e.g. marks, subparts) or are evaluated in the order of the typoscript (e.g. includeJS). As you could have multiple kinds of array in PHP each can be evaluated in multiple ways.
The kind of values (in the documentation) depend on the further evaluation. Simple integer, strings, cObjects, ...
Not everywhere you are able to add stdWrap functions (so values evaluated in the core should have it).
As you already mentioned: typoscript is scanned and stored as multidimensional array.
Each part of (core-)code evaluates this array with an individual logic. So the interpretation of an array is done individually.
And until now there is no full consens about which kind of arrays are representative or typical to be an own type. An unification would probably need code changes, in core and in multiple extensions.
For optimization of the manuals you should open a forge ticket requesting an explanation in the manuals with the kind of arrays you found.
The docs are kind of confusing in that regard, because there are no "arrays" in TypoScript at all, because TypoScript isn't even a programming language.
TypoScript is just a configuration, like YAML or JSON and will be converted into an array itself by PHP. I think it should rather be called "a list of things" instead of "an array of things", but since arrays are kinda lists themselfes and developers, who are the main audience of the docs, should know what the docs are talking about when talking about "an array of things", it is kinda valid to leave it as is.
For the sake of argument can we say that when we create lists in Lisp, it is a change of state? Now that can be using cons, list or any other list creation functions.
Consider a filter function which filters odd number from list and keeps only even numbers. Now it does that by creating new lists and using recursion. Can we say there is change of state in the program? Assuming we already know interpreter's perspective.
Considering lists are objects and and when old objects are dropped in favour of new objects then it is change of state right?
Also how valid would it be to say that from technical point of view. I mean from Lisp interpreter perspective.
It all comes down to how you define "change of state", or better yet, the thing whose state we are talking about. States are properties of things, so to answer your question, we have to ask "the state of what exactly?"
Let's look at a couple of possible candidates:
In your filtering example, we have a list A. Filter constructs a new list B with only the even numbers.
The state of A is definitely not changed. That's the point of constructing a new list.
The state of B is definitely changed. Prior to the run of filter, it did not exist, now it does.
The state of the runtime environment also contains all the variables and as we added a new symbol with the filtered list, its state has certainly changed.
So, to answer your question: Yes. But keep in mind that state is a property of something and to really answer it correctly, you have to tell us whose state you are interested in.
I've been using Coffeescript all day every day for three months.
I love it. There are a few little learning niggles with how it translates to JS, but I've gotten over all of them except one:
How do I remember whether to use in or of when iterating over loops and arrays?
http://coffeescript.org/#loops
Sometimes I need the key and value, sometimes I only need the value. Both of and in work on both arrays and objects to iterate.
Can someone recommend a mnemonic for remembering which one is which?
This would be very valuable to me. I'm tired of going to the doc site for this same thing over and over again :)
Example from a different domain:
I always remember that west is on the left and east is on the right of a compass because it spells "we".
This sentence of the linked documentation seems particularly apt:
Comprehensions can also be used to iterate over the keys and values in an object. Use of to signal comprehension over the properties of an object instead of the values in an array.
Basically, think "items in an array", "properties of an object".
How mouch Scala standard library can be reused to create variant of HashMap that does not handle collisions at all?
In HashMap implementation in Scala I can see that traits HashEntry, DefaultEntry and LinkedEntry are related, but I'm not sure whether I have any control over them.
You could do this by extending HashMap (read the source code of HashMap to see what needs to be modified); basically you'd override put and += to not call findEntry, and you'd override addEntry (from HashTable) to simply compute the hash code and drop the entry in place. Then it wouldn't handle collsions at all.
But this isn't a wise thing to do since the HashEntry structure is specifically designed to handle collisions--the next pointer becomes entirely superfluous at that point. So if you are doing this for performance reasons, it's a bad choice; you have overhead because you wrap everything in an Entry. If you want no collision checking, you're better off just storing the (key,value) tuples in a flat array, or using separate key and value arrays.
Keep in mind that you will now suffer from collisions in hash value, not just in key. And, normally, HashMap starts small and then expands, so you will initially destructively collide things which would have survived had it not started small. You could override initialSize also if you knew how much you would add so that you'd never need to resize.
But, basically, if you want to write a special-purpose high-speed unsafe hash map, you're better off writing it from scratch or using some other library. If you modify the generic library version, you'll get all the unsafety without all of the speed. If it's worth fiddling with, it's worth redoing entirely. (For example, you should implement filters and such that map f: (Key,Value) => Boolean instead of mapping the (K,V) tuple--that way you don't have to wrap and unwrap tuples.)
I guess it depends what you mean by "does not handle collisions at all". Would a thin layer over a MultiMap be sufficient for your needs?