On 2011-Dec-05 18:30:54+00:00, bearophile 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 played a game, where experience counter was int32, it wasn't meant to overflow during normal play, but it allowed console commands, which could be a lot of fun, so I made xp overflow to negative values, it didn't make any trouble, just in the case it used checked arithmetic, it would crash, not so much fun.

Don Wrote:

> On 07.12.2011 05:11, bcs wrote:
> > On 12/05/2011 11:20 PM, Don wrote:
> >> 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.
> >
> > Well you can do it on x86. The fact the it doesn't provied hardware traps is irrelevant. You might need to add a lot of branches but you can get the semantics he is asking for.
> >
> > That said, there is another interesting (but independent) question of can it be done efficiently? You might have a very good question there, but that isn't the question regehr is considering.
> >
> >>
> >> And he talks about NaN, when he means infinity. Floating point overflow never results in a NaN.
> >
> > You have a point there.
> >
> >> 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.
> >
> > Again, he's not interested in the hardware implementation, he's only interested in the defined semantics of the language, the things you can count on regardless of that instruction set you are using. The fact the x86 has saturating integer operations is moot because C doesn't have a type the end up using them.
> 
> He's talking about system languages. A system language has to have a close relationship to the architecture.

Ada is a systems language and if I am not mistaken allows for the type of rules he is describing.

C# is also used as systems language in the Singularity project (Sing# + Bartok) and also has some of the strict rules he advocates.

I am pretty sure that there are quite a few systems languages that have more precise rules regarding integer overflow.

Kagamin:

>I played a game, where experience counter was int32, it wasn't meant to overflow during normal play, but it allowed console commands, which could be a lot of fun, so I made xp overflow to negative values, it didn't make any trouble, just in the case it used checked arithmetic, it would crash, not so much fun.<

If that game is written in C/C++ then those languages don't define what happens when you add 1 to the max signed integer. This means crashing the game in that case is OK according to the specs of those languages.

And even if that experience counter is an unsigned integer, that in C/C++ has to wrap to zero, how many signed or unsigned 32 bit integers there are in a game? A lot. I presume that for most of them a silent wrap to the minimum integer doesn't lead to a fun game. As it usually happens in complex systems, there are far more ways for that system to not work than to work. In most cases implicit modular arithmetic doesn't lead to smooth error behaviours.

Bye,
bearophile

Manu:

> but making standard ints compromise basic hardware implementation just won't fly.<

Ada language does those things, and it's used to fly planes :-) So maybe it will fly.

Today some online games are managing real money of the players. You don't want to use raw integers to manage those important numbers :-)

Bye,
bearophile

On 12/07/2011 11:46 AM, bearophile wrote:
> Manu:
>
>> but making standard ints compromise basic hardware implementation just won't fly.<
>
> Ada language does those things, and it's used to fly planes :-) So maybe it will fly.

Maybe. Ada in action: http://www.youtube.com/watch?v=kYUrqdUyEpI

>
> Today some online games are managing real money of the players. You don't want to use raw integers to manage those important numbers :-)
>

Therefore, don't do that.

On 12/07/2011 11:41 AM, bearophile wrote:
> [...] As it usually happens in complex systems, there are far more ways for that system to not work than to work. [...]
>

Maybe we should exclusively study the ways for for the system to work, as that seems to be less complex.

On 12/7/2011 2:46 AM, bearophile wrote:
> Today some online games are managing real money of the players. You don't
> want to use raw integers to manage those important numbers :-)

Banks have been using computer programs to handle money forever, so has every piece of accounting software. I.e. it's a well understood and solved issue.

It'd be very foolish for online game developers to try to reinvent this.

And frankly, we'd also be foolish to try and reinvent it without consulting with someone who does financial software professionally.

On 12/06/2011 11:50 PM, Don wrote:
>
> He's talking about system languages. A system language has to have a
> close relationship to the architecture.
>
> By contrast, if you don't care about performance, it's easy -- just use
> BigInts for everything. Problem solved.
>
> Looks like I have to put it more bluntly: I don't think he knows what
> he's talking about. (On this particular topic).

I know exactly what you have been saying I just think you are wrong, not because I don't think you knows what you are talking about but because I think you are evaluating his conclusion based on a different criteria than he is.

More specifically, I think we are dealing with a differing order of priories for system languages. Mine would put safety (i.e. NO undefined behaviour) over performance. I think he is going the same way. Personally, if I could only have one, I think I'd (first) go with defining overflow semantics rather than trapping but I'm not sure which is more useful in a systems context.

Can we at least agree that if you are only going to have one signed integer semantic, that undefined overflow is the worst possible choice?

On 06.12.2011 08:20, Walter Bright wrote:
> 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)

The Loitsch paper is very interesting, it presents a simple very fast method which works in 99.5% of cases. Then, you fall back to the simple slow method for the remaining 0.5%. The slow case is rare enough that it's not worth optimizing it.

By contrast, dtoa.c is very complicated, because its fast method only works for ~75% of cases, so there are many optimisations for special cases of the slow method.

On 08.12.2011 05:46, bcs wrote:
> On 12/06/2011 11:50 PM, Don wrote:
>>
>> He's talking about system languages. A system language has to have a
>> close relationship to the architecture.
>>
>> By contrast, if you don't care about performance, it's easy -- just use
>> BigInts for everything. Problem solved.
>>
>> Looks like I have to put it more bluntly: I don't think he knows what
>> he's talking about. (On this particular topic).
>
> I know exactly what you have been saying I just think you are wrong, not
> because I don't think you knows what you are talking about but because I
> think you are evaluating his conclusion based on a different criteria
> than he is.

HE PROPOSES CHANGING INSTRUCTION SETS.

> More specifically, I think we are dealing with a differing order of
> priories for system languages. Mine would put safety (i.e. NO undefined
> behaviour) over performance. I think he is going the same way.
> Personally, if I could only have one, I think I'd (first) go with
> defining overflow semantics rather than trapping but I'm not sure which
> is more useful in a systems context.
>
> Can we at least agree that if you are only going to have one signed
> integer semantic, that undefined overflow is the worst possible choice?

Yes, but D doesn't have undefined overflow. So it's irrelevant.