September 19, 2022
On 19.09.22 01:01, Nicholas Wilson wrote:
> On Sunday, 18 September 2022 at 20:33:03 UTC, Walter Bright wrote:
>> Just like with cars where there is no substitute for horsepower, there's no substitute for extra precision.
> 
> Yes there is. Use an algorithm with better convergence properties or that is more numerically stable. If you have a problem with precision, you have other problems. You should fix the other problems first.
> ...

For my project the problem was specifically precision. I needed each pixel to have different coordinates even on really high zoom levels into the fractal. One nice thing about double-double was that if I centered the image directly on a number that is representable as a double, the maximum possible zoom level was increased massively. :)
September 18, 2022
On Sunday, 18 September 2022 at 23:18:06 UTC, Timon Gehr wrote:
> For my project the problem was specifically precision. I needed each pixel to have different coordinates even on really high zoom levels into the fractal. One nice thing about double-double was that if I centered the image directly on a number that is representable as a double, the maximum possible zoom level was increased massively. :)

Right and that is well beyond the capability of x86-fp80, which was my original point.
I think it makes sense to support real for PPC DoubleDouble, or IEEE quad. I don't think it does for x86-fp80.
September 19, 2022
On 19.09.22 01:51, Nicholas Wilson wrote:
> On Sunday, 18 September 2022 at 23:18:06 UTC, Timon Gehr wrote:
>> For my project the problem was specifically precision. I needed each pixel to have different coordinates even on really high zoom levels into the fractal. One nice thing about double-double was that if I centered the image directly on a number that is representable as a double, the maximum possible zoom level was increased massively. :)
> 
> Right and that is well beyond the capability of x86-fp80, which was my original point.
> I think it makes sense to support real for PPC DoubleDouble, or IEEE quad. I don't think it does for x86-fp80.

Well, I used adaptive precision, float/double/extended/double-double, whatever was needed for the current zoom level. Performance degraded at every step, while precision increased. There was a clear sweet spot where extended precision was the best option.

Of course, as I said, nowadays with AVX and beyond, as well as powerful GPUs, maybe the trade-offs would indeed be a bit different. The support for fp80 is really nice even just for legacy reasons though, it allows porting code that uses the x87 and get consistent results, and it allows easy benchmarking to show that some other solution actually beats it on the given hardware. Most backends have to support it anyway for C long double on e.g. linux.
September 20, 2022

On Saturday, 17 September 2022 at 20:08:26 UTC, Dennis wrote:

>

On Saturday, 17 September 2022 at 07:37:24 UTC, Ogi wrote:

>

Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.

I don't use non-ASCII identifiers, but you'll have to explain how e.g. using π instead of pi results in bugs or maintenance burden.

int μ = 42;
void main() {
    int µ = 69;
    assert(μ == 69);
}
September 20, 2022

On Tuesday, 20 September 2022 at 07:13:45 UTC, Ogi wrote:

>

On Saturday, 17 September 2022 at 20:08:26 UTC, Dennis wrote:

>

On Saturday, 17 September 2022 at 07:37:24 UTC, Ogi wrote:

>

Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.

I don't use non-ASCII identifiers, but you'll have to explain how e.g. using π instead of pi results in bugs or maintenance burden.

int μ = 42;
void main() {
    int µ = 69;
    assert(μ == 69);
}

How is that different from this?

int a = 42;
void main() {
    int a = 69;
    assert(a == 69);
}
September 20, 2022

On Tuesday, 20 September 2022 at 07:17:12 UTC, bauss wrote:

>

How is that different from this?

int a = 42;
void main() {
    int a = 69;
    assert(a == 69);
}

Did you try to copy-paste and run my example? It fails.

September 20, 2022

On Tuesday, 20 September 2022 at 07:44:37 UTC, Ogi wrote:

>

On Tuesday, 20 September 2022 at 07:17:12 UTC, bauss wrote:

>

How is that different from this?

int a = 42;
void main() {
    int a = 69;
    assert(a == 69);
}

Did you try to copy-paste and run my example? It fails.

Interesting, is there a bug filed for this?

September 20, 2022

On Tuesday, 20 September 2022 at 08:47:51 UTC, max haughton wrote:

>

On Tuesday, 20 September 2022 at 07:44:37 UTC, Ogi wrote:

>

On Tuesday, 20 September 2022 at 07:17:12 UTC, bauss wrote:

>

How is that different from this?

int a = 42;
void main() {
    int a = 69;
    assert(a == 69);
}

Did you try to copy-paste and run my example? It fails.

Interesting, is there a bug filed for this?

I'm guessing there are two different unicode glyphs here, mu and micro sign, they look very similar in this font

September 20, 2022

On Tuesday, 20 September 2022 at 08:47:51 UTC, max haughton wrote:

>

On Tuesday, 20 September 2022 at 07:44:37 UTC, Ogi wrote:

>

On Tuesday, 20 September 2022 at 07:17:12 UTC, bauss wrote:

>

How is that different from this?

int a = 42;
void main() {
    int a = 69;
    assert(a == 69);
}

Did you try to copy-paste and run my example? It fails.

Interesting, is there a bug filed for this?

No bug here, that’s two Unicode characters that look identical in many fonts: Greek Small Letter Mu (U+03BC) and Micro Sign (U+00B5).

It shouldn’t come as a surprise that some characters in Unicode look identical. But this case is more interesting because you don’t expect the Greek mu to have a twin brother.

September 20, 2022

On Saturday, 17 September 2022 at 07:37:24 UTC, Ogi wrote:

>

On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:

>

What features could be removed from D if it were up to you?

Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.

ǝpoɔ ǝɔɹnos uᴉ ʇxǝʇ ǝpoɔᴉun ɹoɟ sǝsn pooƃ ǝɹɐ ǝɹǝɥ┴

Seriously though, e.g. I was checking that characters fell in the range of alpha to omega, and used the actual unicode chars to do it.