Re: 64 bit size_t
On Monday, 17 February 2014 at 07:17:06 UTC, Steve Teale wrote: What is size_t for 64 bit? Steve Sorry parent.children is just a straightforward array Sorry again - forget about it. I'd forgotten that D actually says int is 32 bits, and ulong is 64, and size_t for a 64 bit machine is obviously 64. I'll just go through the code and either change int to ulong or use a cast. ;=(
Re: 64 bit size_t
On Monday, 17 February 2014 at 07:46:02 UTC, Steve Teale wrote: On Monday, 17 February 2014 at 07:17:06 UTC, Steve Teale wrote: What is size_t for 64 bit? Steve Sorry parent.children is just a straightforward array Sorry again - forget about it. I'd forgotten that D actually says int is 32 bits, and ulong is 64, and size_t for a 64 bit machine is obviously 64. I'll just go through the code and either change int to ulong or use a cast. ;=( or use auto :)
Re: 64 bit size_t
On 2/17/2014 4:15 PM, Steve Teale wrote: parent is just a straightforward array What is size_t for 64 bit? It's ulong on 64-bit and uint on 32. size_t and ptrdiff_t are defined as aliases in object.d.
Re: 64 bit size_t
On 2/17/2014 4:23 PM, evilrat wrote: but it looks like length is not size_t but ulong in which case you need explicit cast from larget to smaller type. check lenght signature size_t is an alias to ulong on 64-bit. Aliases tend to show up in error messages as the underlying type.
Re: 64 bit size_t
On Monday, 17 February 2014 at 07:15:20 UTC, Steve Teale wrote: Why is it that with 32 bit compilation, int is 32 bits, but apparently this convention is not followed in 64 bit compilation. I have not installed the 64 bit compiler yet, but apparently int len = parent.children.length+1; provokes the following error acomp.d(782): Error: cannot implicitly convert expression (parent.children.length + 1LU) of type ulong to int parent is just a straightforward array What is size_t for 64 bit? Steve it is equal to machine word size. 4 bytes on x86, 8 on x64. but it looks like length is not size_t but ulong in which case you need explicit cast from larget to smaller type. check lenght signature
64 bit size_t
Why is it that with 32 bit compilation, int is 32 bits, but apparently this convention is not followed in 64 bit compilation. I have not installed the 64 bit compiler yet, but apparently int len = parent.children.length+1; provokes the following error acomp.d(782): Error: cannot implicitly convert expression (parent.children.length + 1LU) of type ulong to int parent is just a straightforward array What is size_t for 64 bit? Steve
Re: 64 bit size_t
On Monday, 17 February 2014 at 07:15:20 UTC, Steve Teale wrote: Why is it that with 32 bit compilation, int is 32 bits, but apparently this convention is not followed in 64 bit compilation. I have not installed the 64 bit compiler yet, but apparently int len = parent.children.length+1; provokes the following error acomp.d(782): Error: cannot implicitly convert expression (parent.children.length + 1LU) of type ulong to int parent is just a straightforward array What is size_t for 64 bit? Steve Sorry parent.children is just a straightforward array
Re: Can opCmp return a 'long' instead of 'int'?
On Sunday, 16 February 2014 at 15:19:08 UTC, Timon Gehr wrote: On 02/16/2014 04:13 PM, Timon Gehr wrote: On 02/16/2014 02:59 PM, Saurabh Das wrote: This does compile and run correctly, but are there any hidden assumptions or requirements on the return value of opCmp that I should be aware of? Is there any reason that doing this may be not be wise? No, this is fine. To be more precise: Returning long is fine. The subtraction trick does not work in general regardless of return type: import std.stdio; struct S{ int d; int opCmp(S r){ return d - r.d; } } void main(){ assert(S(1)S(int.max)); // passes. oops. } Right. I didn't expect that! So I shouldn't use it anyway. Thanks! Saurabh
Re: Optimize my code =)
Robin: I always thought that D would be much easier to learn than C++ as all the people always say that C++ is the most complex language. After what I have learned so far D seems to be much more complex which isn't bad in general, but the learning curve doesn't feel so well atm as I am mainly confused by many things instead of getting what happens behind the scene. D is not a small language, it contains many features, but compared to C++ it has less corner cases, less traps, and on default it's often safer than C++. In C++ you need to take care of many details if you want to write correct code. Writing D code should be faster and safer than C++. immutability which result in zero performance boost in non-paralell environments, A good D compiler like ldc2 is sometimes able to optimize better the code that uses immutable/const. But immutability is also for the programmer: to make the code simpler to reason about, and safer. the fact that classes are by-ref and structs are by-val is also confusing from time to time to be honest.) D seems to be more problematic when it comes to learning how to optimize the code. Perhaps because D also focuses a little more on correctness of the code. You see this even more in Ada language. I would love to see how much performance a D vetaran like you is able to grab out of my codes. Just tell me where I shall upload them and I will do so. I guess your code is composed by just one or two small D modules, so you can post it here: http://dpaste.dzfl.pl/ You can also upload there the Java code, to help me compare and to know what you were trying to write :-) However, what is true is, that it is (at least for me) harder to learn how to write efficient code for D than it was to learn it for C++. But I think on average it's a little harder to write correct code in C++ compared to D. Bye, bearophile
Re: [video tutorial] hello world using dmd, rdmd, dub and vibe.d
On Saturday, 15 February 2014 at 13:28:24 UTC, simendsjo wrote: http://youtu.be/8TV9ZZteYEU The content wasn't planned, and English is not my native tongue. Hopefully it can still be useful for newbies. This is pretty much a response to a recent discussion on the lack of documentation/tutorials: http://forum.dlang.org/post/spdddifmaacihlcum...@forum.dlang.org PS: The many delays are X going black, forcing me to switch to a different terminal and back again. Really awesome! I had plans to create something similar to Gynvael Coldwind's ReverseCraft series[1] but dedicated to D generally (not really D as a tool for reversing but basics *G*) Unfortunately, recently my time was limited. Good to see that others also think it is a good idea! Your english was very good in my opinion. I understood everything and I'm not using English on a daily basis. You've got my respects simendsjo and I am definitely looking for more of this! Best regards, Damian Ziemba
Re: [video tutorial] hello world using dmd, rdmd, dub and vibe.d
On Monday, 17 February 2014 at 00:51:17 UTC, nazriel wrote: On Saturday, 15 February 2014 at 13:28:24 UTC, simendsjo wrote: http://youtu.be/8TV9ZZteYEU The content wasn't planned, and English is not my native tongue. Hopefully it can still be useful for newbies. This is pretty much a response to a recent discussion on the lack of documentation/tutorials: http://forum.dlang.org/post/spdddifmaacihlcum...@forum.dlang.org PS: The many delays are X going black, forcing me to switch to a different terminal and back again. Really awesome! I had plans to create something similar to Gynvael Coldwind's ReverseCraft series[1] but dedicated to D generally (not really D as a tool for reversing but basics *G*) Unfortunately, recently my time was limited. Good to see that others also think it is a good idea! Your english was very good in my opinion. I understood everything and I'm not using English on a daily basis. You've got my respects simendsjo and I am definitely looking for more of this! Best regards, Damian Ziemba [1] http://www.youtube.com/user/GynvaelColdwind/videos http://gynvael.coldwind.pl/
Re: Strange result with nextUp for reals
If you swap the line to writefln("nextUp of %a is %a", 1.0L, 1.0L.nextUp()); you get the same result as the second case.
Re: Optimize my code =)
On Sunday, 16 February 2014 at 23:47:08 UTC, Robin wrote: I am not currently aware of the "move semantics" in D or what it is called there. However, I am not quite sure if D does an equally good job as C++ in determining if a value can be moved or not. I have made some simple tests which showed me that the swap-assignment and the move-constructor are never called in D at code where C++ would certainly take them, instead D just copies values which were in fact rvalues ... (Maybe I just don't get the whole thing behind the scenes - and I am really hoping it.) What swap assignment, what move constructor? :) Here are the rules for moving rvalues in D: 1) All anonymous rvalues are moved; 2) Named temporaries that are returned from functions are moved; 3) That's it :) No other guarantees are offered (i.e. compilers may or may not try to be smart in other scenarios). Sometimes when you want an explicit move you can use std.algorithm.move function. But keep in mind that its current implementation is incomplete (i.e. it doesn't handle immutability properly). This code illustrates it all: http://dpaste.dzfl.pl/c050c9fccbb2 @All of you: What I have done since the last time: I have changed my mind - matrix is now a value type. However, I wasn't sure about this step because I planned to implement dense and sparse matrices which could inherit from a basic matrix implementation in thus required to be classes. Templates, perhaps?
Re: [video tutorial] hello world using dmd, rdmd, dub and vibe.d
On Sunday, 16 February 2014 at 22:57:44 UTC, Brad Anderson wrote: (...) Nicely done. It's a bit quiet (I had to max out my volume and put on headphones to hear). Thanks. I'll crank up the volume for the next one.
Re: Optimize my code =)
Hiho, thanks again for your answers! I don't know where to start ... @Stanislav Blinov: I am not currently aware of the "move semantics" in D or what it is called there. However, I am not quite sure if D does an equally good job as C++ in determining if a value can be moved or not. I have made some simple tests which showed me that the swap-assignment and the move-constructor are never called in D at code where C++ would certainly take them, instead D just copies values which were in fact rvalues ... (Maybe I just don't get the whole thing behind the scenes - and I am really hoping it.) My statement that the "in" and "body" block of the assignment operator slows down the whole code isn't true anymore. Don't know what fixed it tough. @bearophile: Yeah, you are completely right - I am super confused at the moment. I always thought that D would be much easier to learn than C++ as all the people always say that C++ is the most complex language. After what I have learned so far D seems to be much more complex which isn't bad in general, but the learning curve doesn't feel so well atm as I am mainly confused by many things instead of getting what happens behind the scene. (e.g. move semantics, the whole army of modifiers, immutability which result in zero performance boost in non-paralell environments, the fact that classes are by-ref and structs are by-val is also confusing from time to time to be honest.) When I started to write the C++ matrix library after I have written the Java matrix library to get to know what both languages can achive I have also had to start learning C++ as well. I bought a book and after 2-3 weeks I got the concepts and everything went as excepted and no things seemed to be hidden behind the scenes from me, the programmer which was in fact a nice experience when trying to optimize the code until it was equally fast as the java code or even faster. D seems to be more problematic when it comes to learning how to optimize the code. To summarize, I am still a beginner and learn this language as it has got cool, new and advanced features, it has not so many legacy issues (like C++), it unites object orientated, functional as well as imperative and paralell programming paradigms (still amazed by that fact!), runs native and isn't bound to any operating system or a huge runtime environment (java/c#). That's why I am learning D! =) I would love to see how much performance a D vetaran like you is able to grab out of my codes. Just tell me where I shall upload them and I will do so. Don't expect too much as I am still a beginner and as this project has just started. I didn't want to implement the whole functionality before I know how to do it with a good result. ;-) The matrix multiplication you have posted has some cool features in it. I especially like the pure one with all that functional stuff. :D @Nick Sabalausky: Don't be shocked at the bad performance of a beginner D programmer. At least I am not shocked yet that my D implementation isn't performing as well as the highly optimized C++11 implementation or the JIT-optimized Java implementation. In general one can not compare the results of a native compilation optimization which shall run on different hardwares and a JIT optimization which is able to pull out every single optimization routine because it knows the system and all its components to compile at. There is also the LDC2 and the GDC which should also improve the general performance quite a bit. However, what is true is, that it is (at least for me) harder to learn how to write efficient code for D than it was to learn it for C++. And keep in mind that my Java implementation (which runs nearly as fast as the C++ implementation) is written just to fit for performance. I have had to do dirty things (against the general Java mentality) in order to achive this performance. Besides that I couldn't implement a generic solution in Java which wasn't five to ten times slower than without generics as generics in Java are a runtime feature. So all in all Java is only good in performance if you don't use it as Java (purely object oriented etc.) ... but it works! :D @All of you: What I have done since the last time: I have changed my mind - matrix is now a value type. However, I wasn't sure about this step because I planned to implement dense and sparse matrices which could inherit from a basic matrix implementation in thus required to be classes. I have also removed that nasty "final struct" statement.^^ However, benchmarks stayed the same since the last post. Hopefully I haven't forgotten to say anything important ... Robin
Re: [video tutorial] hello world using dmd, rdmd, dub and vibe.d
On Saturday, 15 February 2014 at 13:28:24 UTC, simendsjo wrote: http://youtu.be/8TV9ZZteYEU The content wasn't planned, and English is not my native tongue. Hopefully it can still be useful for newbies. This is pretty much a response to a recent discussion on the lack of documentation/tutorials: http://forum.dlang.org/post/spdddifmaacihlcum...@forum.dlang.org PS: The many delays are X going black, forcing me to switch to a different terminal and back again. Nicely done. It's a bit quiet (I had to max out my volume and put on headphones to hear).
Re: Strange result with nextUp for reals
On 02/16/2014 01:42 PM, Andrej Mitrovic wrote: > - > import std.math; > import std.stdio; > > void main() > { > writefln("nextUp of %a is %a", 1.0, 1.0.nextUp()); That line uses doubles. > > real num = 1.0; > writefln("nextUp of %a is %a", num, num.nextUp()); That one uses reals. > } > - > > This prints: > > nextUp of 0x1p+0 is 0x1.1p+0 > nextUp of 0x1p+0 is 0x1.0002p+0 > > Any idea why the results are different? There is no difference. They are both 1. ;) The type of floating point literals is double. You are seeing the precision difference between doubles and reals. Ali
Re: Strange result with nextUp for reals
On 2/16/14, Andrej Mitrovic wrote: > Any idea why the results are different? Interestingly the literal versions end up calling nextUp which takes a double rather than a real. So nextUp(1.0) calls the double overload, nextUp(num) calls the real overload. Mystery solved.
Strange result with nextUp for reals
- import std.math; import std.stdio; void main() { writefln("nextUp of %a is %a", 1.0, 1.0.nextUp()); real num = 1.0; writefln("nextUp of %a is %a", num, num.nextUp()); } - This prints: nextUp of 0x1p+0 is 0x1.1p+0 nextUp of 0x1p+0 is 0x1.0002p+0 Any idea why the results are different?
Re: How to append to SortedRange?
On Sunday, 16 February 2014 at 12:51:10 UTC, bearophile wrote: If you have a limited number of small values (like 30 ints) using a sorted array is quite efficient, and keeps low the binary size and the pressure on the code L1 cache :-) Yup, I admit I over-generalized. But this sorted array should also be encapsulated into a convenient interface. At times, I really miss things like llvm::SmallVector/SmallSet/etc.
Re: std.bigint.BigInt and const modifier
Ruslan Mullakhmetov: i use v2.064.2. is it outdated ? It will be fixed in dmd 2.065. It's not yet out but you can use it already if you want to be on the "bleeding edge", it's currently in beta3 and most regressions are fixed, so it's probably better than using dmd 2.064.2. Bye, bearophile
Re: std.bigint.BigInt and const modifier
On Sunday, 16 February 2014 at 20:36:32 UTC, bearophile wrote: Ruslan Mullakhmetov: Is it a bug or design considerations? It was a const correctness bug, but it's already fixed in recent D compilers. Bye, bearophile recent D compilers. i use v2.064.2. is it outdated ?
Re: std.bigint.BigInt and const modifier
Ruslan Mullakhmetov: Is it a bug or design considerations? It was a const correctness bug, but it's already fixed in recent D compilers. Bye, bearophile
std.bigint.BigInt and const modifier
BigInt is a struct == ValueType, suppose i can assign const(BigInt) to BigInt const(BigInt)/const(BigInt) do not compile. Is it a bug or design considerations? test.d import std.stdio; import std.bigint; void foo(BigInt b) { std.stdio.writefln("foo(%s)", b); } void main() { const BigInt b = BigInt("445216415446"); auto b1 = b / b; foo(b); } $ dmd test.d /tmp/test.d(14): Error: 'b' is not of arithmetic type, it is a const(BigInt) /tmp/test.d(14): Error: 'b' is not of arithmetic type, it is a const(BigInt) /tmp/test.d(16): Error: function test.foo (BigInt b) is not callable using argument types (const(BigInt))
Re: Can opCmp return a 'long' instead of 'int'?
On 02/16/2014 04:40 PM, bearophile wrote: Timon Gehr: assert(S(1)S(int.max)); // passes. oops. A possible solution is to add to Phobos (unless it's already there) a variadic templated funcion cmpBuilder() that accepts an even number of arguments, that are seen as pairs. Usage example: struct Foo { int x, y; string s; int opCmp(in ref Foo r) { return cmpBuilder(x, r.x, y.abs, r.y.abs, s, r.s); } } Is this worth adding to Phobos? Bye, bearophile IMO no (lots of repetition), but forwarding opCmp is: struct Foo{ int x,y; string s; private @property order(){ return tuple(x, abs(y), s); } mixin OrderBy!order; } Furthermore, the language should be updated such that the built-in types are not special w.r.t. operators. Eg: 1.opBinary!"+"(2) 1.opCmp(2) should work. The following should be supported as well: struct Foo{ int x,y; string s; mixin OrderBy!(()=>tuple(x, abs(y), s)); } (Currently DMD bans function literals as members.)
Re: Can opCmp return a 'long' instead of 'int'?
Timon Gehr: assert(S(1)S(int.max)); // passes. oops. A possible solution is to add to Phobos (unless it's already there) a variadic templated funcion cmpBuilder() that accepts an even number of arguments, that are seen as pairs. Usage example: struct Foo { int x, y; string s; int opCmp(in ref Foo r) { return cmpBuilder(x, r.x, y.abs, r.y.abs, s, r.s); } } Is this worth adding to Phobos? Bye, bearophile
Re: Can opCmp return a 'long' instead of 'int'?
On 02/16/2014 04:13 PM, Timon Gehr wrote: On 02/16/2014 02:59 PM, Saurabh Das wrote: This does compile and run correctly, but are there any hidden assumptions or requirements on the return value of opCmp that I should be aware of? Is there any reason that doing this may be not be wise? No, this is fine. To be more precise: Returning long is fine. The subtraction trick does not work in general regardless of return type: import std.stdio; struct S{ int d; int opCmp(S r){ return d - r.d; } } void main(){ assert(S(1)S(int.max)); // passes. oops. }
Re: Can opCmp return a 'long' instead of 'int'?
On 02/16/2014 02:59 PM, Saurabh Das wrote: This does compile and run correctly, but are there any hidden assumptions or requirements on the return value of opCmp that I should be aware of? Is there any reason that doing this may be not be wise? No, this is fine.
Can opCmp return a 'long' instead of 'int'?
Hello, The call signature for opCmp in a struct is: struct S { int opCmp(ref const S s) const { ... } } int opCmp(ref const S s) const { return _val - s._val; } This works fine if _val is 'int'. However, if _val is 'long' then subtracting 2 longs may not result in an int - and therefore I would have to replace the subtraction above with 2 comparison operators. My question is: Can I rewrite opCmp to return a 'long', like: struct S { long opCmp(ref const S s) const { return _val - s.val; } } This does compile and run correctly, but are there any hidden assumptions or requirements on the return value of opCmp that I should be aware of? Is there any reason that doing this may be not be wise? Thanks, Saurabh
Re: How to append to SortedRange?
On Sunday, 16 February 2014 at 12:41:45 UTC, Artem Tarasov wrote: Use a container adequate for the task at hand, e.g. red-black tree. Very often a sorted array is the most adequate set implementation and we should have support for it in phobos.
Re: How to append to SortedRange?
Artem Tarasov: Use a container adequate for the task at hand, e.g. red-black tree. If you have a limited number of small values (like 30 ints) using a sorted array is quite efficient, and keeps low the binary size and the pressure on the code L1 cache :-) Arrays are awesome on modern CPUs. Bye, bearophile
Re: How to append to SortedRange?
Use a container adequate for the task at hand, e.g. red-black tree.
Re: DGUI
On Friday, 14 February 2014 at 20:29:50 UTC, Josh Phillips wrote: I recently downloaded and tried to use DGUI but I can't get it to work. Is there any tutorials on how to build an use it? Or can anyone help me and tel me a way on how I can get it to work? I know this isn't really related to DGUI but, I think this will be useful. I have some semi old static bindings for IUP [0]. Very stable api IUP [1] has (c library) and has good cross platform functionality. Little limited, but will definitely work in almost any cases. [0] https://bitbucket.org/alphaglosined/libglosined/src/85ab6b2135879848e7efd5f1dfa732f2cfb753f8/iup/?at=default [1] http://www.tecgraf.puc-rio.br/iup/
Re: Optimize my code =)
On Sunday, 16 February 2014 at 09:53:08 UTC, bearophile wrote: Be instead amazed of the sometimes near-C++ performance levels they have pushed Java to :-) Sorry, but I fail to be amazed by what huge piles of money thrown to a project for 10+ years can achieve. Those kind of achievements are boring :P And I think D is doing well in a benchmark like this, I guess with ldc2 you can go about as fast as C++. I'm sure that other "small benchmarks" on computational-intensive code achieved C++ speed in the past, so if we can't get C++-like speed here, it's either a problem with the code or some serious performance regression.
Re: How to get normal DLL method name
On 2/16/2014 4:20 PM, Denis Mezhov wrote: On Sunday, 16 February 2014 at 07:17:48 UTC, Denis Mezhov wrote: extern (Windows) void main(string[] args) { HMODULE h; I'm curious why you're declaring your main method as extern(Windows).
Re: how to round durations to most significant unit ? (5 secs, 889 ms, and 811 μs => 5 secs)
On Saturday, February 15, 2014 22:13:07 Steven Schveighoffer wrote: > On Fri, 14 Feb 2014 17:14:03 -0500, Jonathan M Davis > > wrote: > > On Thursday, February 13, 2014 23:37:13 Timothee Cour wrote: > >> Is there a function to do this? > >> If not and I/someone writes it, is there interest to add it to > >> std.datetime? > >> > >> Duration t = ...; > >> t.to!string => 5 secs, 889 ms, and 811 μs > >> t.round.to!string=> 5 secs > >> > >> t=...; > >> t.to!string => 889 ms, and 811 μs > >> t.round.to!string=> 889 secs > >> > >> Use case: shorter logs. > > > > There is no function for that, and no one's ever asked for anything like > > it, > > so I don't know how worthwhile it is to add. However, one possible > > implementation would be > > > > auto roundToLargest(Duration d) > > { > > > > foreach(units; TypeTuple!("weeks", "days", "hours", "minutes", > > "seconds", "msecs", "usecs")) > > > > { > > > > immutable value = d.total!units(); > > if(value != 0) > > > > return dur!units(value); > > > > } > > > > return d; > > > > } > > You are doing the calculation for every test. > > Better: > if(d >= dur!units(1)) > ... Yeah. That would be better. > Now, I think that the dur!units(1) should be statically determined, but if > not, I think you could make it statically determined via enum. It'll only be statically determined if it's in a context that requires it. Unless something has changed recently, the compiler never tries to do CTFE if it doesn't have to. So, you'd need to use an enum to force it. - Jonathan M Davis
Re: DGUI
On Saturday, 15 February 2014 at 16:26:28 UTC, Josh Phillips wrote: On Friday, 14 February 2014 at 20:36:42 UTC, Jeremy DeHaan wrote: Unless I am mistaken, it looks like the last time it was updated was in 2011. You'd probably have to update a bunch of stuff in the sources in order to get it to work properly. I would recommend gtkD as a gui library. I think you are mistaken. On bitbucket there are updates in october last year. Also I have heard lots of bad things about Gtk on windows. and on OS X it is segfaults often, so gtk is no go for non linux
Re: Optimize my code =)
francesco cattoglio: Well, actually, sometimes squeezing as much performance as you can from a test case can be a way to find out if a given language checks all the boxes and can be used to solve your problems. Unless you know a language well, you will fail squeezing that. This is true even in Python. I must admit I'm shocked by the poor performance of D here. But I also know one HAS to try LDC or GDC, or those numbers are really meaningless. Be instead amazed of the sometimes near-C++ performance levels they have pushed Java to :-) And I think D is doing well in a benchmark like this, I guess with ldc2 you can go about as fast as C++. Bye, bearophile
Re: Optimize my code =)
On Sunday, 16 February 2014 at 01:25:13 UTC, bearophile wrote: Many of the things you say and write are still wrong or confused. Usually the hard optimization of code is one the last things you learn about a language Well, actually, sometimes squeezing as much performance as you can from a test case can be a way to find out if a given language checks all the boxes and can be used to solve your problems. I must admit I'm shocked by the poor performance of D here. But I also know one HAS to try LDC or GDC, or those numbers are really meaningless.