On Tuesday, 19 March 2013 at 02:09:06 UTC, timotheecour wrote:
I forgot unittest:
unittest{
assert(uniqStable([1,3,1,0,2] ==[1, 3, 0, 2] ));
}
of course, it needs template on less, etc.
Stealing reply from Bearophile:
http://forum.dlang.org/post/rnsrrlmtguuayfxcz...@forum.dlang.org
He uses
we need a std.algorithm.equalRecurse(T1,T2)(T1 a, T2 b) that
compares recursively a and b;
its behavior should be:
if opEqual is defined, call it
else, if its a range, call std.algorithm.equal (ie compare nb
elements, then each element for equality)
else, if it's a class/struct, make sure
On Tuesday, 19 March 2013 at 08:25:45 UTC, timotheecour wrote:
we need a std.algorithm.equalRecurse(T1,T2)(T1 a, T2 b) that
compares recursively a and b;
its behavior should be:
if opEqual is defined, call it
else, if its a range, call std.algorithm.equal (ie compare nb
elements, then each
On Tuesday, March 19, 2013 09:25:43 timotheecour wrote:
we need a std.algorithm.equalRecurse(T1,T2)(T1 a, T2 b) that
compares recursively a and b;
its behavior should be:
if opEqual is defined, call it
else, if its a range, call std.algorithm.equal (ie compare nb
elements, then each
On Tuesday, 19 March 2013 at 10:08:43 UTC, Jonathan M Davis wrote:
On Tuesday, March 19, 2013 09:25:43 timotheecour wrote:
we need a std.algorithm.equalRecurse(T1,T2)(T1 a, T2 b) that
compares recursively a and b;
its behavior should be:
if opEqual is defined, call it
else, if its a range,
Jonathan M Davis:
Going beyond a range of ranges is likely to be quite rare,
I agree.
and when it does happen, you can simply nest equal as many
times as you need.
A similar function seems useful for Phobos because it's
automatic, you don't need to tell it how many levels there are.
On Tuesday, 19 March 2013 at 11:46:14 UTC, monarch_dodra wrote:
On Tuesday, 19 March 2013 at 10:08:43 UTC, Jonathan M Davis
wrote:
On Tuesday, March 19, 2013 09:25:43 timotheecour wrote:
we need a std.algorithm.equalRecurse(T1,T2)(T1 a, T2 b) that
compares recursively a and b;
its behavior
On Tuesday, 19 March 2013 at 12:16:54 UTC, John Colvin wrote:
On Tuesday, 19 March 2013 at 11:46:14 UTC, monarch_dodra wrote:
On Tuesday, 19 March 2013 at 10:08:43 UTC, Jonathan M Davis
wrote:
On Tuesday, March 19, 2013 09:25:43 timotheecour wrote:
we need a
On Tuesday, 19 March 2013 at 12:16:54 UTC, John Colvin wrote:
(except if you feed it two integer literals, in which case the
compiler throws an out of memory error!).
Which is a legitimate error, seeing as -1 as a size_t is
size_t.max which meant replicate was requesting size_t.max *
On Tuesday, 19 March 2013 at 12:11:50 UTC, bearophile wrote:
Jonathan M Davis:
Going beyond a range of ranges is likely to be quite rare,
I agree.
and when it does happen, you can simply nest equal as many
times as you need.
A similar function seems useful for Phobos because it's
On Tuesday, 19 March 2013 at 12:34:04 UTC, monarch_dodra wrote:
On Tuesday, 19 March 2013 at 12:11:50 UTC, bearophile wrote:
Jonathan M Davis:
Going beyond a range of ranges is likely to be quite rare,
I agree.
and when it does happen, you can simply nest equal as many
times as you need.
On Tuesday, 19 March 2013 at 12:36:34 UTC, John Colvin wrote:
On Tuesday, 19 March 2013 at 12:34:04 UTC, monarch_dodra wrote:
On Tuesday, 19 March 2013 at 12:11:50 UTC, bearophile wrote:
Jonathan M Davis:
Going beyond a range of ranges is likely to be quite rare,
I agree.
and when it
Hi,
I'm interested in updating the existing OpenCL bindings
(https://github.com/Trass3r/cl4d) so they work with Derelict3,
but have never undertaken such a task.
I'm not sure where/how to begin.
Does anyone have any advice? :)
On Tuesday, 19 March 2013 at 14:55:10 UTC, Mike Parker wrote:
This is actually something I've wanted to get around to for a
long time. I'm busier than ever these days so I can't take it
on right now for sure. If you do decide to get busy on it, drop
by the Derelict forums[1] if you need any
On Tuesday, 19 March 2013 at 14:30:19 UTC, Lemonfiend wrote:
Hi,
I'm interested in updating the existing OpenCL bindings
(https://github.com/Trass3r/cl4d) so they work with Derelict3,
but have never undertaken such a task.
I'm not sure where/how to begin.
Does anyone have any advice? :)
On Tuesday, 19 March 2013 at 14:55:10 UTC, Mike Parker wrote:
On Tuesday, 19 March 2013 at 14:30:19 UTC, Lemonfiend wrote:
Hi,
I'm interested in updating the existing OpenCL bindings
(https://github.com/Trass3r/cl4d) so they work with Derelict3,
but have never undertaken such a task.
I'm
I was just looking at the Rosetta code for prime decomposition
and it seems bugged to me, wanted to make sure as you seem to be
the one coordinating these things:
http://rosettacode.org/wiki/Prime_decomposition#D
This will potentially return a 1 in the list of primes which is a
bug as 1
This used to work but now in 2.062 it causes ctfe error.
Any suggested workaround?
http://dpaste.dzfl.pl/f1a8c2f5
-
import std.datetime;
const(Date) DefaultDate = Date(1929, 10, 29);
void main() {
}
-
Compilation output:
On Tuesday, 19 March 2013 at 15:55:19 UTC, ixid wrote:
I was just looking at the Rosetta code for prime decomposition
and it seems bugged to me, wanted to make sure as you seem to
be the one coordinating these things:
http://rosettacode.org/wiki/Prime_decomposition#D
This will potentially
On Tuesday, 19 March 2013 at 16:35:22 UTC, Dan wrote:
This used to work but now in 2.062 it causes ctfe error.
Any suggested workaround?
This seems to work:
Date defDate() pure { return Date(1929, 10, 29); }
const(Date) DefaultDate = defDate();
Assuming you wanted to avoid a initializing
I think none of you got the point of equalRecurse, so let me
clarify.
equalRecurse should work on any type, not just inputRanges, see
my example in the OT with a struct containing an array: currently
std.algorithm.equal has isInputRange conditions on the arguments.
So, yes, it can go deep
On Tuesday, March 19, 2013 17:35:20 Dan wrote:
This used to work but now in 2.062 it causes ctfe error.
Any suggested workaround?
http://dpaste.dzfl.pl/f1a8c2f5
-
import std.datetime;
const(Date) DefaultDate = Date(1929, 10, 29);
void main() {
}
On Tuesday, 19 March 2013 at 17:04:01 UTC, cal wrote:
On Tuesday, 19 March 2013 at 16:35:22 UTC, Dan wrote:
This used to work but now in 2.062 it causes ctfe error.
Any suggested workaround?
This seems to work:
Or:
const(Date) DefaultDate = { return Date(1929,10,10); }();
although this is
ixid:
http://rosettacode.org/wiki/Prime_decomposition#D
This will potentially return a 1 in the list of primes which is
a bug as 1 isn't prime.
From Python code, hopefully more correct and much faster:
http://codepad.org/N4A7kxE1
Bye,
bearophile
On Tuesday, 19 March 2013 at 16:47:43 UTC, Andrea Fontana wrote:
On Tuesday, 19 March 2013 at 15:55:19 UTC, ixid wrote:
I was just looking at the Rosetta code for prime decomposition
and it seems bugged to me, wanted to make sure as you seem to
be the one coordinating these things:
On Tuesday, March 19, 2013 18:08:53 timotheecour wrote:
I think none of you got the point of equalRecurse, so let me
clarify.
equalRecurse should work on any type, not just inputRanges,
Which is fundamentally wrong. == and equal are two very different operations,
even if their intent may be
somewhere else, but I don't see a relevant package. Maybe a new
std.algorithm2 for non-ranges?
Also, the OT's firstDifference would go there too, and I have a
recursive (to specified level) toStringRecurse that would
belong there too.
Also, I'd add to that list copyRecurse and some more,
On Tuesday, 19 March 2013 at 17:18:01 UTC, bearophile wrote:
ixid:
http://rosettacode.org/wiki/Prime_decomposition#D
This will potentially return a 1 in the list of primes which
is a bug as 1 isn't prime.
From Python code, hopefully more correct and much faster:
On Tuesday, March 19, 2013 18:26:16 timotheecour wrote:
somewhere else, but I don't see a relevant package. Maybe a new
std.algorithm2 for non-ranges?
Also, the OT's firstDifference would go there too, and I have a
recursive (to specified level) toStringRecurse that would
belong there
On Tuesday, 19 March 2013 at 00:36:20 UTC, bearophile wrote:
rookie:
There were some interesting solutions for squares like:
https://groups.google.com/forum/#!msg/comp.lang.ruby/lf4Zd9fvuYY/tjT2q65mcFAJ
The Ruby code by Luke Blanshard converted to D:
http://codepad.org/gtWDdRoJ
Ruby is very
On Tuesday, 19 March 2013 at 00:36:20 UTC, bearophile wrote:
rookie:
There were some interesting solutions for squares like:
https://groups.google.com/forum/#!msg/comp.lang.ruby/lf4Zd9fvuYY/tjT2q65mcFAJ
The Ruby code by Luke Blanshard converted to D:
http://codepad.org/gtWDdRoJ
Ruby is very
On Tue, Mar 19, 2013 at 01:48:43PM -0400, Jonathan M Davis wrote:
On Tuesday, March 19, 2013 18:26:16 timotheecour wrote:
somewhere else, but I don't see a relevant package. Maybe a new
std.algorithm2 for non-ranges?
Also, the OT's firstDifference would go there too, and I have a
And how do you even have the concept of recursion without some
sort of range or container to recursively iterate through?
It's not hard: I've done it for a serialization library I've been
working on (which has some advantages over std.orange, such as
serializing to json/binary etc. more on
On Tuesday, 19 March 2013 at 08:25:45 UTC, timotheecour wrote:
we need a std.algorithm.equalRecurse(T1,T2)(T1 a, T2 b) that
compares recursively a and b;
its behavior should be:
if opEqual is defined, call it
The problem is, Object defines opEqual as bool opEquals(Object
o){return this is
Small changes on your version:
http://codepad.org/E9KHKvAi
It's now on Rosettacode. I have added more changes to make it
able to deal with immutable input.
Bye,
bearophile
On Tuesday, March 19, 2013 11:12:38 H. S. Teoh wrote:
On Tue, Mar 19, 2013 at 01:48:43PM -0400, Jonathan M Davis wrote:
On Tuesday, March 19, 2013 18:26:16 timotheecour wrote:
somewhere else, but I don't see a relevant package. Maybe a new
std.algorithm2 for non-ranges?
Also,
On Tuesday, 19 March 2013 at 17:08:54 UTC, timotheecour wrote:
I think none of you got the point of equalRecurse, so let me
clarify.
I think I understand what you are after and I like the idea. I've
got a few:
-typesDeepEqual
-typesDeepCmp
-deepHash
Have a look at:
On Tuesday, March 19, 2013 19:13:14 timotheecour wrote:
And how do you even have the concept of recursion without some
sort of range or container to recursively iterate through?
It's not hard: I've done it for a serialization library I've been
working on (which has some advantages over
I think I understand what you are after and I like the idea.
I've got a few:
-typesDeepEqual
-typesDeepCmp
-deepHash
approxEqualRecurse could also be useful for numerical
applications (same as equalRecurse, except uses approxEqual for
floating point comparisons)
That's opEquals' job. It deals with recursive comparisons like
you're describing here just fine.
Except the functionality is very different, as opEquals is blind
to range semantics. I want equalRecurse to work as follows:
struct A{ int[]b=[1]; }
void main(){
auto a1=A();
On Tuesday, March 19, 2013 21:13:21 timotheecour wrote:
That's opEquals' job. It deals with recursive comparisons like
you're describing here just fine.
Except the functionality is very different, as opEquals is blind
to range semantics.
opEquals defines equality however it chooses to
On Tuesday, March 19, 2013 20:36:09 Dan wrote:
On Tuesday, 19 March 2013 at 17:08:54 UTC, timotheecour wrote:
I think none of you got the point of equalRecurse, so let me
clarify.
I think I understand what you are after and I like the idea. I've
got a few:
-typesDeepEqual
On Tuesday, 19 March 2013 at 20:28:09 UTC, Jonathan M Davis wrote:
Those are what opEquals, opCmp, and toHash are for. It might
make sense to
define mixins which implement them for you (dealing with
whatever recursive
semantics are necessary), but using external functions for
those just
On Tuesday, March 19, 2013 21:50:55 Dan wrote:
On Tuesday, 19 March 2013 at 20:28:09 UTC, Jonathan M Davis wrote:
The language and standard library are designed around them being
part of the types themselves. Stuff like AAs won't work if
those functions
aren't defined on the types
On Tuesday, 19 March 2013 at 21:11:12 UTC, Jonathan M Davis wrote:
Lots of stuff uses ==, toHash, etc. That's the way the language
is designed.
Agreed
Defining your types without defining those properly just isn't
going to work for
a _lot_ of stuff. Creating an external function to compare
On Tuesday, 19 March 2013 at 22:06:31 UTC, Martin wrote:
http://pastebin.com/8M2EuyfT
I'm fairly new to D, but would this work? Obviously I would
need to make my own kind of associative array that uses manual
memory management to completely circumvent the GC, but besides
that?
Have you
I was inspired by the Unmanaged framework, and the usage would
be something like:
class MyClass
{
private:
int _a;
int _b;
public:
this(int a, int b)
{
_a = a;
_b = b;
}
}
class OtherClass
{
private:
RefCountedObj!MyClass _myClassInstance;
public:
On Tuesday, 19 March 2013 at 22:09:22 UTC, Brad Anderson wrote:
On Tuesday, 19 March 2013 at 22:06:31 UTC, Martin wrote:
http://pastebin.com/8M2EuyfT
I'm fairly new to D, but would this work? Obviously I would
need to make my own kind of associative array that uses manual
memory management
On Tuesday, March 19, 2013 22:43:10 Dan wrote:
The above works with the built-in AAs.
Please offer an example.
It works because the outer type defines toHash. Without toHash, the built-in
AAs won't work. If you're dealing with member variables which don't have
toHash, then doing something
Can we replace phobos' and tools' Makefile with D with following
advantages:
* no more 3 distinct files (posix.mak,win32.mak,win64.mak),
instead use version() to maximize code reuse.
* less verbosity / bugs / forward compatibility issues eg when a
module is added/renamed: eg could take
On Tuesday, 19 March 2013 at 23:13:19 UTC, Jonathan M Davis wrote:
On Tuesday, March 19, 2013 22:43:10 Dan wrote:
The above works with the built-in AAs.
Please offer an example.
It works because the outer type defines toHash. Without toHash,
the built-in
AAs won't work. If you're dealing
On Wednesday, March 20, 2013 01:17:13 Dan wrote:
This is true, but then my code is by definition not standard.
However, theoretically, the language writers could. For example,
any '==' could be lowered to a 'standard' function, probably
better named 'intancesDeepEqual(a,b)' and that function
On Wednesday, March 20, 2013 00:18:41 timotheecour wrote:
Can we replace phobos' and tools' Makefile with D with following
advantages:
* no more 3 distinct files (posix.mak,win32.mak,win64.mak),
instead use version() to maximize code reuse.
* less verbosity / bugs / forward compatibility
On Wed, Mar 20, 2013 at 01:17:13AM +0100, Dan wrote:
On Tuesday, 19 March 2013 at 23:13:19 UTC, Jonathan M Davis wrote:
[...]
But the main problem that I'm pointing out is that you can't define
your own, non-standard functions for equality or hashing or whatever
and expect your types to play
On Tuesday, March 19, 2013 18:20:35 H. S. Teoh wrote:
I like this idea. By default, provide something that recursively
compares struct/class members, array elements, etc.. But if at any level
an opEquals is defined, then that is used instead. This maximizes
convenience for those cases where
On Wednesday, 20 March 2013 at 02:03:31 UTC, Jonathan M Davis
wrote:
We already get this. That's what == does by default. It's just
that it uses ==
on each member, so if == doesn't work for a particular member
variable and the
semantics you want for == on the type it's in, you need to
override
On Wednesday, March 20, 2013 03:48:38 Dan wrote:
On Wednesday, 20 March 2013 at 02:03:31 UTC, Jonathan M Davis
wrote:
We already get this. That's what == does by default. It's just
that it uses ==
on each member, so if == doesn't work for a particular member
variable and the
On Wednesday, March 20, 2013 01:17:13 Dan wrote:
This is true, but then my code is by definition not standard.
However, theoretically, the language writers could. For example,
any '==' could be lowered to a 'standard' function, probably
better named 'intancesDeepEqual(a,b)' and that function
On Wednesday, 20 March 2013 at 02:54:23 UTC, Jonathan M Davis
wrote:
On Wednesday, March 20, 2013 03:48:38 Dan wrote:
On Wednesday, 20 March 2013 at 02:03:31 UTC, Jonathan M Davis
wrote:
We already get this. That's what == does by default. It's
just
that it uses ==
on each member, so if
59 matches
Mail list logo
