Re: Unicode function name? ∩
On Wednesday, 7 September 2016 at 07:39:53 UTC, Jesper Tholstrup wrote: On Tuesday, 6 September 2016 at 20:26:01 UTC, Illuminati wrote: Ok, continue your game I see you are quite involved with it. For what it's worth I was actually trying to learn something. I apologize if I contributed to sidetracking the discussion. Well, I tried to tell you that you are hung up on the meaning of meaningless things and you said that it was all my personal opinion. Either it is or isn't but simply stating it proves nothing. It's up for you to decide if what I have said is worth pursuing for yourself or not. But surely you would agree that if you believe something has inherent meaning but it actually doesn't that you are creating a whole world of grief for yourself and others? Hence, it is utmost importance to know? All I will say is "Don't confuse the map with the territory". The territory exists without the map, but not vice versa.
Re: Unicode function name? ∩
On Tuesday, 6 September 2016 at 19:58:11 UTC, Jesper Tholstrup wrote: On Tuesday, 6 September 2016 at 18:46:52 UTC, Illuminati wrote: [...] You are somewhat of topic here. [...] A lot of code is written by non-mathematicians and has to be maintained by non-mathematicians. Mathematicians will be confused when people start using the symbols incorrectly, simply because they try to be clever. Sure, some developers would probably mix up english words like 'intersect' and 'union', but I think that it is less common. [...] Ok, continue your game I see you are quite involved with it.
Re: Unicode function name? ∩
On Tuesday, 6 September 2016 at 13:41:22 UTC, Jesper Tholstrup wrote: On Tuesday, 6 September 2016 at 02:22:50 UTC, Illuminati wrote: It's concise and has a very specific meaning. Well, only if we can agree on what the symbols mean. I'm not sure that every symbol is concise and specific across the fields of mathematics, statistics, and physics. The worst part, however, is our (humans, that is) intrinsic desire to be "clever". There will be an endless incorrect use of symbols, which will render code very difficult to understand Friday afternoon when things break. Symbols are inherently meaningless so you are not making sense. Clever is what got humans out the jungle, I think it is a good thing. No need to denigrate it when you benefit from people being clever. Of course, you could argue that staying in the jungle would have been the best thing... The whole point of symbols is to simplify, ∩ is more simple than intersect as the first requires 1 symbol and the second requires 8 symbols. I don't buy that argument - fewer symbols is better? If so disagree, its a lot easier to make and a lot harder to catch a ∩ vs ∪ error compared to 'intersect()' vs 'union()' error. How is Unicode normalization handled? It is my impression that certain symbols can be represented in more than one way. I could be wrong... Mathematicians don't seem to get confused by symbols. intersect is a symbol. It is no different than ∩ or any other symbol. It is just chicken scratch. There is no inherent meaning in the wavy lines. If you think there is then you are deluding yourself. You have simply memorized what those groups of symbols mean and you are too lazy to memorize what some other symbol means. Once you realize the game you are playing with yourself then it becomes easier to break the bad habit and not get caught up in the nonsense. The reason why ∩ is better than intersect is because it is quicker to see and analyze(due to its "size"). True, it is more ambiguous, as ambiguity depends on size, but at least in this case it has been well established just as π and 1,2,3..., etc. But if you are so concerned about ambiguity then why not intersectsetofarithmeticintegerswithsetofarithmeticintegers? That is far less ambiguous than intersect. My point is, you are playing games. You might not realize it but that is what is going on. If you want to be truthful, it is better to say "I prefer to use my own personal standardized notation that I have already learned since it takes precious time away from my own life.". When do you this, I cannot argue with you, but then you also have to accept that you cannot argue with me(or anyone else). Because what makes sense or works for you might not work for me or someone else. Your argument is exactly analogous to "I don't speak french! Use English you stupid french speaking person, french is for idiots anyways". The tone is irrelevant, the point is acting like one superficial system is better than some other superficial system simply because of perspective/laziness/arrogance/etc. The only issues are that either you are failing to see the systems as superficial or you are failing to see that your own personal center of the universe is not actually the center of the universe. So just be real. The reason you don't like it is because it confuses you. If it didn't, you wouldn't have a problem with it. If you could speak French and English then you, if you were that hypothetical person, wouldn't care what language was used. All I can say is that everyone is confused until they learn something. But don't confuse your confusion with some innate scale of better/worse, it only leads to more confusion. The solution to all confusion is familiarity. Become familiar with your confusion(e.g., using ∩) and it won't be confusing anymore. The reason the mathematical symbols don't phase me is because I spent years using them. In my mind ∩ = intersection of sets(which I have a non-verbal meaning in my own mind on what that means). I see no difference between ∩ and intersect. Hence I am not confused. If someone comes along and uses ∩ to mean what I call union. Then it won't confuse me either. Because I realize they have just relabeled stuff. Sure I have to keep track, but as long as they are logical(consistent) then I'll get used to(familiar) with their system and it won't be a problem. I won't get angry or upset that they are trying to pull the rug out from underneath me. I'll realize that they just speak French and if I want to communicate with them I'll learn French. No big deal, I'll be more enlightened from doing so. Sure it takes some time, but what else do we humans have to do? Everything we do just superficial anyways.
Re: Unicode function name? ∩
On Monday, 29 August 2016 at 12:53:26 UTC, Jesper Tholstrup wrote:
On Sunday, 28 August 2016 at 05:21:03 UTC, Tofu Ninja wrote:
Are unicode function names not supported in dmd?
bool ∩(A, B)(A a, B b){
return intersect(a, b);
}
Error: character 0x2229 is not a valid token
Personally, I would prefer 'intersect' as a function name over
'∩' anytime.
Which benifits does the symbols add?
It's concise and has a very specific meaning. If one is working
with mathematical objects and set up correctly then it can be
more easily interpreted because it is `inline` with standard
mathematical syntax.
It's the same reason mathematicians prefer ∩ over intersect. You
would prefer it too if you got used to it. The whole point of
symbols is to simplify, ∩ is more simple than intersect as the
first requires 1 symbol and the second requires 8 symbols.
Re: Hash table element existence check
On Saturday, 3 September 2016 at 14:07:27 UTC, Cauterite wrote:
On Saturday, 3 September 2016 at 12:33:26 UTC, Illuminati wrote:
On Saturday, 3 September 2016 at 07:44:28 UTC, Cauterite wrote:
On Friday, 2 September 2016 at 19:38:34 UTC, Illuminati wrote:
I am trying to create a hash table and would like an
efficient way to be able to know if an element exists to
test for collisions.
Just do a regular lookup on the hash? It's an O(1) operation,
like 4 instructions.
Huh? One can look up fine, but how does one know if the result
is valid or not?
Okay I think I misinterpreted the question. I believe when I
did this my solution was to have an additional template
parameter specifying null key values, so the template was like
this:
struct HashTbl(
K, /* key type */
V, /* value type */
K NullKey, /* key placeholder value */
alias hash_key, /* hash function */
alias keys_eq /* equality function */
) {...
I guess this doesn't really solve the problem, but makes it the
user's problem.
Yeah, and there might not be any "null" keys. If there is, then
it is easy, But, say the key is an int... what is "null"? While
it does let the user define what null means, it assumes that it
is possible to do so and that might not always be the case.
I suppose one could then switch to pointers and waste a bit of
space if necessary. The main point of the question was if there
were any tricks that avoided this problem. E.g., maybe the hash
function itself could be used to determine if the key exists. Not
sure how but who knows?
I could keep a bitarray, but wasting around 12% space.
That assumes your (K,V) tuples are 1 byte total, right?
Yeah. Larger values will reduce the size to some degree. Really,
it is simply N/8 wasted space. For large N it becomes a problem.
Maybe not a huge deal since virtually most of the time N < 1M,
and it would be around 125k bytes for such a large array. Large
arrays could probably be handled differently if memory
constraints were such an issue.
Re: How compiler detects forward reference errors
On Sunday, 4 September 2016 at 19:15:15 UTC, Igor wrote:
On Saturday, 3 September 2016 at 14:13:27 UTC, Lodovico
Giaretta wrote:
On Saturday, 3 September 2016 at 14:06:06 UTC, Igor wrote:
Can anyone explain in plain English how does compiler process
and detect a "test.d(6) Error: forward reference of variable
a" in following code:
import std.stdio;
enum a = 1 + b;
enum d = 5 + a; // No error here
enum b = 12 + c;
enum c = 10 + a; // error here
void main()
{
writeln("Hello World!", b);
}
a needs b to be initialized. So b must be initialized before
a. Let's write this b->a. Now b needs c. So c->b. c needs a,
so a->c. If we sum everything, we have that a->c->b->a. This
mean that to initialize a we need b, to initialize b we need
c, but to initialize c we need a. So to initialize a we need
a, which is not possible. We need a before having initialized
it.
On the other hand, a->d is not a problem, as d can be
initialized after a.
So, you are saying compiler is keeping a kind of linked list of
dependencies and then checks if any of those lists are
circular? But how exactly would that list be structured since
one expression can have multiple dependencies, like:
enum a = b + c + d + e;
enum b = 10 + c;
enum c = d + e + a;
...
It is not complicated. Each expression is incomplete. The
compiler can easily keep track if a variable is completely
defined or incompletely defined. If it is completely defined it
must be able to be evaluated at CT. It can be evaluated because
it only depends on things that are evaluatable(such as numbers
and mathematical operations, etc).
So, any expression that depends on something else, that something
else must be completely evaluatable for the dependent expression
to be completely evaluatable.
That is "completely evaluatable" is transitive. As the compiler
processes expressions, it can check just have a flag to mark
variable that "hold" those expressions(or were assigned) as
either being evaluated or not. If it is, it, say, is marked. Then
other other expressions that depend on the variable(s) require
all it's dependencies to have been evaluated.
For forward references, it is not much difference between that
and an undefined variable except the compiler "looks ahead"
and knows that the variables were declared after they were used.
Not a lot of difference between the two except the compiler tries
to be a little smarter in one case.
For the compiler to actually finish it's job, every single
expression, statement, etc must be interpreted properly. If it is
not, it can't compute the result. The "program" is invalid. There
is effectively a one to one correspondence between the languages
grammar and the "machine code" that the compiler spits out. If
there is not, then the compiler simply cannot produce a result(it
does not know how or understand what the programmer wants).
It is very complex, in many ways, but the rules are simple and
well defined(they must be to be able to produce consistent and
valid results). It is like physics or any scientific thing. The
are "laws" of behavior and no matter how complex something
behaves in the physical world, it must behave according to those
laws. There are laws in a programming language(the grammar) and
every program must abide by them or the program is invalid.
Using a variable before it is defined does not make sense. It is
illogical, unmathematical, unscientific, and meaningless.
One could argue that something like
enum a = b + c;
enum b = 10 + c;
enum c = 4;
could be valid, and this is true, if we work from the bottom up.
But that is just grammatical transformations. We generally work
top down and all grammars I know of use top down. One can't use
both because it would produce ambiguous results and is rather
meaningless.
But
enum a = b;
enum b = a;
is meaningless in any interpretation and doesn't work no matter
how one defines things, in general. Of course, one can build in
any type of craziness in to a grammar and make such things
interpretable but generally, while simple cases work, more
complex cases become ambiguous and meaningless, hard to reason
about, etc.
So, a compiler creates a set of rules and a programmer(should be
programmar, but...) learns those rules and tries to express what
he wants done by the program in terms of those rules. The
compiler then takes the "code" from the programmer and checks to
see if it fits the rules of the grammar and if it does, it
converts the code in to a program to execute the "specific" rules
the programmer coded.
Now, the compiler can decide how it wants to process the code.
This is where the "forward reference" comes in for D. Not all
compilers do this. Some will just process the first line and say
"Hey, there is no b in my symbol table. FAIL!". D goes a step
further and doesn't stop immediately, it processes the next
line.. etc. But all that is implementation details that depends
on the specific
Re: Hash table element existence check
On Saturday, 3 September 2016 at 09:43:04 UTC, Basile B. wrote: On Friday, 2 September 2016 at 19:38:34 UTC, Illuminati wrote: I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. I could keep a bitarray, but wasting around 12% space. I could use pointers(null check) to elements but this creates fragmentation. It is not terrible, just curious if anyone has a better way? fragmentation is a consequence of the hash function. You should set the hasher as a template parameter so that, according to the value type, the best hash fun (the one that creates less clustering) can be supplied. I mean memory fragmentation. If the key and value are structs, The memory is an array of tuple(key, value). Any scanning and returning are quite efficiency since all the tuples are next to each other. If they are pointers to the key/value then they could point to any location in memory. Scanning and such are far more likely to create cache misses. Maybe not a big deal for simple one-time access but in other cases it could be extremely slow(such as iterating over the table). But otherwise the buckets is almost always an array of ReturnType!hashFun with the max value wrapped around the next power of two value following entry count. My hash table is simply a fixed array of type X = tuple(key, value). X is at location key.hashOf % length(more or less). When the table becomes too small, it is enlarged and everything is rehashed. But keys and values can be values or references and this changes the behavior. references can be checked for null, but values can't.
Re: Hash table element existence check
On Saturday, 3 September 2016 at 07:44:28 UTC, Cauterite wrote: On Friday, 2 September 2016 at 19:38:34 UTC, Illuminati wrote: I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. Just do a regular lookup on the hash? It's an O(1) operation, like 4 instructions. Huh? One can look up fine, but how does one know if the result is valid or not?
Re: Hash table element existence check
On Friday, 2 September 2016 at 19:48:30 UTC, Steven Schveighoffer wrote: On 9/2/16 3:38 PM, Illuminati wrote: I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. You mean you are writing your own hash table, or you want to use a D hash table (associative array)? First. I could keep a bitarray, but wasting around 12% space. I could use pointers(null check) to elements but this creates fragmentation. It is not terrible, just curious if anyone has a better way? I'm not sure I understand the question. Hash tables have many many many different ways to implement. Obviously, marking empty buckets somehow is necessary. -Steve Yes, one must have a way to mark empty "buckets"(I hate that term! Seems so banal for some reason ;/) If using pointers, which is what I use, then null means empty, but one can't use inline structs and which then can create data fragmentation. If the structs are inline, there is no way to know if the element is a valid struct or empty. One could test against the .init, say, but I don't think any of that is safe. Hence a bitmap could be used in that case, but wastes a lot of space. I don't see any other way though. Pointers, also, waste memory rather than structs inline and effectively is a bitmap but does save space for sparse maps.
Hash table element existence check
I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. I could keep a bitarray, but wasting around 12% space. I could use pointers(null check) to elements but this creates fragmentation. It is not terrible, just curious if anyone has a better way?
Re: InterlockedIncrement, InterlockedCompareExchange, etc
On Sunday, 28 August 2016 at 20:38:30 UTC, Lodovico Giaretta wrote: On Sunday, 28 August 2016 at 19:53:51 UTC, Illuminati wrote: What are the D equivalents to these types of functions? I do not see anything in core.atomic that can accomplish this. I have tried to include core.sys.windows.winbase but still get linker errors(I've also directly tried importing kernel32 using various methods and still nothing). Regardless, would be nicer to have a more portable solution. I'm not an expert in this field (so probably I'm missing something), but I would think that InterlockedIncrement could be done with atomicOp!"+"(val, 1) and InterlockedCompareExchange with cas. The interlocked functions generate memory barriers, does atomicOp do that? Also D doesn't seem to have a volitile keyword anymore which is required to prevent the compiler from prematurely optimizing critical code.
InterlockedIncrement, InterlockedCompareExchange, etc
What are the D equivalents to these types of functions? I do not see anything in core.atomic that can accomplish this. I have tried to include core.sys.windows.winbase but still get linker errors(I've also directly tried importing kernel32 using various methods and still nothing). Regardless, would be nicer to have a more portable solution.
Re: Proper concurrent nearly lock free efficient nogc storage structures?
On Saturday, 27 August 2016 at 17:27:19 UTC, Dicebot wrote: On Friday, 26 August 2016 at 23:38:02 UTC, Illuminati wrote: Does D have any such thing? I'm having to recreate the wheel here and it isn't fun ;/ Getting in the way of real work ;/ Surely you would think that with the power D has such things would exist by now? There doesn't seem to be much demand for that as concurrency trend keeps moving from making shared access transparent to minimizing or even removing it completely. And for many remaining cases locking is acceptable and more simple. Thus I am not very surprised no one has bothered to work on lock-free data structures seriously so far. This is not a solution. D doesn't even seem to any have proper concurrent storage structures.
Re: Proper concurrent nearly lock free efficient nogc storage structures?
On Saturday, 27 August 2016 at 13:12:42 UTC, ZombineDev wrote: On Friday, 26 August 2016 at 23:38:02 UTC, Illuminati wrote: Does D have any such thing? I'm having to recreate the wheel here and it isn't fun ;/ Getting in the way of real work ;/ Surely you would think that with the power D has such things would exist by now? Here's two popular libraries that implement @nogc containers: http://code.dlang.org/packages/emsi_containers http://code.dlang.org/packages/memutils I don't know if in they have containers supporting concurrent lock-free operations, but still, it may be worth having a look. Nope, neither. Kinda useless as you can't use single threaded in a multi-threaded environment. It's either all or nothing here and it seems there is nothing ;/
Re: Proper concurrent nearly lock free efficient nogc storage structures?
On Friday, 26 August 2016 at 23:44:53 UTC, Cauterite wrote: On Friday, 26 August 2016 at 23:38:02 UTC, Illuminati wrote: Does D have any such thing? I'm having to recreate the wheel here and it isn't fun ;/ Getting in the way of real work ;/ @nogc is such a new language feature that you can't expect a lot of support yet from e.g. the standard library. But in any case, Phobos is a very minimal library when it comes to data structures, for better or for worse. I personally hate to say it. However if you don't have your eye on Phobos, disregard my response, it was hard to tell from your question. I would imagine after the addition of nogc that all the required plumbing would be next on the list? not having nogc containers is a real pain ;/ I've implemented a few but I find myself dreading each new container, not so much because it is difficult but because it is time consuming and takes away from real work I should be doing. Surely one of the many intelligent people on this forum should be able to implement some of the basic structures fairly quickly?
Proper concurrent nearly lock free efficient nogc storage structures?
Does D have any such thing? I'm having to recreate the wheel here and it isn't fun ;/ Getting in the way of real work ;/ Surely you would think that with the power D has such things would exist by now?
Re: Judy Arrays
On Thursday, 25 August 2016 at 20:42:42 UTC, Illuminati wrote: http://judy.sourceforge.net/downloads/10minutes.htm Would be nice to have such an implementation. Supposedly one of the best all around data structures in existence? Maybe D could be used to make them work with arbitrary cache-sizes? Anyone up for the challenge? Also, I think it would be best to avoid the GC, so it works in both GC code and non-gc code.
Judy Arrays
http://judy.sourceforge.net/downloads/10minutes.htm Would be nice to have such an implementation. Supposedly one of the best all around data structures in existence? Maybe D could be used to make them work with arbitrary cache-sizes? Anyone up for the challenge?
Re: Nogc Associative Array?
On Thursday, 25 August 2016 at 20:11:32 UTC, Laeeth Isharc wrote: On Thursday, 25 August 2016 at 18:14:42 UTC, Illuminati wrote: Does D have a non-gc based associative array? If not, what would be a good way to go about creating one? See EMSI containers in code.dlang.org Thanks.
Re: nested enum
On Thursday, 25 August 2016 at 01:37:05 UTC, Mike Parker wrote:
On Wednesday, 24 August 2016 at 23:04:25 UTC, Illuminati wrote:
How can I create nested enum like structures?
instead of Enum.X_Y I would like to access like Enum.X.Y
Yet I want it to behave exactly as an enum. I just want to
not use _ as .'s are better as they express more clearly what
I want.
struct MyEnum {
enum X { Y = 10, Z = 20 }
}
void main() {
import std.stdio;
int y = MyEnum.X.Y;
writeln(y);
}
Thanks. I should have thought of that.
Nogc Associative Array?
Does D have a non-gc based associative array? If not, what would be a good way to go about creating one?
nested enum
How can I create nested enum like structures? instead of Enum.X_Y I would like to access like Enum.X.Y Yet I want it to behave exactly as an enum. I just want to not use _ as .'s are better as they express more clearly what I want.
