Re: Operator overloading or alternatives to expression templates

On 09/14/2015 08:09 PM, Andrei Alexandrescu wrote: On 09/13/2015 10:06 AM, Martin Nowak wrote: ... - language regularization It's surprising to find these "arbitrary" language limitations. The non-predictability of what's possible has always been a huge issue for me with C++, i.e. you

Re: Operator overloading or alternatives to expression templates

On 09/14/2015 08:18 PM, Andrei Alexandrescu wrote: On 09/13/2015 01:16 PM, Daniel N wrote: On Sunday, 13 September 2015 at 14:06:46 UTC, Martin Nowak wrote: struct Foo { size_t id; int opCmp(Foo rhs) { if (id < rhs.id) return -1; if (id == rhs.id)

Re: Improving assert-printing in DMD

On 09/30/2015 05:08 AM, Andrei Alexandrescu wrote: On 09/29/2015 05:25 PM, John Colvin wrote: auto pass = getPassword(); pass.clean(); assert(pass == pass.toLower()); //and on we go ... Interesting angle, but it's not something we should worry about. -- Andrei There's also the possibility

Re: Shout out to D at cppcon, when talkign about ranges.

On 09/30/2015 06:06 PM, Joakim wrote: It is amazing how noisy some of the implementation code with templates is in C++: I felt like I was looking at some Haskell variant compared to how clean D would look for the same code. It's easy to write a clean Haskell version, in case you were trying to

Re: Improving assert-printing in DMD

On 09/30/2015 03:10 PM, Andrei Alexandrescu wrote: I encourage making assert smarter seeing (a) it's already used everywhere so the benefits will come for free and (b) it's a built-in. -- Andrei About (b): I'm surprised to see that you seem to have so fundamentally changed your attitude

Re: Improving assert-printing in DMD

On 10/02/2015 01:33 AM, Andrei Alexandrescu wrote: On 10/01/2015 06:41 PM, Timon Gehr wrote: On 09/30/2015 03:10 PM, Andrei Alexandrescu wrote: I encourage making assert smarter seeing (a) it's already used everywhere so the benefits will come for free and (b) it's a built-in. -- Andrei

Re: C++ compiler vs D compiler

On 10/03/2015 12:45 PM, Abdulhaq wrote: Perhaps the answer to this is obvious, but what's harder to write from scratch - a C++ compiler or a D compiler? :-) We know Walter wrote a C++ compiler single handedly, does anyone else recall the C++ Grandmaster qualification, the free course where

Re: Improving assert-printing in DMD

On 10/02/2015 02:47 AM, deadalnix wrote: ... - assert already have a fair amount of magic, notably assert(0) change the way control flow works. Yes, and it is not stellar design. Generally, if it is not possible to wrap a statement or expression in a function without changing its

Re: Is Anything Holding you back?

On 10/02/2015 03:24 PM, Andrei Alexandrescu wrote: On 10/02/2015 09:11 AM, Dmitry Olshansky wrote: On 02-Oct-2015 05:25, Yaser wrote: Are there any critical frameworks or libraries that are holding you back in fully investing in D? Obviously I think D is an awesome language, but some

Re: Behavior of opEquals

On 09/09/2015 01:32 AM, Jonathan M Davis wrote: On Tuesday, 8 September 2015 at 20:55:35 UTC, Timon Gehr wrote: On 09/08/2015 06:49 PM, Jonathan M Davis wrote: Sure, it _could_ be implemented that way, but the only reason I see to do that is if we're specifically looking to support defining

Re: Moving back to .NET

On 09/25/2015 12:45 PM, rumbu wrote: ... Me, I don't have *any* reason to go back in time 20 years ago, I'd advise to stop making those ridiculous and disrespectful statements. It's slightly annoying and does not add anything to your point. I hate that black & white thing on my screen.

Re: Complexity nomenclature

On 12/07/2015 02:46 PM, Andrei Alexandrescu wrote: On 12/7/15 5:14 AM, Timon Gehr wrote: D does not allow overloading of syntax to the extent necessary to make similar things really pleasant in the long run, and it has been repeatedly argued that this is a good thing; that custom parsing should

Re: What complexity have a log(sum) shape?

On 12/08/2015 04:25 PM, Andrei Alexandrescu wrote: I'm working on the complexity algebra and of course trying to simplify my life :o). One good simplification would be to get rid of log(polynomial_sum) terms such as: log(n + m) log(n^^3 + n1^^2 + n2) etc. Do any of these occur in some

Re: An interesting data structure with search time O(sqrt n)

On 12/02/2015 12:26 PM, Timon Gehr wrote: ... ∑ᵢ[2≤i≤m]·log(i)·∑ₖ[0≤k≤⌊i/2⌋-1]·(2·k+1) = ∑ᵢ[2≤i≤m]·log(i)·⌊i/2⌋² It should actually be (⌊i/2⌋-1)² here, but this does not change the asymptotics.

Re: An interesting data structure with search time O(sqrt n)

On 12/02/2015 03:29 PM, Timon Gehr wrote: On 12/02/2015 12:26 PM, Timon Gehr wrote: ... ∑ᵢ[2≤i≤m]·log(i)·∑ₖ[0≤k≤⌊i/2⌋-1]·(2·k+1) = ∑ᵢ[2≤i≤m]·log(i)·⌊i/2⌋² It should actually be (⌊i/2⌋-1)² here, but this does not change the asymptotics. Oops. No, it was actually right. Sorry for the noise.

Re: Complexity nomenclature

On 12/04/2015 03:36 AM, Andrei Alexandrescu wrote: On 12/03/2015 09:27 PM, Timon Gehr wrote: On 12/04/2015 03:19 AM, Andrei Alexandrescu wrote: On 12/03/2015 08:55 PM, Timon Gehr wrote: I don't really understand what calling it 'complexity' actually buys though. Instant understanding by

Re: Complexity nomenclature

On 12/06/2015 08:59 AM, Ola Fosheim Grøstad wrote: On Sunday, 6 December 2015 at 03:24:24 UTC, Timon Gehr wrote: Some upper bounds are incomparable, so there would not be a total order. But that is not a problem. It is a problem in all cases as you usually dont have an optimal bound. Are

Re: Complexity nomenclature

On 12/06/2015 03:39 PM, Timon Gehr wrote: For our purposes, O(f) = { g | ∃c. ∀x⃗. |g(x⃗)| ≤ c·|f(x⃗)|+c }. Hm, this does not actually work too well. E.g., we want O(n+m) ⊆ O(n log m + m log n). This breaks down with that definition if we e.g. fix m=1 and let n vary. Anyway, I think this

Re: Complexity nomenclature

On 12/04/2015 09:03 PM, Andrei Alexandrescu wrote: > >Your cases then become: > >O(1): expBase=1, polyExp=0, logExp=0; >O(log n): expBase=1, polyExp=0, logExp=1; >O((log n)^k): expBase=1, polyExp=0, logExp=k; >O(sqrt n): expBase=1, polyExp=Fraction(1,2), logExp=0; >O(n): expBase=1,

Re: Complexity nomenclature

On 12/06/2015 08:48 PM, Andrei Alexandrescu wrote: >The next step up the expressiveness scale would be to have a >sum-of-products representation. > >Proof of concept (disclaimer: hacked together in the middle of the >night, and not tested thoroughly): > >http://dpaste.dzfl.pl/d1512905accd > >I

Re: Complexity nomenclature

On 12/06/2015 08:48 PM, Andrei Alexandrescu wrote: > >The next step up the expressiveness scale would be to have a >sum-of-products representation. > >Proof of concept (disclaimer: hacked together in the middle of the >night, and not tested thoroughly): > >http://dpaste.dzfl.pl/d1512905accd > >I

Re: Complexity nomenclature

On 12/06/2015 10:35 PM, Ola Fosheim Grøstad wrote: On Sunday, 6 December 2015 at 14:39:05 UTC, Timon Gehr wrote: Are you complaining that the given implementation does not support 'min', or what are you trying to say here? I am saying that comparing bounds is not the same as comparing running

Re: Complexity nomenclature

On 12/07/2015 02:07 AM, Andrei Alexandrescu wrote: On 12/06/2015 07:50 PM, Timon Gehr wrote: On 12/06/2015 08:48 PM, Andrei Alexandrescu wrote: >The next step up the expressiveness scale would be to have a >sum-of-products representation. > >Proof of concept (disclaimer: hacked together in the

Re: Complexity nomenclature

On 12/07/2015 02:05 AM, Andrei Alexandrescu wrote: On 12/06/2015 06:21 PM, Timon Gehr wrote: The implementation of power on BigO given does not actually work in general (there should have been an enforcement that makes sure there is only one summand). I'll think about whether and how it can be

Re: What complexity have a log(sum) shape?

On 12/08/2015 11:31 PM, Andrei Alexandrescu wrote: On 12/08/2015 04:55 PM, Timon Gehr wrote: The context is asymptotic runtime bounds. The special cases for small values of continuous logarithms can just be defined away. They have no relevance for asymptotic runtime analysis (even though

Re: What complexity have a log(sum) shape?

On 12/09/2015 02:02 AM, H. S. Teoh via Digitalmars-d wrote: Big-O notation deals with asymptotic behaviour as the variables approach infinity, so behaviour at 'small' values of m and n are irrelevant. The problem is, however, that only m /or/ n could be small. Therefore, formalizing this

Re: What complexity have a log(sum) shape?

On 12/09/2015 03:06 AM, Algo wrote: On Wednesday, 9 December 2015 at 01:40:12 UTC, Timon Gehr wrote: On 12/09/2015 02:02 AM, H. S. Teoh via Digitalmars-d wrote: Big-O notation deals with asymptotic behaviour as the variables approach infinity, so behaviour at 'small' values of m and n are

Re: What complexity have a log(sum) shape?

On 12/08/2015 09:56 PM, cym13 wrote: On Tuesday, 8 December 2015 at 17:33:49 UTC, Andrei Alexandrescu wrote: On 12/08/2015 12:12 PM, Timon Gehr wrote: O(log(n+m)) = O(log(n)+log(m)). Noice. Yes I did miss it. Thx!! -- Andrei Surely I'm missing something obvious but why is it true exactly?

Re: What complexity have a log(sum) shape?

On 12/08/2015 10:35 PM, Charles wrote: On Tuesday, 8 December 2015 at 21:18:01 UTC, Timon Gehr wrote: On 12/08/2015 09:56 PM, cym13 wrote: On Tuesday, 8 December 2015 at 17:33:49 UTC, Andrei Alexandrescu wrote: On 12/08/2015 12:12 PM, Timon Gehr wrote: O(log(n+m)) = O(log(n)+log(m)).

Re: Complexity nomenclature

On 12/05/2015 04:24 AM, Timon Gehr wrote: If only products should be expressible, But I think not. O(n+m) is common.

Re: Complexity nomenclature

On 12/04/2015 11:57 PM, Andrei Alexandrescu wrote: On 12/04/2015 04:40 PM, Timon Gehr wrote: Another question is how widely applicable BigO should become beyond std.container. I'm thinking we could add complexity annotations to range functions. For example the complexity of map is linear etc.

Re: Complexity nomenclature

On 12/06/2015 12:55 AM, Andrei Alexandrescu wrote: On 12/05/2015 04:52 PM, BLM768 wrote: Well, we could see how CAS libraries handle this kind of stuff (if there _is_ one which handles it)... CAS = ? ... Computer Algebra System, I assume.

Re: Complexity nomenclature

On 12/05/2015 09:48 PM, Andrei Alexandrescu wrote: On 12/04/2015 10:24 PM, Timon Gehr wrote: void foo(@(BigO.linear) int n,@(BigO.linear) int m); But UDAs for parameters are not supported. That's actually pretty neat and easy to work around like this: void foo(int n, int m)

Re: Complexity nomenclature

On 12/06/2015 03:47 AM, BLM768 wrote: log(x^2) should approach log(x) as x approaches infinity, I think. (My calculus is a bit rusty.) log(x^2) = 2 log x.

Re: Another fun one: partialSort with two ranges

On 12/03/2015 08:12 PM, Andrei Alexandrescu wrote: On 12/03/2015 02:09 PM, Andrei Alexandrescu wrote: Yah, please convert to pull request. Using two ranges is just beautiful. Thanks! -- Andrei I should add that the use of chain is liable to be quite a bit less efficient - it's one of those

Re: Another fun one: partialSort with two ranges

On 12/03/2015 05:09 PM, Vladimir Panteleev wrote: On Thursday, 3 December 2015 at 15:18:16 UTC, Andrei Alexandrescu wrote: This should be pretty cool: https://issues.dlang.org/show_bug.cgi?id=15401 Andrei Does chain not provide random access, thus allowing sorting a chain of two ranges?

Re: Under 1000 opened bugs for Phobos

On 12/01/2015 03:17 PM, BBaz wrote: So I don't know...and I ask, should the garbages from bearophile be closed ? This is a loaded question.

Re: Complexity nomenclature

On 12/04/2015 02:27 AM, Andrei Alexandrescu wrote: Consider the collections universe. So we have an imperative primitive like: c.insertAfter(r, x) where c is a collection, r is a range previously extracted from c, and x is a value convertible to collection's element type. The expression

Re: An interesting data structure with search time O(sqrt n)

On 12/03/2015 11:44 PM, Andrei Alexandrescu wrote: On 12/02/2015 06:26 AM, Timon Gehr wrote: Assume the initial array is sorted from largest to smallest. This will be the worst case for this construction algorithm, as each element will be sifted all the way down to leaf level of the last heap.

Re: Pseudo namespaces

On 12/04/2015 02:37 AM, Mike wrote: On Friday, 4 December 2015 at 01:04:33 UTC, Idan Arye wrote: People are going to hate me, but http://dpaste.dzfl.pl/851d1d1f5e4b Doesn't seem to scale to member access: http://dpaste.dzfl.pl/37193377524c /d649/f987.d-mixin-3(7): Error: 'this' is only

Re: Pseudo namespaces

On 12/03/2015 10:29 PM, Andrei Alexandrescu wrote: FWIW I wanted to use it to allow lst.linear.stable.insert() and lst.stable.linear.insert() to refer to the same function, but this is not working. Qualifies as a bug? Yes. (It works with my own implementation of name lookup.)

Re: Complexity nomenclature

On 12/04/2015 03:18 AM, Andrei Alexandrescu wrote: On 12/03/2015 08:37 PM, Jack Stouffer wrote: On Friday, 4 December 2015 at 01:27:42 UTC, Andrei Alexandrescu wrote: These complexities must be reflected in the name of the primitives. I don't see why. IMO, names should convey what the

Re: Complexity nomenclature

On 12/04/2015 03:19 AM, Andrei Alexandrescu wrote: On 12/03/2015 08:55 PM, Timon Gehr wrote: I don't really understand what calling it 'complexity' actually buys though. Instant understanding by everyone. -- Andrei Well, no. "running time" is actually more descriptive.

Re: Pseudo namespaces

On 12/04/2015 03:24 AM, Tofu Ninja wrote: On Friday, 4 December 2015 at 02:02:48 UTC, Timon Gehr wrote: On 12/04/2015 02:37 AM, Mike wrote: On Friday, 4 December 2015 at 01:04:33 UTC, Idan Arye wrote: People are going to hate me, but http://dpaste.dzfl.pl/851d1d1f5e4b Doesn't seem to scale

Re: Complexity nomenclature

On 12/04/2015 03:34 AM, Xinok wrote: On Friday, 4 December 2015 at 01:55:15 UTC, Timon Gehr wrote: Regarding nomenclature, it would be awesome if we could call this "running time" instead of "complexity". Algorithms have running times and memory usages. Problems have (time and space)

Re: Complexity nomenclature

On 12/04/2015 03:36 AM, Andrei Alexandrescu wrote: On 12/03/2015 09:27 PM, Timon Gehr wrote: On 12/04/2015 03:19 AM, Andrei Alexandrescu wrote: On 12/03/2015 08:55 PM, Timon Gehr wrote: I don't really understand what calling it 'complexity' actually buys though. Instant understanding by

Re: Complexity nomenclature

On 12/04/2015 03:35 AM, Andrei Alexandrescu wrote: On 12/03/2015 09:24 PM, Timon Gehr wrote: On 12/04/2015 03:18 AM, Andrei Alexandrescu wrote: On 12/03/2015 08:37 PM, Jack Stouffer wrote: On Friday, 4 December 2015 at 01:27:42 UTC, Andrei Alexandrescu wrote: These complexities must be

Re: An interesting data structure with search time O(sqrt n)

On 12/01/2015 11:48 PM, Andrei Alexandrescu wrote: On 12/01/2015 12:13 AM, Andrei Alexandrescu wrote: On 11/30/15 9:47 PM, Timon Gehr wrote: On 12/01/2015 03:33 AM, Timon Gehr wrote: On 11/30/2015 09:57 PM, Andrei Alexandrescu wrote: So now consider my square heaps. We have O(n) build time

Re: Three people out of four dislike SDL

On 12/01/2015 06:26 PM, Andrei Alexandrescu wrote: On 12/01/2015 09:18 AM, Timon Gehr wrote: On 12/01/2015 03:01 PM, Saurabh Das wrote: now told that 75% of the community doesn't like the change. I'm sorry to enter this discussion, but that's simply not what the poll is saying. It should be

Re: Three people out of four dislike SDL

On 12/02/2015 01:40 PM, Timon Gehr wrote: Since this thread has started (with a suggestion to take actions based on the poll), the answers have basically evened out. It is currently at 48% vs 52%: http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67 This effect wasn't as strong when I

Re: Complexity nomenclature

On 12/07/2015 05:15 PM, Andrei Alexandrescu wrote: On 12/07/2015 09:43 AM, Timon Gehr wrote: 1-2) BigO("1") 3) BigO("count") 4) BigO("distance(first,last)") 5) BigO("ilist.size()") There's also this: On 12/06/2015 12:55 AM, Andrei Alexandrescu wrote: Well you'd need multiple terms if you

Re: Complexity nomenclature

On 12/04/2015 07:37 PM, Andrei Alexandrescu wrote: Following up on this, I thought I'd define a little algebra It will be closed (no arbitrary expressions) ... I think that the exponents matter. E.g. n^1.5 vs n^2. The algebra can be made more expressive while simplifying its

Re: How is `auto` and not `alias` appropriate for alias sequences?

On 12/11/2015 12:18 PM, Shriramana Sharma wrote: Hello. I just found that the following code compiles without any problem: struct Foo { int val; string name; } Foo foo = {1, "one"}; auto t = foo.tupleof; Trying to use `alias` i.o. `auto` above fails. ... The alias should

Re: How is `auto` and not `alias` appropriate for alias sequences?

On 12/11/2015 03:12 PM, ZombineDev wrote: alias can refer to types, templates, template argument lists and compile-time expressions. It can't refer to run-time variables. Yes it can. void main(){ int x=0; alias y=x; y=2; assert(x==2) } It cannot refer to a field or method of

Re: Template parameter-dependent attributes

On 12/16/2015 06:14 PM, Andrei Alexandrescu wrote: So, I wrote this beautiful BigO framework: <400 lines all told, clear code, real nice. Then I got this cold shower: void insertFrontMany(C, R)(C container, R range) @BigO(complexity!(C.insertFront) * linearTime) { ... } My hope being

Re: Template parameter-dependent attributes

On 12/16/2015 06:46 PM, Daniel N wrote: On Wednesday, 16 December 2015 at 17:14:50 UTC, Andrei Alexandrescu wrote: So... attributes are currently not allowed to depend on template parameters, which is a serious damper on enthusiasm. Indeed, please see the discussion in:

Re: We need better documentation for functions with ranges and templates

On 12/15/2015 12:26 PM, rumbu wrote: And personally, I found the MS remark more compact and more user friendly than: "This is a best-effort implementation of length for any kind of range. If hasLength!Range, simply returns range.length without checking upTo (when specified). Otherwise, walks

Re: Another cool project: make double.to!string CTFEable

On 12/16/2015 06:04 PM, tcak wrote: On Wednesday, 16 December 2015 at 15:44:45 UTC, Andrei Alexandrescu wrote: This has been discussed in the past and at a point Walter was looking into it. Currently std.conv.to applied to double uses snprintf, which is obviously non-CTFEable. There's been

Re: We need better documentation for functions with ranges and templates

On 12/17/2015 01:06 AM, John Colvin wrote: One doesn't need to know any results or definitions from complexity theory in order to understand what O(n) means. What it means here is that for large enough n the actual number is bounded from above by n multiplied by some unspecified constant. (In

Re: log(n) amortized growth for containers

On 12/11/2015 04:55 AM, Andrei Alexandrescu wrote: Here's a quick thought on growth schedule for arrays. The classic approach is to grow by a geometric schedule. For example: 1, 2, 4, 8, 16, etc. That way, n memory moves are necessary for achieving a capacity equal to n, so on average we spend

Re: isExpressions -> isValuesSeq

On 12/12/2015 03:51 PM, Mike Parker wrote: On Saturday, 12 December 2015 at 14:05:04 UTC, Shriramana Sharma wrote: Mike Parker wrote: All values, 3 and false included, *are* expressions. They are expressions with one operand and no operator, but they are still expressions.

Re: isExpressions -> isValuesSeq

On 12/12/2015 09:01 PM, Timon Gehr wrote: On 12/12/2015 03:51 PM, Mike Parker wrote: On Saturday, 12 December 2015 at 14:05:04 UTC, Shriramana Sharma wrote: Mike Parker wrote: All values, 3 and false included, *are* expressions. They are expressions with one operand and no operator, but they

Re: isExpressions -> isValuesSeq

On 12/12/2015 07:41 AM, Shriramana Sharma wrote: This is w.r.t. http://dlang.org/phobos/std_traits.html#isExpressions: I am trying the following code: import std.stdio, std.meta, std.traits; void main() { alias a = AliasSeq!(1 + 2, "foo" == "goo"); if (isExpressions!a) write("This

Re: Replacing .tupleof

On 12/11/2015 04:14 PM, ZombineDev wrote: On Friday, 11 December 2015 at 11:36:38 UTC, Shriramana Sharma wrote: Given that TypeTuple is replaced by AliasSeq (though many don't like the new name), it seems that .tupleof should be replaced by .fieldvalues like std.traits is proposed to have

Re: Expression-bodied functions

On 12/31/2015 06:15 PM, Gabriel Garcia wrote: Hello all (: This is my first post here. I don't know if this has been proposed before. Probably, it has been. Either way... https://github.com/dotnet/roslyn/wiki/New-Language-Features-in-C%23-6#expression-bodied-function-members Given D's

Re: Here's looking at you, kid

On 11/23/2015 11:03 PM, Chris wrote: ... Do not watch this, if you identify with any of the following languages: C, C++, Perl, Java, Scala, JavaScript, Go, Rust, bash, Python (2 and 3), Ruby, PHP, Mathematica, C#, Prolog, Lisp http://bjorn.tipling.com/if-programming-languages-were-weapons

Re: Collections question

On 11/27/2015 09:14 PM, Andrei Alexandrescu wrote: There's this oddity of built-in hash tables: a reference to a non-empty hash table can be copied and then both references refer to the same hash table object. However, if the hash table is null, copying the reference won't track the same object

Re: extern(C++, NS)

On 11/29/2015 05:57 AM, Walter Bright wrote: D does not support C++ semantics. You cannot split namespaces into multiple files in D, nor can you add symbols to an existing namespace. For namespace NS, all the declarations in NS have to be in one file and between the { }, just like any other

Re: extern(C++, NS)

On 11/29/2015 05:40 AM, Manu via Digitalmars-d wrote: The trouble mostly appears in this situation: file1.d extern(C++, NS) struct X; file2.d extern(C++, NS) struct Y; file3.d import file1, file2; X x; // nope Y y; // nope Those two actually work for me. NS.X x; // NS

Re: extern(C++, NS)

On 11/29/2015 12:22 PM, Daniel N wrote: On Sunday, 29 November 2015 at 10:58:48 UTC, Manu wrote: On 29 November 2015 at 20:17, Iain Buclaw via Digitalmars-d I think your idea with aliases was just wishful thinking, aliases themselves never worked like that. I thought aliases did produce a

Re: An interesting data structure with search time O(sqrt n)

On 11/30/2015 09:57 PM, Andrei Alexandrescu wrote: So now consider my square heaps. We have O(n) build time (just a bunch of heapifications) and O(sqrt n) search. How do you build in O(n)? (The initial array is assumed to be completely unordered, afaict.)

Re: An interesting data structure with search time O(sqrt n)

On 12/01/2015 03:33 AM, Timon Gehr wrote: On 11/30/2015 09:57 PM, Andrei Alexandrescu wrote: So now consider my square heaps. We have O(n) build time (just a bunch of heapifications) and O(sqrt n) search. How do you build in O(n)? (The initial array is assumed to be completely unordered,

Re: An interesting data structure with search time O(sqrt n)

On 11/30/2015 09:13 PM, Andrei Alexandrescu wrote: I haven't worked out the math for insertion and deletion yet, but they seem to also be around O(sqrt n) or O(log(n) * sqrt(n)). (Assuming the bucket sizes actually grow linearly.) It seems to me that for insertion O(√n̅ log n) is very easy to

Re: extern(C++, NS)

On 11/29/2015 12:13 PM, Ola Fosheim Grøstad wrote: On a related note, does D support inline namespaces? Apparently it affects mangling: http://stackoverflow.com/questions/29764869/can-inline-namespaces-be-used-to-keep-backwards-compatibility-in-a-shared-librar Namespaces affect mangling. The

Re: Three people out of four dislike SDL

On 12/01/2015 03:01 PM, Saurabh Das wrote: now told that 75% of the community doesn't like the change. I'm sorry to enter this discussion, but that's simply not what the poll is saying. It should be very obvious that the poll is basically meaningless.

Re: Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent

On 11/20/2015 09:06 PM, Chris Wright wrote: ... When people complain about others being offended, it's usually to distract from the issue at hand. When people complain about others being offended, I think it is usually because being offended can be a way to artificially add weight to the

Re: foreach and element type inference

On 11/24/2015 05:58 AM, Jonny wrote: Else, why not allow stuff like e = 1; instead of auto e = 1; Because the first notation already has a different meaning.

Re: extern(C++, ns)

On 01/11/2016 10:12 PM, Walter Bright wrote: On 1/11/2016 12:56 PM, Timon Gehr wrote: This not an undefined identifier error. Please post an example of the bug you assert. I can't, as Manu hasn't provided the code. I'm just saying that, if the following is true: On 01/11/2016 02:20 AM,

Re: opCmp, [partial/total/pre]orders, custom floating point types etc.

On 01/12/2016 10:02 PM, John Colvin wrote: On Tuesday, 12 January 2016 at 20:52:51 UTC, Timon Gehr wrote: On 01/12/2016 07:27 PM, John Colvin wrote: ... struct S{ auto opCmp(S rhs){ return float.nan; } bool opEquals(S rhs){ return false; } } unittest{ S a,b;

Re: opCmp, [partial/total/pre]orders, custom floating point types etc.

On 01/12/2016 07:27 PM, John Colvin wrote: ... struct S{ auto opCmp(S rhs){ return float.nan; } bool opEquals(S rhs){ return false; } } unittest{ S a,b; assert(!(a==b)); assert(!(ab)); assert(!(a>=b)); }

Re: Today was a good day

On 01/12/2016 04:15 AM, Andrei Alexandrescu wrote: A few primitive algorithms got quite a bit quicker. https://github.com/D-Programming-Language/phobos/pull/3921 https://github.com/D-Programming-Language/phobos/pull/3922 Destroy! Andrei Nice. - This probably does not make a large

Re: extern(C++, ns)

On 01/11/2016 02:59 AM, Walter Bright wrote: On 1/10/2016 5:20 PM, Manu via Digitalmars-d wrote: This design doesn't give us anything, and you seem to be resisting making an argument for its existence. We don't need to do this, we don't need to waste any more time. I appreciate that, but

Re: extern(C++, ns)

On 01/11/2016 09:53 PM, Walter Bright wrote: On 1/11/2016 12:23 PM, Timon Gehr wrote: If replacing extern(C++,ns) with extern(C++) fixes undefined identifier errors, then we are talking about a bug in the implementation. No: - module s; int ns,b; - module t; int ns,c; - import s;

Re: The Case Against Autodecode

On 02.06.2016 23:06, Andrei Alexandrescu wrote: As the examples show, the examples would be entirely meaningless at code unit level. So far, I needed to count the number of characters 'ö' inside some string exactly zero times, but I wanted to chain or join strings relatively often.

Re: The Case Against Autodecode

On 02.06.2016 21:05, Andrei Alexandrescu wrote: On 06/02/2016 01:54 PM, Marc Schütz wrote: On Thursday, 2 June 2016 at 14:28:44 UTC, Andrei Alexandrescu wrote: That's not going to work. A false impression created in this thread has been that code points are useless They _are_ useless for

Re: The Case Against Autodecode

On 02.06.2016 21:26, Andrei Alexandrescu wrote: ag0aep6g wrote: On 06/02/2016 09:05 PM, Andrei Alexandrescu wrote: Pretty much everything. Consider s and s1 string variables with possibly different encodings (UTF8/UTF16). * s.all!(c => c == 'ö') works only with

Re: The Case Against Autodecode

On 02.06.2016 22:07, Walter Bright wrote: On 6/2/2016 12:05 PM, Andrei Alexandrescu wrote: * s.all!(c => c == 'ö') works only with autodecoding. It returns always false without. The o is inferred as a wchar. The lamda then is inferred to return a wchar. No, the lambda returns a bool. The

Re: The Case Against Autodecode

On 02.06.2016 23:46, Andrei Alexandrescu wrote: On 6/2/16 5:43 PM, Timon Gehr wrote: .̂ ̪.̂ (Copy-paste it somewhere else, I think it might not be rendered correctly on the forum.) The point is that if I do: ".̂ ̪.̂".normalize!NFC.byGrapheme.findAmong([Grapheme("."),Grapheme(",")]) no

Re: The Case Against Autodecode

On 02.06.2016 22:28, Andrei Alexandrescu wrote: On 06/02/2016 04:12 PM, Timon Gehr wrote: It is not meaningful to compare utf-8 and utf-16 code units directly. But it is meaningful to compare Unicode code points. -- Andrei It is also meaningful to compare two utf-8 code units or two utf-16

Re: The Case Against Autodecode

On 02.06.2016 22:51, Andrei Alexandrescu wrote: On 06/02/2016 04:50 PM, Timon Gehr wrote: On 02.06.2016 22:28, Andrei Alexandrescu wrote: On 06/02/2016 04:12 PM, Timon Gehr wrote: It is not meaningful to compare utf-8 and utf-16 code units directly. But it is meaningful to compare Unicode

Re: The Case Against Autodecode

On 02.06.2016 22:13, Andrei Alexandrescu wrote: On 06/02/2016 03:34 PM, deadalnix wrote: On Thursday, 2 June 2016 at 19:05:44 UTC, Andrei Alexandrescu wrote: Pretty much everything. Consider s and s1 string variables with possibly different encodings (UTF8/UTF16). * s.all!(c => c == 'ö')

Re: The Case Against Autodecode

On 02.06.2016 23:56, Walter Bright wrote: On 6/2/2016 1:12 PM, Timon Gehr wrote: ... It is not meaningful to compare utf-8 and utf-16 code units directly. Yes, you have a good point. But we do allow things like: byte b; if (b == 1) ... Well, this is a somewhat different case,

Re: The Case Against Autodecode

On 02.06.2016 22:29, Andrei Alexandrescu wrote: On 06/02/2016 04:22 PM, cym13 wrote: A:“We should decode to code points” B:“No, decoding to code points is a stupid idea.” A:“No it's not!” B:“Can you show a concrete example where it does something useful?” A:“Sure, look at that!” B:“This isn't

Re: The Case Against Autodecode

On 02.06.2016 23:20, deadalnix wrote: The sample code won't count the instance of the grapheme 'ö' as some of its encoding won't be counted, which definitively count as doesn't work. It also has false positives (you can combine 'ö' with some combining character in order to get some strange

Re: The Case Against Autodecode

On 02.06.2016 23:23, Andrei Alexandrescu wrote: On 6/2/16 5:19 PM, Timon Gehr wrote: On 02.06.2016 23:16, Timon Gehr wrote: On 02.06.2016 23:06, Andrei Alexandrescu wrote: As the examples show, the examples would be entirely meaningless at code unit level. So far, I needed to count the

Binding contexts

On 03.06.2016 13:11, Vladimir Panteleev wrote: I think that alias template parameters and context binding are a very rich and unexplored area of D, which will allow writing some really efficient and composable code. A while ago I created a few DMD pull requests with related improvements, and

Re: Lifetime tracking

On 03.06.2016 01:29, Timon Gehr wrote: [1] It might be possible to get that example to pass the type checker with 'return' annotations only if I change 'ref' to 'out', but often more than two lifetimes are involved, and then it falls flat on its face. To be slightly more explicit: void

Re: The Case Against Autodecode

On 03.06.2016 00:26, Walter Bright wrote: On 6/2/2016 3:11 PM, Timon Gehr wrote: Well, this is a somewhat different case, because 1 is just not representable as a byte. Every value that fits in a byte fits in an int though. It's different for code units. They are incompatible both ways.

Re: The Case Against Autodecode

On 03.06.2016 00:23, Andrei Alexandrescu wrote: On 06/02/2016 05:58 PM, Walter Bright wrote: On 6/2/2016 1:27 PM, Andrei Alexandrescu wrote: The lambda returns bool. -- Andrei Yes, I was wrong about that. But the point still stands with: > * s.balancedParens('〈', '〉') works only with

Lifetime tracking

On 03.06.2016 00:29, Walter Bright wrote: On 6/2/2016 3:10 PM, Marco Leise wrote: we haven't looked into borrowing/scoped enough That's my fault. As for scoped, the idea is to make scope work analogously to DIP25's 'return ref'. I don't believe we need borrowing, we've worked out another

<    3   4   5   6   7   8   9   10   11   12   >