Re: OT On NumPy [was beginner's pyd question - exporting structs to python]
On Mon, 2014-08-18 at 23:12 +, Laeeth Isharc via Digitalmars-d-learn wrote: […] For me, NumPy has some serious problems despite being the accepted norm for computational work. If not too offtopic, do you have a link describing, or would you briefly summarize these problems? I am intrigued. And what would you suggest in its place? Fortran? […] I have no benchmark experiment data as proof yet, just anecdotal evidence forming an hypothesis, but it seems that the underlying data parallelism model of NumPy has some serious overhead problems: speed-ups are not as high as they should be, and scaling is not as good as it should be. The finance people using Python in London, and indeed the general data analysis using Python folk (cf. PyData meetings around the world) all take NumPy as a given, and that it works well enough for them. I guess those for whom NumPy is not good enough are using Cython, C++ or Fortran (or even C) for the computationally intensive stuff. Or more likely they already had the native code in place and so are not using NumPy other than for data visualization and replacement of Matlab. I think Numba is a disruptive technology here. However the danger is that the opaque type approach of NumPy (which is good) is forgotten as a good abstraction in the face of Numba speeds, with people reverting to explicit rather than implicit iteration just because things go faster. Or maybe this won't happen because all the needed computationally intensive libraries already exists. I guess the PyData meetings are the place where al this will be played out. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: beginner's pyd question - exporting structs to python
On Tue, 2014-08-19 at 00:53 +, bachmeier via Digitalmars-d-learn wrote: […] I'm not sure which computational work he is referring to, but for statistical analysis, R dominates by a wide margin (although statistical analysis done in Silicon Valley, the type you read about on Hacker News, is often done using Python). My own :-) I think Python is not making inroads in the world-wide R community, but it is in the Matlab and Mathematica ones. Whether Julia acts as a disruptive technology here we will see. I write functions in D, compile as a shared library, and call from R. The more statically typed code I write, the more I like it. I'm finishing up a blog post describing my usage. This model also works for Python and D and does not require PyD (*). The issue here is that D, like C++, can provide shared objects (aka DLLs) with C linkage entry points and so Python extensions can be created. (*) Though arguably it is easier using PyD. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: goto skips declaration of variable
On Monday, 18 August 2014 at 17:47:21 UTC, ketmar via Digitalmars-d-learn wrote: On Mon, 18 Aug 2014 13:51:12 + nrgyzer via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: When I try to compile this sample application I'm getting the following error: sample.d(7): Error: goto skips declaration of variable sample.main.__ctmp1344 at sample.d(9) it's compiler bug i believe. but why do you need gotos at the first place? i'm not saying that you must avoid gotos at all costs!, but D has some nice features like scope(exit), scope(success), scope(failure) and nested functions, which can render gotos unnecessary in many cases (and make code cleaner). I know, gotos are having a negative connotation. Sure, I can also use nested functions, but in my opinion it results in dirty and complex code. It's totally overkilled compared to a simple if and goto-instruction. The same regards the scoping... it's simply to much overhead.
Re: goto skips declaration of variable
On Tue, 19 Aug 2014 08:04:54 + nrgyzer via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: goto-instruction. The same regards the scoping... it's simply to much overhead. it's a matter of taste, i think. i myself find 'scope(exit)' excellent, 'cause i'm always keep forgeting to free some resources / restore some state in EXIT: part. ;-) but i'm not saying that everyone should avoid gotos, and this is definitely the bug in compiler that should be fixed. signature.asc Description: PGP signature
Re: goto skips declaration of variable
nrgyzer: Sure, I can also use nested functions, but in my opinion it results in dirty and complex code. It's totally overkilled compared to a simple if and goto-instruction. Often nested functions are less complex, more clean and simpler code compared to using gotos. I suggest to start using nested functions and see how they work out. Bye, bearophile
Re: String Prefix Predicate
On Monday, 18 August 2014 at 20:50:55 UTC, Nordlöw wrote: On Monday, 18 August 2014 at 12:42:25 UTC, monarch_dodra wrote: If you are using a string, the only thing helpful in there is `byCodeunit`. The rest is only useful if you have actual ranges. Actual ranges of...characters and strings? Could you gives some examples? I'm curious. You could define your own range of chars, for example, a rope. Or, you want to store your string in a deterministic container (Array!char). These would produce individual code units, but you'd still need them to be interpreted your range as a sequence of code points. This is where `byDchar` would come in handy. There is a fair bit of discrepancy between a char[], and a range where `ElementType!R` is `char`, which is quite unfortunate. There have been talks of killing auto-decode, in which case, a range of chars would have the same behavior as a char[].
Re: String Prefix Predicate
On Tuesday, 19 August 2014 at 08:23:53 UTC, monarch_dodra wrote: You could define your own range of chars, for example, a rope. Or, you want to store your string in a deterministic container (Array!char). These would produce individual code units, but you'd still need them to be interpreted your range as a sequence of code points. This is where `byDchar` would come in handy. There is a fair bit of discrepancy between a char[], and a range where `ElementType!R` is `char`, which is quite unfortunate. There have been talks of killing auto-decode, in which case, a range of chars would have the same behavior as a char[]. Ok, thanks again.
Re: In the new D release why use free functions instead of properties?
On Tuesday, 19 August 2014 at 00:55:24 UTC, Idan Arye wrote:
On Tuesday, 19 August 2014 at 00:54:25 UTC, Idan Arye wrote:
On Monday, 18 August 2014 at 21:17:11 UTC, Jonathan M Davis
wrote:
On Monday, 18 August 2014 at 21:02:09 UTC, Gary Willoughby
wrote:
In the new D release there have been some changes regarding
built-in types.
http://dlang.org/changelog.html?2.066#array_and_aa_changes
I would like to learn why this has been done like this and
why it is desired to be free functions rather than
properties?
Probably because they never should have been properties in
the first place. Properties are supposed to emulate
variables, whereas something like dup is clearly an action.
So, it's clearly not supposed to be a property. However,
because D doesn't require parens on a function with no
arguments, you can still call it without parens. Some of the
changes probably also help with cleaning up the AA internals,
which is sorely needed.
- Jonathan M Davis
Also std.algorithm's heavy usage of passing delegates as
template arguments makes it more elegant to use free functions:
import std.algorithm;
import std.compiler;
void main()
{
int[][] arr=[[1,2],[3,4]];
static if (version_minor=65){
auto arr2=arr.map!(a = a.dup)();
}else{
auto arr2=arr.map!(a.dup)();
}
arr2[0][0]=9;
assert(arr2[0][0] == 1);
}
Sorry - that should have been:
import std.algorithm;
import std.compiler;
void main()
{
int[][] arr=[[1,2],[3,4]];
static if (version_minor=65){
auto arr2=arr.map!(a = a.dup)();
}else{
auto arr2=arr.map!(dup)();
}
arr2[0][0]=9;
assert(arr2[0][0] == 1);
}
This kind of makes sense for `dup` because that could be applied
across types but what about rehash, byKey, byValue, keys, values,
etc of AA's? Surely these will only be used by AA's? Is this more
about speed optimisation?
Re: In the new D release why use free functions instead of properties?
On Tuesday, 19 August 2014 at 16:04:15 UTC, Gary Willoughby wrote: This kind of makes sense for `dup` because that could be applied across types but what about rehash, byKey, byValue, keys, values, etc of AA's? Surely these will only be used by AA's? Is this more about speed optimisation? I am pretty sure this is just one of steps for librarization of AA implementation and minimizing special handling for it in compiler. Not that valuable on its own, just one of many small steps towards hard goal.
Re: In the new D release why use free functions instead of properties?
On Monday, 18 August 2014 at 21:17:11 UTC, Jonathan M Davis wrote: On Monday, 18 August 2014 at 21:02:09 UTC, Gary Willoughby wrote: In the new D release there have been some changes regarding built-in types. http://dlang.org/changelog.html?2.066#array_and_aa_changes I would like to learn why this has been done like this and why it is desired to be free functions rather than properties? Probably because they never should have been properties in the first place. Properties are supposed to emulate variables, whereas something like dup is clearly an action. So, it's clearly not supposed to be a property. However, because D doesn't require parens on a function with no arguments, you can still call it without parens. Some of the changes probably also help with cleaning up the AA internals, which is sorely needed. - Jonathan M Davis Actually, the new free functions *are* properties. All that you just declared is valid, but we never got around to doing it. Walter (If I remember correctly) was opposed. So right now, even if dup is a free function, myArray.dup() is still invalid. :(
Re: goto skips declaration of variable
On 08/19/2014 01:04 AM, nrgyzer wrote: On Monday, 18 August 2014 at 17:47:21 UTC, ketmar via but why do you need gotos at the first place? i'm not saying that you must avoid gotos at all costs!, but D has some nice features like scope(exit), scope(success), scope(failure) and nested functions, which can render gotos unnecessary in many cases (and make code cleaner). I know, gotos are having a negative connotation. Sure, I can also use nested functions, but in my opinion it results in dirty and complex code. It's totally overkilled compared to a simple if and goto-instruction. The same regards the scoping... it's simply to much overhead. However, goto is not a substitute for scope(exit) and friends or similar D features because goto may not be executed if an exception is thrown. Ali
shared and idup
shared int[] foo;
auto bar() {
foo ~= 42;
return foo.idup;
}
Error: cannot implicitly convert element type shared(int) to
immutable in foo.idup
Is this not correct? If I instead dup'd an array of ints (or some
other non-reference elements) and cast to immutable, would I be
in danger of undefined behavior?
iterate traits ?
Hi,
i'm trying to create a dynamic vertex format for opengl, defined
at compiletime by a struct
e.g. struct Vertex {float[3] position, float[3] normal}
i can get the name of all members with this:
auto b = [ __traits(allMembers, VertexType) ];
but i can't iterate them at compiletime because there is no
static foreach?
foreach(e; b) {
alias tt = typeof(__traits(getMember, VertexType, e)); // not
working
writeln(tt.sizeof);
}
since i need to setup vertexpointers for opengl at runtime my
next question? - is it possible to evaluate the traits also at
runtime? but i'd also like to know how i can iterate them at
compiletime
thx in advance :)
Re: iterate traits ?
On Tue, 19 Aug 2014 18:15:33 +, ddos wrote: since i need to setup vertexpointers for opengl at runtime my next question? - is it possible to evaluate the traits also at runtime? but i'd also like to know how i can iterate them at compiletime thx in advance :) Take a look at this example: http://dpaste.dzfl.pl/2fdea78a49b6 A foreach becomes compile-time whenever the aggregate is a purely compile- time construct such as a tuple.
Re: iterate traits ?
On Tuesday, 19 August 2014 at 18:25:24 UTC, Justin Whear wrote: On Tue, 19 Aug 2014 18:15:33 +, ddos wrote: since i need to setup vertexpointers for opengl at runtime my next question? - is it possible to evaluate the traits also at runtime? but i'd also like to know how i can iterate them at compiletime thx in advance :) Take a look at this example: http://dpaste.dzfl.pl/2fdea78a49b6 A foreach becomes compile-time whenever the aggregate is a purely compile- time construct such as a tuple. thank you!
Re: iterate traits ?
A foreach becomes compile-time whenever the aggregate is a purely compile-
time construct such as a tuple.
Yeah, I think you transformed it into a runtime array by using [ ...
]. Tuples with compatible types can be 'downgraded' to arrays that
way. But there is no need to: tuples are iterable, indexable and
slice-able in D.
import std.stdio;
struct Vertex {float[3] position; float[3] normal;}
void main() {
foreach(e; __traits(allMembers, Vertex)) {
alias tt = typeof(__traits(getMember, Vertex, e)); // worksforme
writeln(tt.sizeof);
}
}
Re: shared and idup
On Tuesday, 19 August 2014 at 17:56:31 UTC, Low Functioning wrote:
shared int[] foo;
auto bar() {
foo ~= 42;
return foo.idup;
}
Error: cannot implicitly convert element type shared(int) to
immutable in foo.idup
Is this not correct? If I instead dup'd an array of ints (or
some other non-reference elements) and cast to immutable, would
I be in danger of undefined behavior?
Try upgrading you compiler to the just released 2.067, it works
for me with that version.
Re: In the new D release why use free functions instead of properties?
On Tuesday, 19 August 2014 at 16:28:54 UTC, monarch_dodra wrote: Actually, the new free functions *are* properties. All that you just declared is valid, but we never got around to doing it. Walter (If I remember correctly) was opposed. So right now, even if dup is a free function, myArray.dup() is still invalid. Yuck. It shouldn't even be a breaking change to make them functions unless code is specifically testing dup vs dup(). We really should make that change IMHO. - Jonathan M Davis
Re: shared and idup
On Tuesday, 19 August 2014 at 19:00:49 UTC, Marc Schütz wrote:
On Tuesday, 19 August 2014 at 17:56:31 UTC, Low Functioning
wrote:
shared int[] foo;
auto bar() {
foo ~= 42;
return foo.idup;
}
Error: cannot implicitly convert element type shared(int) to
immutable in foo.idup
Is this not correct? If I instead dup'd an array of ints (or
some other non-reference elements) and cast to immutable,
would I be in danger of undefined behavior?
Try upgrading you compiler to the just released 2.067, it works
for me with that version.
Actually, it's 2.066, but regardless, dup and idup were turned
into free functions, so that will probably fix some bugs where
they didn't work with shared or weren't nothrow or somesuch (or
if it doesn't, it puts them one step closer to it).
- Jonathan M Davis
Re: goto skips declaration of variable
On Monday, 18 August 2014 at 13:51:14 UTC, nrgyzer wrote:
Hi all,
I've the following code snipped:
import std.bigint;
void main(string[] args)
{
BigInt i = 12345;
if (args.length 1)
{
goto Exit;
}
i = BigInt(67890);
Exit:
return;
}
For what it's worth, whenever you have goto-end style code,
place all your code in a proper block, in such a way that all
your variable declarations are in that block, and all your gotos
break out of this block. This way, a goto will *never* cross a
declaration, so coding is easy. The only variables you place at
the top or the ones that could need cleanup.
void main(string[] args)
{
//Declarations that need cleanup:
void* p;
//Code
{
BigInt i = 12345; //Local variable
if (args.length 1)
{
goto Exit; //Breaks out of block
}
i = BigInt(67890);
BigInt j = 54321; //Local variable
}
//End
Exit:
CleanUp(p);
return;
}
Re: request assistance resolving curl related linker error
On Tuesday, 19 August 2014 at 03:56:38 UTC, ketmar via Digitalmars-d-learn wrote: On Tue, 19 Aug 2014 03:37:23 + Vladimir Panteleev via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: And Windows. Since, apparently, pragma(lib) is only supported by COFF and OMF. nope, GNU/Linux DMD supports it too (at least 32-bit version). Hmm, I believe I've been lied to, then!
Auto attributes for functions
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
away. It would be great if this could be achieved like so:
auto function() @auto
{}
instead of manually writing:
auto function() pure @safe nothrow @nogc const
{}
cheers,
uri
Re: Auto attributes for functions
On Wednesday, 20 August 2014 at 01:38:53 UTC, uri wrote:
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
away. It would be great if this could be achieved like so:
auto function() @auto
{}
instead of manually writing:
auto function() pure @safe nothrow @nogc const
{}
cheers,
uri
Only if they're template functions.
//inferred as @safe pure nothrow @nogc
auto fun()() {}
//Compiler treats this is @system impure throwing @gc
//(if the latter three existed)
auto fun() {}
I think Andrei suggested in the past that functions with a return
type of auto have attributes inferred for them as well, but
some people were against it, and nobody's tried implementing it
yet.
Re: Question about operations on class/struct properties
I have another similar example illustrating this problem at
semantic level.
import std.stdio, std.typecons;
struct Test
{
//ref
Nullable!int prop() @property
{
return _value;
}
private Nullable!int _value = 10;
}
void main()
{
auto test = Test();
//This looks like I want to modify property with *nullify*,
//but instead it creates variable that will never be used and
modify it
test.prop.nullify();
assert( test.prop.isNull ); //This fails
}
So when using with value types I should always look if property
is *ref* or not and it's not very good.
I have another question. How could I implement in this example if
I uncomment it to call some function after modifying property? Do
I need some sort of class wrapper for property or is there some
other ideas?
What I expect:
void main()
{
auto test = Test();
test.prop.nullify();
//Callback called after this operation
test.prop = 15;
//Callback called after this operation too
}
Callback is simple method of Test like:
void callback(Nullable!int value)
{
if( value.isNull )
//Do smth
else if( value = 0 )
//Do smth else
else //Just assign to internal field
_value = value;
}
So I think it is possible to do this with some class wrapper
around Nullable!int that should implement al of it's methods or
for example dispatching calls to them via opDispacth. But this
approach looks slightly complicated. What if I have complicated
interface (for example std.datetime.Date as such property) so I
need to reimplement or dispatch a lot of methods.
Could you advise another more simple approach to this problem?
