On Mon, 26 May 2014 19:03:22 -0400, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sat, May 24, 2014 at 11:54:47PM -0700, Steven Schveighoffer via
Digitalmars-d wrote:
On Sat, 24 May 2014 21:39:14 -0700, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On
On Sat, May 24, 2014 at 11:54:47PM -0700, Steven Schveighoffer via
Digitalmars-d wrote:
On Sat, 24 May 2014 21:39:14 -0700, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sat, May 24, 2014 at 06:05:49PM -0700, Steven Schveighoffer via
Digitalmars-d wrote:
On Sat, 24 May
On Sat, 24 May 2014 21:39:14 -0700, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sat, May 24, 2014 at 06:05:49PM -0700, Steven Schveighoffer via
Digitalmars-d wrote:
On Sat, 24 May 2014 02:54:01 -0700, FG h...@fgda.pl wrote:
[...]
Really? Then what does
On Sunday, 25 May 2014 at 06:54:47 UTC, Steven Schveighoffer
wrote:
Any object/struct that defines opCmp but not opEquals is
broken, and deserves to not work with AAs.
If this is the case, then it needs to be documented in
http://dlang.org/operatoroverloading.html (I'm not seeing it
there),
On Sunday, 25 May 2014 at 06:54:47 UTC, Steven Schveighoffer
wrote:
On Sat, 24 May 2014 21:39:14 -0700, H. S. Teoh via
Digitalmars-d digitalmars-d@puremagic.com wrote:
On Sat, May 24, 2014 at 06:05:49PM -0700, Steven Schveighoffer
via Digitalmars-d wrote:
On Sat, 24 May 2014 02:54:01 -0700,
On Sun, 25 May 2014 03:19:37 -0700, Marc Schütz schue...@gmx.net wrote:
On Sunday, 25 May 2014 at 06:54:47 UTC, Steven Schveighoffer wrote:
Any object/struct that defines opCmp but not opEquals is broken, and
deserves to not work with AAs.
If this is the case, then it needs to be documented
On Sun, 25 May 2014 04:59:43 -0700, John Colvin
john.loughran.col...@gmail.com wrote:
On Sunday, 25 May 2014 at 06:54:47 UTC, Steven Schveighoffer wrote:
It's a trivial change to add opEquals when opCmp is defined.
Perhaps I'm being naïve, but can't we just have a default compiler
Bloody Thunderbird. I think I pressed Reply instead of Followup. Sorry, Steven.
On 2014-05-19 15:31, Steven Schveighoffer wrote:
No, in that DMD file, the bucket is a tree, not a doubly-linked list.
Silly me. A look at the body of delnodes should have made it clear that it's a
binary tree.
On Sat, 24 May 2014 02:54:01 -0700, FG h...@fgda.pl wrote:
Bloody Thunderbird. I think I pressed Reply instead of Followup. Sorry,
Steven.
It's OK, it went into my spam folder anyway ;)
On 2014-05-19 15:31, Steven Schveighoffer wrote:
No, in that DMD file, the bucket is a tree, not a
On Sat, May 24, 2014 at 06:05:49PM -0700, Steven Schveighoffer via
Digitalmars-d wrote:
On Sat, 24 May 2014 02:54:01 -0700, FG h...@fgda.pl wrote:
[...]
Really? Then what does TypeInfo.compare(void*, void*) use? For
example here:
auto key_hash = keyti.getHash(pkey); Entry *e;
/*
On Sat, 17 May 2014 16:18:07 -0400, FG h...@fgda.pl wrote:
On 2014-05-17 21:35, bearophile wrote:
FG:
and don't forget the extra memory needed to store the tree for fast
key look-up in the hash array.
I think D now uses a linked list for the collision chains (so opCmp is
useless,
On Saturday, 17 May 2014 at 22:05:03 UTC, bearophile wrote:
monarch_dodra:
for a sorted linked list (or forward iterators in general),
you can find the result with O(N) *walk* iterations, but still
only O(log(N)) *comparison* iterations.
I think I have never implement such algorithm, but
monarch_dodra:
It's not used in phobos (as far as I know of anyways). It
*could* be implemented in SortedRange's BinaryFind though.
Recently SortedRanges were changed, now they don't need to be
random access ranges, so this is possible and I think it's good:
On Saturday, 17 May 2014 at 00:25:13 UTC, sdvcn wrote:
import std.stdio;
import std.utf;
import std.uni;
import std.string;
import std.random;
import std.conv;
int main(string[] argv)
{
size_t[string] bary;
try{
for(size_t i=0;i(size_t.max -1);i++)
On Saturday, 17 May 2014 at 09:26:32 UTC, Marc Schütz wrote:
On Saturday, 17 May 2014 at 00:25:13 UTC, sdvcn wrote:
import std.stdio;
import std.utf;
import std.uni;
import std.string;
import std.random;
import std.conv;
int main(string[] argv)
{
size_t[string] bary;
try{
int main(string[] argv)
{
auto flog = File(results.txt, w);
size_t[string] bary;
for(size_t i=0;i(size_t.max -1);i++)
{
bary[Key: ~ to!(string)(i)] = i;
flog.write(stop i= ~text(i));
flog.seek(0);
On 2014-05-17 12:46, sdvcn wrote:
int main(string[] argv)
{
auto flog = File(results.txt, w);
size_t[string] bary;
for(size_t i=0;i(size_t.max -1);i++)
{
bary[Key: ~ to!(string)(i)] = i;
flog.write(stop i= ~text(i));
flog.seek(0);
FG:
and don't forget the extra memory needed to store the tree for
fast key look-up in the hash array.
I think D now uses a linked list for the collision chains (so
opCmp is useless, despite it's still required for the hashing
protocol).
Bye,
bearophile
On 2014-05-17 21:35, bearophile wrote:
FG:
and don't forget the extra memory needed to store the tree for fast key look-up
in the hash array.
I think D now uses a linked list for the collision chains (so opCmp is useless,
despite it's still required for the hashing protocol).
Indeed, I
FG:
and each bucket points to an ordered double-linked list.
That list is walked left or right depending on what value
Typeinfo::compare returns for two keys. Hmm... isn't opCmp
used by that function? Why useless?
Sorry, I didn't know the linked list is sorted. It's scanned
sequentially,
On 2014-05-17 22:30, bearophile wrote:
Sorry, I didn't know the linked list is sorted. It's scanned sequentially,
because you can't use a binary search on a regular linked list. Perhaps a
skiplist is better to avoid O(n^2) behavour in presence of attacks or
degenerate cases (in past the AA
On Saturday, 17 May 2014 at 20:30:30 UTC, bearophile wrote:
Sorry, I didn't know the linked list is sorted. It's scanned
sequentially, because you can't use a binary search on a
regular linked list. Perhaps a skiplist is better to avoid
O(n^2) behavour in presence of attacks or degenerate
monarch_dodra:
for a sorted linked list (or forward iterators in general), you
can find the result with O(N) *walk* iterations, but still only
O(log(N)) *comparison* iterations.
I think I have never implement such algorithm, but you are right,
and it's nice. Is Phobos using this idea
import std.stdio;
import std.utf;
import std.uni;
import std.string;
import std.random;
import std.conv;
int main(string[] argv)
{
size_t[string] bary;
try{
for(size_t i=0;i(size_t.max -1);i++)
{
bary[Key: ~
24 matches
Mail list logo
