On 12/05/2011 01:37 PM, Don wrote:
> On 05.12.2011 18:36, bearophile wrote:
>> Manu:
>>
>>> Also, contrary to his claim, I find that wrapping is usually what I
>>> DO want in this case..
>>> It's super rare that I write any code that pushes the limits of an int
>>> (unless we're talking 8-16 bit, see my range+saturation comment before),
>>> and when I do write code that pushes the range of an int, I can't
>>> think of
>>> a time when I've not wanted to wrap as expected.
>>
>> The code you usually write seems rather unusual. I have kind of the
>> opposite situations.
>>
>> But first of all, "trapping" ints are needed to avoid bugs in normal
>> code. Some bugs are shown here:
>> http://embed.cs.utah.edu/ioc/
>
> Those mostly aren't relevant for D. C has many cases of undefined
> behaviour because it doesn't require twos-complement arithmetic. D
> doesn't have that problem.
> We still need to tidy up the semantics of << and >> to remove undefined
> behaviour. But it's hard to do much more than that.
>
> The "overflow12.pdf" paper on that site shows statistics that overflow
> is very often intentional. It's strong evidence that you *cannot* make
> signed overflow an error. Even if you could do it with zero complexity
> and zero performance impact, it would be wrong.

What is needed is a type that has *defined* overflow characteristics (IIRC unsigned does but there might be value in having a signed one as well) and, maybe, another one that traps. Undefined overflow is a bugs waiting to happen:

// In C
for (short i = 1; i > 0; i++);

Under GCC, no optimisation finishes in ms. With -O9, it's an endless loop.

On 12/5/11 9:57 PM, Walter Bright wrote:
> http://www.cs.washington.edu/education/courses/cse590p/590k_02au/print-fp.pdf
>
> http://www.cs.washington.edu/education/courses/cse590p/590k_02au/read-fp.pdf

In fact there's more recent work on that, see http://goo.gl/H6VZD. It's been on reddit, too: http://goo.gl/teyDy. That work is implemented in Google's double-conversion library: http://goo.gl/RU5g4.

I wanted for a long time to have double->string and string->double routines in native D that are CTFE-able. Those would make it possible to generate function tables and other awesome applications. If someone could find the time to e.g. take dmc's floating point formatting/parsing routines and translate them to D, that would be great.


Andrei

On 12/5/11 10:15 PM, Walter Bright wrote:
> On 12/5/2011 8:10 PM, bearophile wrote:
>> This is not about integers but yeah, I'd like the better str<-> float
>> conversions of Python in D too.
>
> Do you have any test data that they actually are better in Python (apart
> from just being better specified)?

I can tell Google's double-conversion routines (http://goo.gl/RU5g4) are faster than sprintf/sscanf, in addition to being better specified. We use them at Facebook.

Andrei

On 06.12.2011 05:15, Walter Bright wrote:
> On 12/5/2011 8:10 PM, bearophile wrote:
>> This is not about integers but yeah, I'd like the better str<-> float
>> conversions of Python in D too.
>
> Do you have any test data that they actually are better in Python (apart
> from just being better specified)?

Bug 5229 is an example.

I have five papers on this topic. Most recent is the excellent:
Florian Loitsch, "Printing FP numbers quickly and accurately with integers" (2010)

On 12/5/2011 8:48 PM, Andrei Alexandrescu wrote:
> On 12/5/11 10:15 PM, Walter Bright wrote:
>> On 12/5/2011 8:10 PM, bearophile wrote:
>>> This is not about integers but yeah, I'd like the better str<-> float
>>> conversions of Python in D too.
>>
>> Do you have any test data that they actually are better in Python (apart
>> from just being better specified)?
>
> I can tell Google's double-conversion routines (http://goo.gl/RU5g4) are faster
> than sprintf/sscanf, in addition to being better specified. We use them at
> Facebook.

Darn, licensing problems:

"Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution."

http://www.opensource.org/licenses/bsd-license.php

On 12/5/2011 8:48 PM, Andrei Alexandrescu wrote:
> On 12/5/11 10:15 PM, Walter Bright wrote:
>> On 12/5/2011 8:10 PM, bearophile wrote:
>>> This is not about integers but yeah, I'd like the better str<-> float
>>> conversions of Python in D too.
>>
>> Do you have any test data that they actually are better in Python (apart
>> from just being better specified)?
>
> I can tell Google's double-conversion routines (http://goo.gl/RU5g4) are faster
> than sprintf/sscanf, in addition to being better specified. We use them at
> Facebook.

This one is apparently in wide use:

http://www.netlib.org/fp/dtoa.c

On 06.12.2011 05:21, bcs wrote:
> On 12/05/2011 08:37 AM, Don wrote:
>> On 05.12.2011 14:31, bearophile wrote:
>>> Found through Reddit, two blog posts about how integers should behave
>>> in system languages (with hardware support):
>>>
>>> http://blog.regehr.org/archives/641
>>> http://blog.regehr.org/archives/642
>>>
>>> Bye,
>>> bearophile
>>
>> Not very convincing, since he proposes a change to existing
>> architectures, and seems completely unaware of the overflow flag.
>
> I think he's looking at it form the language theory standpoint. As such,
> architectures has nothing to do with it (the architectures to be
> targeted has yet to be defined at that point)and getting access to the
> overflow flag would require exposing it natively in the language.

It's not that he hasn't specified an architecture. It's a proposal which does not work on _any_ existing architectures!
It's pure fantasy.

And he talks about NaN, when he means infinity. Floating point overflow never results in a NaN. He doesn't seem to know anything about saturating integer arithmetic, which exists in hardware (even x86 machines have supported a couple of operations since 1996).

Useless.

On 12/5/2011 10:52 PM, Don wrote:
> On 06.12.2011 05:15, Walter Bright wrote:
>> On 12/5/2011 8:10 PM, bearophile wrote:
>>> This is not about integers but yeah, I'd like the better str<-> float
>>> conversions of Python in D too.
>>
>> Do you have any test data that they actually are better in Python (apart
>> from just being better specified)?
>
> Bug 5229 is an example.
>
> I have five papers on this topic. Most recent is the excellent:
> Florian Loitsch, "Printing FP numbers quickly and accurately with integers" (2010)

Right now, we rely on C's standard library. Often, it's deficient. We should roll our own, like we did with the math routines, and make sure the D standard reflects the modern thinking on it.

(Python's implementation currently uses David Gay's dtoa.c)

>
> Manu:
>
> > but I don't believe I'm alone.. the rest
> > of the gamedev community will find D soon enough if the language gets it
> > right...
>
> I think games are one of the most important short-term purposes of D, despite I think D was not explicitly designed to write games.
>

I agree, it certainly didn't seem to be a major consideration early on, but I don't think any decisions yet made prohibit it from being well suited. If as you say, there is some focus to generate interest from the game community, it would be really nice to have a few binary GDC cross compiler distributions available (for windows, linux users never have problems building the toolchain themselves). ARM/PPC, maybe MIPS toolchains hosted somewhere on the website might really help encourage some people get started, and I'd love to spend some time on the standard libraries for these platforms.


> If you're suggesting the reason for trapping overflow's is
> > specifically to CATCH bugs like this, then maybe make is a compiler flag when building a debug binary? (ie. assert on integer overflow).
>
> Right.
>
>
> I think D2/D3 has also a bit of hope to replace some of the purposes of Ada language. Walter maybe didn't think of it when he designed D, but D shares some design purposes with Ada. Walter past work in aeronautical engineering leads naturally to a language that shares some of the purposes of Ada. For such purposes correctness and reliability are of the highest importance, this also means full type safety (implicit type conversions = bad) and number safety (integral overflows = bad). Defining something like a "MISRA-D" (a strict and safe subset of D similar to MISRA-C) is an option, and maybe it will produce a less butchered language.
>

I appreciate the attention to floating point detail made in D, and this
isn't incompatible with gamedev, but making standard ints compromise basic
hardware implementation just won't fly.
Compile time flag maybe to enable integer exceptions perhaps, or a special
mode like you say...

On 6 December 2011 10:27, Manu <turkeyman@gmail.com> wrote:
>> Manu:
>>
>> > but I don't believe I'm alone.. the rest
>> > of the gamedev community will find D soon enough if the language gets it
>> > right...
>>
>> I think games are one of the most important short-term purposes of D, despite I think D was not explicitly designed to write games.
>
>
> I agree, it certainly didn't seem to be a major consideration early on, but
> I don't think any decisions yet made prohibit it from being well suited.
> If as you say, there is some focus to generate interest from the game
> community, it would be really nice to have a few binary GDC cross compiler
> distributions available (for windows, linux users never have problems
> building the toolchain themselves). ARM/PPC, maybe MIPS toolchains hosted
> somewhere on the website might really help encourage some people get
> started, and I'd love to spend some time on the standard libraries for these
> platforms.
>

If you ping me on IRC to get this moving, could put some time into setting up a toolchain for such purposes over the weekend. ie: such as a sript to set-up cross compiling from the current host to target B.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';