Mathematical formulae in documentation / Mathjax
Hi, MathJax is a Javascript trick that can nicely typeset mathematical equations written in TeX, on-the-fly, in any HTML document. Enabling it is easily done by adding some in the , which I managed to do by overriding DDOC. However, if I have a piece of code like /// Return \(x^2\) int square(int x) dmd -D produces Return \(x\) Mathjax searches for \( ... \) in the page and then typeset as if it was written in TeX it but here it does not recognise and gives up. Editing DDOC_PARAM is not an option of course. Is there a way around? Thanks in advance!
Alignment of dynamic arrays
With "auto a = new double[1000]", is there any guarantee that a.ptr is aligned on a 16-byte boundary? Indeed I would like to use core.simd and this alignment is paramount for efficient loading from memory to SSE2 registers. On MacOS X and 64-bit Linux, it looks true for dmd. Looking at the implementation of arrays, it seems that it eventually depends on gc_malloc implementation but I could not find the code of that extern(C) function.
Re: Alignment of dynamic arrays
On Friday, 9 January 2015 at 00:23:47 UTC, bearophile wrote: Luc Bourhis: With "auto a = new double[1000]", is there any guarantee that a.ptr is aligned on a 16-byte boundary? Arrays are aligned on a 16-byte. Good news! But if you slice them, this alignment can be broken. Yes, of course. It's part of the game to prevent alignment-breaking slices. In past I suggested to put the alignment of an array in the D type system, as an optional extra information (if the alignment is not correct this causes compile-time errors in some cases and some run-time errors when the slicing bounds are runtime values). I like the general idea. But it would seem more natural to me if a slice returned an aligned array if possible, otherwise a misaligned one. Thanks for your thorough answer!
Re: Alignment of dynamic arrays
Keeping alignment when slicing is easy since it matches the size of the xmm registers: one has to partition the array by blocks of 2 doubles, 4 floats, etc. For AVX, the ideal alignment is on 32-byte boundaries but the really bad performance hit happens only when an unaligned access crosses a cacheline boundary. With SSE2, this concerns every single access.
[std.traits] Detect complex numbers
There is "isFloatingPointType!T" to find out whether type T is
one of the floating point types but I could not find anything
equivalent for complex numbers (cdouble, cfloat, creal) in Phobos
2.066 (which I installed with MacPorts for the record). Am I
missing something?
My goal was to detect types suitable as scalars in a linear
algebra context. I had to do it by hand:
enum bool supportedScalar(T) = is(ScalarTypeOf!T) &&
!isAggregateType!T;
private {
alias ScalarTypeList = TypeTuple!(float, double, real,
cfloat, cdouble, creal);
template ScalarTypeOf(T) {
static if (is(AliasThisTypeOf!T AT) && !is(AT[] == AT))
alias X = ScalarTypeOf!AT;
else
alias X = OriginalType!T;
static if (staticIndexOf!(Unqual!X, ScalarTypeList) >= 0)
alias ScalarTypeOf = X;
else
static assert(0, T.stringof~" is not a floating point
type");
}
}
Re: [std.traits] Detect complex numbers
I forgot to mention the obvious: I simply parroted the code in std.traits!
Re: [std.traits] Detect complex numbers
It doesn't answer your question as such, but you should take a look at: http://dlang.org/phobos/std_complex.html The planned obsolescence of cdouble and consort is another issue I wanted to raise actually but better do it in a dedicated thread.
[unittest] constness
Testing constness implementation is easy: const Foo a; a.non_const_method(); // <<< compilation fails but how would I catch that in a unittest?
Re: [unittest] constness
Thanks everybody for your help!
Re: [unittest] constness
On Monday, 19 January 2015 at 16:12:59 UTC, Luc Bourhis wrote: Thanks everybody for your help! Just one point I forgot to mention: the compiler chokes on static assert(!__traits(compiles, xc[0] = 1.0)); with: found '=' when expecting ')' following template argument list But static assert(!__traits(compiles, (xc[0] = 1.0))); works.
Documenting the use of mixing templates
ddox does not seem to pick up on "mixin MySuperDuperFeatures!()". So the only way at the moment seems to put a note in the class or the struct top documentation. Or am I missing something?
mixin template and overloading
Consider:
~ % dmd -v|head -n 1
DMD64 D Compiler v2.066-devel
~% cat mixin_template_pb.d
mixin template Foo(T) {
void bar() {}
}
struct FooBar {
mixin Foo!int;
void bar(ulong d)() {}
}
void check() {
FooBar o;
o.bar();
}
~% dmd -c mixin_template_pb.d
mixin_template_pb.d(12): Error: template
mixin_template_pb.FooBar.bar cannot deduce function from argument
types !()(), candidates are:
mixin_template_pb.d(7):mixin_template_pb.FooBar.bar(ulong
d)()
It looks like the compiler does not see the mixed-in "bar". If I
comment out the definition of "bar" in "FooBar", it compiles
fine. Is this to be considered a bug?
std.stdio and copying
If s is the instance of some struct S, "write(s)" will first copy
s. Not only this can be very inefficient but it won't even
compile if S features "@disable this(this)". The same goes for
all the other functions, including
format("s=%s", s)
One is then force to manually insert "s.toString()". Not quite a
good fit for the overhaul elegance of D imho. Wouldn't it be nice
to have those I/O functions support "const ref" for struct's? Or
am I missing something?
Re: Proposal : aggregated dlang git repository
On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote: Idea is to create an aggregated repository as part of D-Programming-Language organization which will include other existing ones as a submodules Imho, git subtree would be a better idea
Re: Proposal : aggregated dlang git repository
On Tuesday, 10 February 2015 at 22:12:41 UTC, Vladimir Panteleev wrote: On Tuesday, 10 February 2015 at 21:45:49 UTC, Luc Bourhis wrote: On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote: Idea is to create an aggregated repository as part of D-Programming-Language organization which will include other existing ones as a submodules Imho, git subtree would be a better idea I don't think so. What are the advantages? With subtree, one has a unified working directory from which one can straightforwardly make commits for each components. So if one makes a change on phobos that relies on a change on dmd, both changes can easily be made, committed and then pushed. With submodule, this is so cumbersome that it would requires some dedicated scripts. One big disadvantage that I see is that you can't create pull requests to the original repos from subtrees. You would create pull separate pull requests for the dmd repository, the phobos directory, etc. You mean you want to be able to do pull request from the master repository? Again, it seems to me this is not going to be intuitive at all with submodules.
math libraries
What is the difference between (i) core.math, (ii) std.math, (iii) core.stdc.math and (iv) core.stdc.tgmath? (iv) falls back on (iii) as far as I can tell. (i) and (ii) seem to emit the same old x87 instructions, like fsin e.g., even for double and float. What's the difference? So that leaves only core.stdc.math which may use fast SSE2 scalar instructions. It looks like it may do so, from a glance at the assembly with GDB. Could somebody shine some light?
Re: math libraries
Thank you very much Ilya for this comprehensive and clear answer.
Re: Vectorization examples
On Monday, 20 April 2015 at 11:15:48 UTC, finalpatch wrote: On Monday, 20 April 2015 at 11:01:28 UTC, Panke wrote: Aren't unaligned loads as fast as aligned loads on modern x86? No that's not true. On modern x86 processors using unaligned loading instructions on aligned data does not incur additional overhead, therefore you can always use unaligned load for everything, but loading unaligned data is still slower than aligned data. According to [1, section 7.13 and 8.13], the overhead was particularly bad for Core2 but this not a major issue either for Nehalem or SandyBridge anymore. Do you have data contradicting him? [1] Agner Fog, 3. The microarchitecture of Intel, AMD and VIA CPUs, Tech. report, Copenhagen University College of Engineering, February 2012. http://www.agner.org/optimize/
Re: C++ const expression are not that const after all
On Tuesday, 28 April 2015 at 02:48:09 UTC, H. S. Teoh wrote: On Tue, Apr 28, 2015 at 02:24:01AM +, deadalnix via Digitalmars-d wrote: http://b.atch.se/posts/non-constant-constant-expressions/ Whoa. This is gonna give me nightmares tonight... that is absolutely insane. The author of that blog seems to see his finding in a positive light actually. As it makes it possible to write more powerful template metaprograms!
