Re: Pseudo namespaces

On Friday, 4 December 2015 at 02:59:12 UTC, Steven Schveighoffer wrote: FWIW, I don't believe this complexity of API is worth it. It may be you have all this wonderful mechanisms to specify exactly the runtime requirements for your algorithms -- and Big-Oh isn't particularly useful, but

Re: Complexity nomenclature

On Friday, 4 December 2015 at 06:05:55 UTC, Tofu Ninja wrote: Also maybe a simpler idea would just be to annotate the the operations with there complexity with UDAs. That way things that really care about the complexity can get it, and those who don't can ignore it. It has the benefit of being

Re: Complexity nomenclature

On Friday, 4 December 2015 at 06:05:55 UTC, Tofu Ninja wrote: When would a generic algorithm even need to know the complexity of the container? A generic algorithm that uses exponential time when given the "wrong" inputs is a hidden danger. This can easily happen when composing with linear

Re: Pseudo namespaces

On Friday, 4 December 2015 at 08:40:13 UTC, Ola Fosheim Grøstad wrote: Big-Oh isn't particularly useful, but having an upper bound on actual running time is useful in real time programming. And to avoid confusion: in real time applications _everything_ is O(1). Anything worse than that is

Re: OT: Swift is now open source

On Thursday, 3 December 2015 at 17:56:49 UTC, tcak wrote: Even on C#, there is nothing like giving the type of a variable like "typeof( another_variable_or_enum ) var;". C# and Java programmers are not aware of what things they are missing :D Never needed typeof. Missing scope guards and

Re: improving scope(finally/success)

On 12/03/15 16:33, Steven Schveighoffer via Digitalmars-d wrote: > auto ref logCall(alias f, Args...)(auto ref Args args) { >auto ref printResult(T)(auto ref T t) >{ > writeln(t); > return t; >} >return printResult(f(args)) > } > > logCall!foo(true); Which will

Forward declaration issue

Hi, I have a strange issue with following coding. void baz(); // forward declaration void foo() { void bar() { baz(); // (1) without f.d. syntax error } void baz() { bar(); } baz(); // (2)

Re: Pseudo namespaces

On Friday, 4 December 2015 at 07:12:50 UTC, Jacob Carlborg wrote: On 2015-12-03 22:02, Dicebot wrote: And for that specific "stable" example - just make it a separate module, problem solved. To make use of module system for symbol resolution one needs to have many small modules, _that_ should

Re: Complexity nomenclature

On Friday, 4 December 2015 at 06:05:55 UTC, Tofu Ninja wrote: On Friday, 4 December 2015 at 03:37:10 UTC, Andrei Alexandrescu wrote: On 12/3/15 10:29 PM, Jack Stouffer wrote: On Friday, 4 December 2015 at 02:21:12 UTC, Andrei Alexandrescu wrote: On 12/03/2015 09:10 PM, Idan Arye wrote: The

Re: Complexity nomenclature

On Friday, 4 December 2015 at 01:55:15 UTC, Timon Gehr wrote: awfully popular outside of actual complexity theory papers. I don't really understand what calling it 'complexity' actually buys though. It will make static arrays look very good. All operations are O(1).

Re: Pseudo namespaces

On Friday, 4 December 2015 at 06:57:17 UTC, Walter Bright wrote: On 12/3/2015 12:59 PM, Dicebot wrote: This isn't any different from namespace struct idiom, is it? I don't like it because it forces the namespace usage even if it isn't needed. If you use mixin templates, you can use or not

Re: Complexity nomenclature

On Friday, 4 December 2015 at 09:09:35 UTC, ZombineDev wrote: and space complexity (the correctness is given). Otherwise, designing large systems becomes impossible, because all large systems have hard performance requirements. I am sorry to say this, but hard performance requirements require

Re: Pseudo namespaces

On Friday, 4 December 2015 at 09:30:08 UTC, Walter Bright wrote: I don't understand your comment that modules are broken. With imports, you can use the module name as a prefix or not. I am referring to Andrei proposal for template "namespaces" + your explanation of how it can be flattened via

Re: Forward declaration issue

On Friday, 4 December 2015 at 09:51:30 UTC, Artur Skawina wrote: No, it's how D is designed -- inside functions the order of declarations matters (and forward declarations don't work). Your version wrongly declares another `baz` at module scope, and, as there's no definition, you end up with

Re: Pseudo namespaces

On 12/4/2015 12:48 AM, Dicebot wrote: True, that didn't come to my mind. But that pushes resulting coding style from "weird but tolerable" to "good luck explaining newbies why D modules are not broken". All for the sake of a putting a dot in the name. Look at perspective for a moment think if

Re: Complexity nomenclature

On Friday, 4 December 2015 at 09:17:07 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 December 2015 at 09:09:35 UTC, ZombineDev wrote: and space complexity (the correctness is given). Otherwise, designing large systems becomes impossible, because all large systems have hard performance

Re: Complexity nomenclature

On Friday, 4 December 2015 at 01:37:33 UTC, 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 function does, not how it does it.

Re: OT: Swift is now open source

On Friday, 4 December 2015 at 02:59:21 UTC, tcak wrote: On Thursday, 3 December 2015 at 20:37:04 UTC, Steven Schveighoffer wrote: On 12/3/15 3:16 PM, Meta wrote: On Thursday, 3 December 2015 at 19:10:04 UTC, Steven Schveighoffer wrote: And the lack of semi-colons has poisoned me from writing

Re: Neat project: add pointer capability to std.bitmanip.bitfields

On Friday, 4 December 2015 at 01:35:45 UTC, deadalnix wrote: First it check for alignement. Considering this : On Thursday, 3 December 2015 at 09:11:12 UTC, Vladimir Panteleev wrote: True, assuming that: 1. The pointers are still aligned at machine word boundaries No. The pointer needs to

Re: Complexity nomenclature

On Friday, 4 December 2015 at 10:35:33 UTC, ZombineDev wrote: However, here we're talking about API for containers and algorithms and I think that putting the complexity in the function signature is better than only using abstract data structures, because it makes you more aware of the

Re: OT: Swift is now open source

On Friday, 4 December 2015 at 10:24:48 UTC, Chris wrote: As opposed to D, there is a lot of conversion going on from C to Swift And they will have to keep converting, as there are breaking changes planned for Swift 3.0: https://github.com/apple/swift-evolution/blob/master/README.md

Re: Struct initializers as expressions

On Thursday, 3 December 2015 at 15:31:49 UTC, Chris Wright wrote: On Thu, 03 Dec 2015 06:38:20 +, Mike Parker wrote: AFAIK, your only option is to use a struct constructor. This is the sort of thing they're used for. Which brings be back to positional arguments, which means that

Re: Struct initializers as expressions

On Friday, 4 December 2015 at 10:42:46 UTC, Marc Schütz wrote: I suggest to make the struct name optional: ... but not forbidden. With templates or "auto" could be useful to force the type.

Re: Struct initializers as expressions

On Friday, 4 December 2015 at 10:42:46 UTC, Marc Schütz wrote: ; Then we can add some syntax sugar to leave out the braces, too: void bar(int a, T t) bar(42, a: "bla", b: "xyz"); This effectively gives us strongly typed named arguments, without making the names part of the function

Re: Complexity nomenclature

On Friday, 4 December 2015 at 07:50:19 UTC, Minas Mina wrote: On Friday, 4 December 2015 at 03:46:39 UTC, Walter Bright wrote: On 12/3/2015 5:27 PM, Andrei Alexandrescu wrote: Now this primitive may have three complexities: * linear in the length of r (e.g. c is a singly-linked list) *

Re: Complexity nomenclature

On Friday, 4 December 2015 at 09:17:07 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 December 2015 at 09:09:35 UTC, ZombineDev wrote: and space complexity (the correctness is given). Otherwise, designing large systems becomes impossible, because all large systems have hard performance

Re: Forward declaration issue

On 12/04/15 09:12, Andre via Digitalmars-d-learn wrote: > Hi, > > I have a strange issue with following coding. > > void baz(); // forward declaration > > void foo() > { > void bar() > { > baz(); // (1) without f.d. syntax error > } > > void baz() > { >

Re: Complexity nomenclature

On Friday, 4 December 2015 at 09:51:05 UTC, tn wrote: "I just want to insert an element. I don't care how long it takes. Why do I need to specify that it should be linear?" In my opinion, there should be "constantInsert", "linearInsert", etc. for those who care about the complexity, and

Re: Forward declaration issue

On Friday, December 04, 2015 08:12:05 Andre via Digitalmars-d-learn wrote: > Hi, > > I have a strange issue with following coding. > > void baz(); // forward declaration > > void foo() > { > void bar() > { > baz(); // (1) without f.d. syntax error > } > > void baz() > { >

Re: Complexity nomenclature

On Friday, 4 December 2015 at 09:33:42 UTC, ZombineDev wrote: Well, I agree, but I didn't say hard real-time, only performance requirements that are hard to achieve because the system is large, and becuase it would cost even more if the system was larger (slower). Yes, if you are writing for

Re: Complexity nomenclature

On Friday, 4 December 2015 at 03:37:10 UTC, Andrei Alexandrescu wrote: On 12/3/15 10:29 PM, Jack Stouffer wrote: On Friday, 4 December 2015 at 02:21:12 UTC, Andrei Alexandrescu wrote: On 12/03/2015 09:10 PM, Idan Arye wrote: The complexities of the operations is a property of the data

Re: Complexity nomenclature

On Friday, 4 December 2015 at 09:50:15 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 December 2015 at 09:33:42 UTC, ZombineDev wrote: Well, I agree, but I didn't say hard real-time, only performance requirements that are hard to achieve because the system is large, and becuase it would cost

Re: Release D 2.069.2

wonderful!

Re: Complexity nomenclature

On Friday, 4 December 2015 at 14:51:40 UTC, CraigDillabaugh wrote: My personal preference would be not to have the complexity in the names, as I prefer shorter/concise names. Typically when I am writing code using containers of any sort I will check the documentation to determine what the cost

Re: Complexity nomenclature

On Friday, 4 December 2015 at 09:17:07 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 December 2015 at 09:09:35 UTC, ZombineDev wrote: and space complexity (the correctness is given). Otherwise, designing large systems becomes impossible, because all large systems have hard performance

Re: Which type it better to use for array's indices?

On Fri, 04 Dec 2015 13:24:16 +, ref2401 wrote: > It seem like `size_t` suites well because 'is large enough to represent > an offset into all addressible memory.' > (http://dlang.org/spec/type.html#size_t) > However sometimes I want index to be less the 0 to represent a > particular case.

[Issue 15402] Make it an error to declare package level symbols when there is no package

https://issues.dlang.org/show_bug.cgi?id=15402 Andre changed: What|Removed |Added CC||an...@s-e-a-p.de --

Re: Struct initializers as expressions

On Friday, 4 December 2015 at 11:25:12 UTC, Mike Parker wrote: On Friday, 4 December 2015 at 10:42:46 UTC, Marc Schütz wrote: ; Then we can add some syntax sugar to leave out the braces, too: void bar(int a, T t) bar(42, a: "bla", b: "xyz"); This effectively gives us strongly typed

Re: Dconf.org is (kinda) down

On 12/04/2015 09:21 AM, Mathias Lang wrote: It is not directly accessible through http://dconf.org/index.php Works using http://dconf.org/2016/index.html so it seems to be a PHP problem. Side note: It would be useful to have a mailing list to report urgent issues like this which would forward

Re: Complexity nomenclature

On Friday, 4 December 2015 at 09:57:48 UTC, Jakob Ovrum wrote: On Friday, 4 December 2015 at 09:51:05 UTC, tn wrote: "I just want to insert an element. I don't care how long it takes. Why do I need to specify that it should be linear?" In my opinion, there should be "constantInsert",

Re: Struct initializers as expressions

On Fri, 04 Dec 2015 15:07:01 +0100, Jacob Carlborg wrote: > But I do see a problem, which I'm guessing Walter would point out as > well. It might/will complicate the overloading rules. What if "a" and > "b" in T would be integers instead. I think that would be ambiguous. Right. I would much

Re: Complexity nomenclature

On Friday, 4 December 2015 at 13:58:50 UTC, Andrei Alexandrescu wrote: On 12/03/2015 10:46 PM, Walter Bright wrote: On 12/3/2015 5:27 PM, Andrei Alexandrescu wrote: Now this primitive may have three complexities: Looks exaggerated, innit? The fact of the matter is people choose collections

Re: Struct initializers as expressions

On Friday, 4 December 2015 at 14:07:01 UTC, Jacob Carlborg wrote: On 2015-12-04 11:42, Marc Schütz wrote: I'd support that, too. I suggest to make the struct name optional: struct S { int a, b; } struct T { string a, b; } void foo(S s); void foo(T t); foo({b: 1, a:

[Issue 15346] Calling interface methods on out contracts causes segfaults

https://issues.dlang.org/show_bug.cgi?id=15346 --- Comment #3 from Alex Parrill --- Still happens on DMD 2.069.2. I haven't gotten around to downloading master and compiling it yet; I don't know if I'll have time for that. --

Re: Complexity nomenclature

On Friday, 4 December 2015 at 13:59:41 UTC, Andrei Alexandrescu wrote: On 12/04/2015 01:05 AM, Tofu Ninja wrote: Also maybe a simpler idea would just be to annotate the the operations with there complexity with UDAs. Great idea, will keep it in mind. Thanks! -- Andrei Yeah. If the primary

Re: Complexity nomenclature

On 12/04/2015 09:50 AM, tn wrote: However, my point is that it seems backwards if 1) When I don't care about the complexity, then I need to specify one (e.g. linearInsert). 2) When I care and want a constant complexity, then I don't specify one (e.g. use insert instead of constantInsert). When

Re: Which type it better to use for array's indices?

On Friday, 4 December 2015 at 13:24:16 UTC, ref2401 wrote: Which type it better to use for array's indices? float[] arr = new float[10]; int i; long j; size_t k; // which one is better arr[i], a[j]or arr[k] ? It seem like `size_t` suites well because 'is large enough to represent an

Re: Complexity nomenclature

On 12/04/2015 01:05 AM, Tofu Ninja wrote: When would a generic algorithm even need to know the complexity of the container? Only always :o). -- Andrei

Re: Complexity nomenclature

On 12/04/2015 01:05 AM, Tofu Ninja wrote: Also maybe a simpler idea would just be to annotate the the operations with there complexity with UDAs. Great idea, will keep it in mind. Thanks! -- Andrei

Re: Complexity nomenclature

On 12/03/2015 10:46 PM, Walter Bright wrote: On 12/3/2015 5:27 PM, Andrei Alexandrescu wrote: Now this primitive may have three complexities: * linear in the length of r (e.g. c is a singly-linked list) * linear in the number of elements after r in the collection (e.g. c is an array) *

Re: Dconf.org is (kinda) down

On 12/04/2015 09:21 AM, Mathias Lang wrote: It is not directly accessible through http://dconf.org/index.php Works using http://dconf.org/2016/index.html so it seems to be a PHP problem. Side note: It would be useful to have a mailing list to report urgent issues like this which would forward

Re: Which type it better to use for array's indices?

On Friday, 4 December 2015 at 13:24:16 UTC, ref2401 wrote: Which type it better to use for array's indices? float[] arr = new float[10]; int i; long j; size_t k; // which one is better arr[i], a[j]or arr[k] ? It seem like `size_t` suites well because 'is large enough to represent an

Re: Pseudo namespaces

On 12/04/2015 02:12 AM, Jacob Carlborg wrote: On 2015-12-03 22:02, Dicebot wrote: And for that specific "stable" example - just make it a separate module, problem solved. To make use of module system for symbol resolution one needs to have many small modules, _that_ should become D idiom. I

Re: Complexity nomenclature

On 12/04/2015 04:51 AM, tn wrote: "I just want to insert an element. I don't care how long it takes. Why do I need to specify that it should be linear?" Oh but you do care. In my opinion, there should be "constantInsert", "linearInsert", etc. for those who care about the complexity, and

benchmark on binary trees

Hi everybody, this is going to be a learning by doing a benchmark test - post. Found this "game" on the web http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees and wanted to experiment on my self, I tried to reimplement some code in D. This:

Re: OT: Swift is now open source

Seems controversial: https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md Bubba.

Re: __traits and string mixins

On Thursday, 3 December 2015 at 13:36:16 UTC, Christian Köstlin wrote: Hi, I started an experiment with the informations that are available for compile time reflection. [...] I think CyberShadow (aka Vladimir Panteleev) has done something similar to this

Re: Complexity nomenclature

On 12/04/2015 03:41 AM, Jakob Ovrum wrote: On Friday, 4 December 2015 at 06:05:55 UTC, Tofu Ninja wrote: When would a generic algorithm even need to know the complexity of the container? A generic algorithm that uses exponential time when given the "wrong" inputs is a hidden danger. This can

Re: Pseudo namespaces

On 12/04/2015 02:19 AM, Minas Mina wrote: On Thursday, 3 December 2015 at 22:54:53 UTC, Andrei Alexandrescu wrote: Nothing. But one thing I was keeping an eye for would be to allow lst.stable.linear.xxx and lst.linear.stable.xxx with one body. -- Andrei Please don't. Choose one to be the

Re: Complexity nomenclature

On 12/04/2015 02:50 AM, Minas Mina wrote: I agree -- putting the complexity (eh, running time) to the primitive's name seems like a bad idea. I believe that stability is a more important "feature" of a sorting algorithm than its running time, because you can make implications about it and use

Re: Which type it better to use for array's indices?

On 2015-12-04 14:24, ref2401 wrote: For instance `find(float[] arr, float v)` may return -1 if `v` has not been found. If "find" is returning an index, it could return arr.length to indicate it was not found. -- /Jacob Carlborg

Re: https everywhere update - dlang.org gets an "A" now!

On Wednesday, 2 December 2015 at 22:17:20 UTC, Walter Bright wrote: On 11/24/2015 10:59 AM, David Nadlinger wrote: > On Monday, 23 November 2015 at 20:55:32 UTC, Walter Bright wrote: >> [...] proper >> [...] fully https! > > There are a number of issues with how SSL is set up on the server, from

Re: Struct initializers as expressions

On 2015-12-04 11:42, Marc Schütz wrote: I'd support that, too. I suggest to make the struct name optional: struct S { int a, b; } struct T { string a, b; } void foo(S s); void foo(T t); foo({b: 1, a: 2}); // foo(S(2, 1)); foo({a: "bla"});// foo(T("bla",

Re: Complexity nomenclature

On 12/04/2015 04:27 AM, Andrea Fontana wrote: And who knows, maybe someone will discover a more efficient way to implement "insertAfter" or the collection itself... We should change its name? Of course. The old name will still work because, remember, there's a hierarchy of operations; those

Dconf.org is (kinda) down

It is not directly accessible through http://dconf.org/index.php Works using http://dconf.org/2016/index.html so it seems to be a PHP problem. Side note: It would be useful to have a mailing list to report urgent issues like this which would forward to the right people. This issue is present

Re: Dconf.org is (kinda) down

On 12/04/2015 09:24 AM, Andrei Alexandrescu wrote: I guess webmas...@dlang.org is the classic solution, I'll let our admin know about that, too. I've also asked the creation of webmas...@dconf.org. -- Andrei

Re: OT: Swift is now open source

On Friday, 4 December 2015 at 03:38:23 UTC, Steven Schveighoffer wrote: Yes, I know that trick. In swift, everywhere you are using/expecting a Foo, it allows the shortcut. It's very nice when you are doing things that require a lot of enum function parameters (UI has a lot of this).

Which type it better to use for array's indices?

Which type it better to use for array's indices? float[] arr = new float[10]; int i; long j; size_t k; // which one is better arr[i], a[j]or arr[k] ? It seem like `size_t` suites well because 'is large enough to represent an offset into all addressible memory.'

Re: Complexity nomenclature

On Friday, 4 December 2015 at 14:08:08 UTC, Andrei Alexandrescu wrote: On 12/04/2015 04:51 AM, tn wrote: "I just want to insert an element. I don't care how long it takes. Why do I need to specify that it should be linear?" Oh but you do care. I don't, if I have a small container of

Re: Complexity nomenclature

On 12/04/2015 01:05 AM, Tofu Ninja wrote: Also maybe a simpler idea would just be to annotate the the operations with there complexity with UDAs. That way things that really care about the complexity can get it, and those who don't can ignore it. It has the benefit of being self documenting as

Re: Wiki article: Starting as a Contributor

On Tuesday, 1 December 2015 at 18:58:37 UTC, Jack Stouffer wrote: On Monday, 3 August 2015 at 21:25:35 UTC, Andrei Alexandrescu wrote: I had to set up dmd and friends on a fresh Ubuntu box, so I thought I'd document the step-by-step process: http://wiki.dlang.org/Starting_as_a_Contributor

Re: Complexity nomenclature

On Friday, 4 December 2015 at 16:06:25 UTC, Andrei Alexandrescu wrote: Well look at what the cat dragged in: http://dpaste.dzfl.pl/711aecacc450 That's quite promising. The code is very preliminary and uses strings for typical complexity values (e.g. "constant", "linear", and later

Re: Complexity nomenclature

On Friday, 4 December 2015 at 15:33:56 UTC, Jonathan M Davis wrote: Only when dealing with an arbitrary number of elements. O(n^2) could be fine if you know for a fact that you're always dealing with a very small number of elements. I think there was a misunderstanding about notation here. If

Another cool mini-project: advance a range within n steps from its end

Like "tail" in Unix. Given a range R r and a number size_t n, return a TakeExactly!R that's r at no more than n steps from its end: TakeExactly!R advanceWithin(R)(R r, size_t n) if (isForwardRange!R); Invariant: assert(r.advanceWithin(n).length <= n); Implementation would send a scout range

Re: OT: Swift is now open source

On Thursday, 3 December 2015 at 20:22:39 UTC, Adam D. Ruppe wrote: On Thursday, 3 December 2015 at 20:16:50 UTC, Meta wrote: Surprisingly (or not), lack of semicolons is something that I have sorely missed in D/++/Java/C#/etc. ever since I first tried Ruby. There's a lot to be said for the

Re: Complexity nomenclature

On Friday, 4 December 2015 at 22:48:03 UTC, Andrei Alexandrescu wrote: On 12/04/2015 03:43 PM, Walter Bright wrote: On 12/4/2015 10:49 AM, Dmitry Olshansky wrote: Was vaguely terrified reading this whole thread until hitting this gem. Seems like a creative use for UDA. Yeah, I think it puts

Re: DMD unittest fail reporting…

On Friday, 4 December 2015 at 19:00:37 UTC, Russel Winder wrote: … is completely hideous, or am I unique in objecting to the mess of output you get on a test fail? You can look at some of the DUB packages: http://code.dlang.org/search?q=test for more advanced testing facilities. I for

Re: OT: Swift is now open source

On 2015-12-04 13:35, rcorre wrote: Do you mean something like: enum Foo { bar, baz } void fun(Foo foo) { } fun(baz); I don't really mind having to use switch/with but I've found myself wishing for the above on occasion. Yes, but in Swift you need to prefix "baz" with a dot. -- /Jacob

Re: Pseudo namespaces

Jacob Carlborg wrote: > On 2015-12-04 15:00, Andrei Alexandrescu wrote: > >> How would one create a module inside a class or struct? -- Andrei > > Hmm, I see that I really didn't understand what you were trying to do. > So you want to create a namespace inside a class or struct? I

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 Friday, 4 December 2015 at 18:21:41 UTC, Walter Bright wrote: On 12/4/2015 7:11 AM, Jonathan M Davis wrote: std.container puts linear and/or stable in some of its names and then creates an alias to whichever one makes sense as the default where the alias doesn't have linear or stable in the

Re: Another cool mini-project: advance a range within n steps from its end

On Friday, 4 December 2015 at 22:53:01 UTC, Andrei Alexandrescu wrote: Doesn't work. Try it! void main() { import std.range : retro, take; import std.stdio : writeln; assert([1,2,3,4,5].retro.take(3).retro == [3,4,5]); } What exactly doesn't work?

Re: Complexity nomenclature

On 12/3/2015 10:05 PM, Tofu Ninja wrote: Also maybe a simpler idea would just be to annotate the the operations with there complexity with UDAs. That way things that really care about the complexity can get it, and those who don't can ignore it. It has the benefit of being self documenting as

Re: Pseudo namespaces

On Friday, 4 December 2015 at 09:30:08 UTC, Walter Bright wrote: On 12/4/2015 12:48 AM, Dicebot wrote: True, that didn't come to my mind. But that pushes resulting coding style from "weird but tolerable" to "good luck explaining newbies why D modules are not broken". All for the sake of a

Re: benchmark on binary trees

On 04.12.2015 15:06, Alex wrote: 3. The compilation was done by: dmd -O -release -boundscheck=off [filename.d] Is there anything else to improve performance significantly? You forgot -inline. By the way, I'm not a fan of using -boundscheck=off like a general optimization flag. It undermines

Re: Complexity nomenclature

On Friday, 4 December 2015 at 18:21:41 UTC, Walter Bright wrote: I suggested in the pseudo namespaces thread using template parameters to express characteristics, as in: remove!(stable, linear) with sensible defaults so most of the time the user would just use: remove The nice

Re: Complexity nomenclature

On 12/4/2015 10:49 AM, Dmitry Olshansky wrote: Was vaguely terrified reading this whole thread until hitting this gem. Seems like a creative use for UDA. Yeah, I think it puts UDA on the map! Instead of string arguments, though, I suggest enums.

Re: Complexity nomenclature

I'll get back to this (on the phone) but this is incorrect: sqrt really belongs under poly, as far as asymptotic behaviour is concerned. Fractional powers are sublinear. And sqrt times sqrt is linear which is important. Andrei

Re: Complexity nomenclature

Timon Gehr wrote: > 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

Re: Another cool mini-project: advance a range within n steps from its end

On 2015-12-04 17:37, Andrei Alexandrescu wrote: Like "tail" in Unix. Given a range R r and a number size_t n, return a TakeExactly!R that's r at no more than n steps from its end: TakeExactly!R advanceWithin(R)(R r, size_t n) if (isForwardRange!R); Invariant: assert(r.advanceWithin(n).length

Re: Another cool mini-project: advance a range within n steps from its end

On Friday, 4 December 2015 at 20:01:10 UTC, Jacob Carlborg wrote: On 2015-12-04 17:37, Andrei Alexandrescu wrote: Like "tail" in Unix. Given a range R r and a number size_t n, return a TakeExactly!R that's r at no more than n steps from its end: TakeExactly!R advanceWithin(R)(R r, size_t n)

Re: Data-drive (aka table-driven) tests

On Fri, 04 Dec 2015 18:49:39 +, Russel Winder via Digitalmars-d wrote: > Is anyone looking at enabling proper data-driven tests by example. > > I am finding that although this can be done trivially in dynamic > languages, in static languages it is less so. Scala can do it due to the >

Re: Complexity nomenclature

On Fri, Dec 04, 2015 at 05:48:03PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > On 12/04/2015 03:43 PM, Walter Bright wrote: > >On 12/4/2015 10:49 AM, Dmitry Olshansky wrote: > >>Was vaguely terrified reading this whole thread until hitting this > >>gem. Seems like a creative use for

Re: benchmark on binary trees

On 04.12.2015 21:30, Alex wrote: Yes, I missed this, sorry. The main part of the question was probably about the class and struct difference. I thought handling with structs and pointers would be faster then with classes. When you use a struct directly, without going through a pointer, that

Re: benchmark on binary trees

On Friday, 4 December 2015 at 19:31:22 UTC, anonymous wrote: Why did you expect the C++ inspired version to be faster? Just because the original was written in C++? From a quick skim the two versions seem to be pretty much identical, aside from names and struct vs class. Names don't make a

Re: Pseudo namespaces

On Friday, 4 December 2015 at 20:58:02 UTC, tcak wrote: On Friday, 4 December 2015 at 09:30:08 UTC, Walter Bright wrote: On 12/4/2015 12:48 AM, Dicebot wrote: [...] I don't understand your comment that modules are broken. With imports, you can use the module name as a prefix or not. The

Re: Pseudo namespaces

On 2015-12-04 15:00, Andrei Alexandrescu wrote: How would one create a module inside a class or struct? -- Andrei Hmm, I see that I really didn't understand what you were trying to do. So you want to create a namespace inside a class or struct? I would probably create a separate struct and

Re: Complexity nomenclature

On Fri, Dec 04, 2015 at 08:03:17PM +, Andrei Alexandrescu via Digitalmars-d wrote: > I'll get back to this (on the phone) but this is incorrect: > > sqrt really belongs under poly, as far as asymptotic behaviour is > concerned. OK, I guess by poly you mean n^k for k>1. I was lumping

Re: Which type it better to use for array's indices?

On Friday, December 04, 2015 13:24:16 ref2401 via Digitalmars-d-learn wrote: > Which type it better to use for array's indices? > > float[] arr = new float[10]; > int i; > long j; > size_t k; > // which one is better arr[i], a[j]or arr[k] ? > > It seem like `size_t` suites well because 'is large

Re: Another cool mini-project: advance a range within n steps from its end

On 12/04/2015 03:01 PM, Jacob Carlborg wrote: On 2015-12-04 17:37, Andrei Alexandrescu wrote: Like "tail" in Unix. Given a range R r and a number size_t n, return a TakeExactly!R that's r at no more than n steps from its end: TakeExactly!R advanceWithin(R)(R r, size_t n) if (isForwardRange!R);

  1   2   >