On Sunday, 9 September 2012 at 01:01:00 UTC, Timon Gehr wrote:
Works correctly in 32 bit mode. 64 bit code gen bug.
Hehe, glad it was helpful. :D
On Saturday, 8 September 2012 at 23:58:36 UTC, Walter Bright
wrote:
On 9/8/2012 3:56 PM, Mehrdad wrote:
I was pretty excited to figure out that a one-liner FFT is
possible in D!
creal[] dft(creal[] v) { return v.length > 1 ? (p =>
chain(map!(q
=> q[0] + q[1])(p), map!(q => q[0] -
q[1])(p)))(zi
On 9/8/2012 6:01 PM, Timon Gehr wrote:
> On 09/09/2012 02:57 AM, Timon Gehr wrote:
>> On 09/09/2012 12:56 AM, Mehrdad wrote:
>>> I was pretty excited to figure out that a one-liner FFT is
>>> possible in D!
>>> creal[] dft(creal[] v) { return v.length > 1 ? (p => chain(map!(q
>>> => q[0] + q[1])(p)
Walter Bright:
Awesome! Thanks for figuring this out. Any chance you can write
up a brief article on this, so we can post a link on reddit?
See also:
http://rosettacode.org/wiki/FFT#D
Bye,
bearophile
On 09/09/2012 02:57 AM, Timon Gehr wrote:
On 09/09/2012 12:56 AM, Mehrdad wrote:
I was pretty excited to figure out that a one-liner FFT is
possible in D!
creal[] dft(creal[] v) { return v.length > 1 ? (p => chain(map!(q
=> q[0] + q[1])(p), map!(q => q[0] -
q[1])(p)))(zip(dft(v.stride(2).array()
On 09/09/2012 12:56 AM, Mehrdad wrote:
I was pretty excited to figure out that a one-liner FFT is
possible in D!
creal[] dft(creal[] v) { return v.length > 1 ? (p => chain(map!(q
=> q[0] + q[1])(p), map!(q => q[0] -
q[1])(p)))(zip(dft(v.stride(2).array()), map!(p => p[1] *
expi(p[0] * -2 * PI / v
On 08-09-2012 22:54, Adam Wilson wrote:
On Sat, 08 Sep 2012 05:47:23 -0700, Alex Rønne Petersen
wrote:
On 08-09-2012 08:44, Benjamin Thaut wrote:
Am 08.09.2012 03:56, schrieb Tyler Jameson Little:
This issue on bugzilla hasn't been updated since July 2011, but
it's assigned to Sean Kelly:
ht
On 08-09-2012 22:04, Benjamin Thaut wrote:
Am 08.09.2012 14:47, schrieb Alex Rønne Petersen:
On 08-09-2012 08:44, Benjamin Thaut wrote:
Am 08.09.2012 03:56, schrieb Tyler Jameson Little:
This issue on bugzilla hasn't been updated since July 2011, but
it's assigned to Sean Kelly:
http://d.purem
On 9/8/2012 3:56 PM, Mehrdad wrote:
I was pretty excited to figure out that a one-liner FFT is
possible in D!
creal[] dft(creal[] v) { return v.length > 1 ? (p => chain(map!(q
=> q[0] + q[1])(p), map!(q => q[0] -
q[1])(p)))(zip(dft(v.stride(2).array()), map!(p => p[1] *
expi(p[0] * -2 * PI / v.le
I was pretty excited to figure out that a one-liner FFT is
possible in D!
creal[] dft(creal[] v) { return v.length > 1 ? (p => chain(map!(q
=> q[0] + q[1])(p), map!(q => q[0] -
q[1])(p)))(zip(dft(v.stride(2).array()), map!(p => p[1] *
expi(p[0] * -2 * PI / v.length))(zip(iota(v.length / 2),
dft(v.
Awesome, that's good news. I'd love to test it out, but I've
never built the D runtime (or Phobos for that matter) from
source. Are there any instructions or do I just do something like
make && sudo make install and it'll put itself in the right
places? FWIW, I'm running Linux with the standard DM
On Sat, 08 Sep 2012 05:47:23 -0700, Alex Rønne Petersen
wrote:
On 08-09-2012 08:44, Benjamin Thaut wrote:
Am 08.09.2012 03:56, schrieb Tyler Jameson Little:
This issue on bugzilla hasn't been updated since July 2011, but
it's assigned to Sean Kelly:
http://d.puremagic.com/issues/show_bug.cg
On Fri, 07 Sep 2012 13:34:02 +0200
"Kevin McTaggart" wrote:
> I suggest that the language require ref and out when
> calling functions, as C# requires.
That's one thing I've always thought C# got better than D. I'd love to
see D fixed in this regard, and I've argued in favor of it
some time ago
Am 08.09.2012 14:47, schrieb Alex Rønne Petersen:
On 08-09-2012 08:44, Benjamin Thaut wrote:
Am 08.09.2012 03:56, schrieb Tyler Jameson Little:
This issue on bugzilla hasn't been updated since July 2011, but
it's assigned to Sean Kelly:
http://d.puremagic.com/issues/show_bug.cgi?id=3463
I've f
Agh, sent a private mail again. I don't seem to be the only one though.
Has there been a thunderbird UI change?
On 09/08/2012 06:05 PM, Nick Treleaven wrote:
On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
Given:
void func (ref int[], int)
If ref/out were required at the call site, this des
On Saturday, 8 September 2012 at 12:10:26 UTC, kenji hara wrote:
2012/9/8 monarch_dodra :
[snip]
Still, I find it horrible to have to create a named "dummy"
variable just
when I simply want to pass a copy of my range.
Why you are afraid to declaring "dummy" variable?
formattedRead is a pars
On Saturday, September 08, 2012 17:05:25 Nick Treleaven wrote:
> As an option it would serve no practical purpose other than documentation.
It's worse than that. It's not even documentation that you can trust. If it
were optional, and ref were used in a function call, then you know that the
argu
On Friday, 7 September 2012 at 11:33:41 UTC, Kevin McTaggart
wrote:
I've been looking at migrating a reasonably large ship motion
library (tens of thousands of lines) from C# to D. I've become
quite enthusiastic about D, and most of my problems have been
relatively minor (e.g., inconsistent bu
On Saturday, 8 September 2012 at 12:10:26 UTC, kenji hara wrote:
2012/9/8 monarch_dodra :
[snip]
Still, I find it horrible to have to create a named "dummy"
variable just
when I simply want to pass a copy of my range.
Why you are afraid to declaring "dummy" variable?
formattedRead is a pars
Nick Treleaven:
IMO it's only functions whose arguments are all passed by ref
that don't really need annotation, and these are infrequent.
All others stand to benefit.
For arguments that use "const ref", "in ref", "immutable ref" I
think ref at the call site is not so important.
Bye,
bearo
On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
Given:
void func (ref int[], int)
If ref/out were required at the call site, this destroys UFCS.
int[] array;
array.func(0); // error, ref not specified by caller
For UFCS, ref should be implied. Also for 'const ref' parameters,
callsite ref
On Sep 8, 2012, at 5:47 AM, Alex Rønne Petersen wrote:
> On 08-09-2012 08:44, Benjamin Thaut wrote:
>> Am 08.09.2012 03:56, schrieb Tyler Jameson Little:
>>> This issue on bugzilla hasn't been updated since July 2011, but
>>> it's assigned to Sean Kelly:
>>> http://d.puremagic.com/issues/show_bug
Given:
void func (ref int[], int)
If ref/out were required at the call site, this destroys UFCS.
int[] array;
array.func(0); // error, ref not specified by caller
Or would one expect something like:
(ref array).func(0);
...put simply, I hope not.
This suggestion has come up a couple times b
On 08-09-2012 08:44, Benjamin Thaut wrote:
Am 08.09.2012 03:56, schrieb Tyler Jameson Little:
This issue on bugzilla hasn't been updated since July 2011, but
it's assigned to Sean Kelly:
http://d.puremagic.com/issues/show_bug.cgi?id=3463
I've found these threads concerning a precise GC:
http:/
2012/9/8 monarch_dodra :
[snip]
>
> Still, I find it horrible to have to create a named "dummy" variable just
> when I simply want to pass a copy of my range.
Why you are afraid to declaring "dummy" variable?
formattedRead is a parser, not an algorithm (as I said in the pull
request comment). Afte
On Thu, 2012-09-06 at 09:14 -0700, William Deegan wrote:
[…]
> Are you dropping any existing tools?
No. The dmd tool remains but has been revamped significantly. the gdc
and ldc tools are additions. Currently they are close to copies of each
other. More refactoring is needed to pull out common mat
I have commented to the pull.
I don't like adding convenient interfaces to std.format module.
https://github.com/D-Programming-Language/phobos/pull/777#issuecomment-8385551
Kenji Hara
2012/9/8 monarch_dodra :
> On Friday, 7 September 2012 at 15:34:12 UTC, monarch_dodra wrote:
>>
>> I think this
I happen to have been trying it yesterday and spent the better part of
the day fixing issues (especially with dynamic arrays). I just noticed
there are still problems with associative arrays, but I hope I will have
a pull request today.
Rainer
@dsimcha: Sorry about spamming your personal mail
28 matches
Mail list logo
