August 19, 2012
I was against nan being the dafault value, but now I that I think about it, it is useful (for the reasons in the article).
August 20, 2012
On 08/19/2012 06:16 PM, Walter Bright wrote:
> On 8/19/2012 1:43 PM, Chad J wrote:
>> So instead of writing
>>
>> float f;
>> if (condition1)
>> f = 7;
>> ... code ...
>> if (condition2)
>> ++f;
>>
>> is there any way we can make it easier to write
>>
>> void someCode() {
>> ... code ...
>> }
>>
>> float f;
>> if ( condition )
>> {
>> f = 7;
>> someCode();
>> ++f;
>> }
>> else
>> someCode();
>>
>> assuming that condition2 is true when condition1 is true?
>
> Yes, you can do that.
>
>
>> I feel like NaNs are a step forward, but better can be done. They
>> allow error
>> detection, but it's still merely runtime error detection, and worse
>> yet, it's
>> /non-local/ error detection. NaNs can spread from function to function
>> and end
>> up in completely different parts of a program than the place they
>> originated.
>> This causes debugging hell, just like null values.
>
> I'm sorry, it's not debugging hell. I've done an awful lot of "figure
> out where this null came from" and it's a bit tedious, but not hell. You
> go step by step, such as "it's null in this function, so put an assert
> on the callers of the function", rinse, repeat.
>
> Yes, I also know this is more of a problem if you've got a program
> that's not so easy to rerun.
>

Most of the programs I've worked on, be it hobby games or business apps for pay, have been interactive stuff.  Rerunning sucks.  Debuggers also interact very poorly with these things, or just plain have crappy interfaces that make using them a legitimate pain.  My productivity is greatly improved by NOT having to do tedious busywork.

This is why I have a very low tolerance for non-local bugs and a lack of good stacktrace info when crashing.

I'd feel /a lot/ better if corrupt data like NaNs or nulls would create some kind of a crash or compiler error /before/ leaving the function that created them.

IMO, this would be a huge step forward for programmer productivity.  No longer does every nan/null take like 15-30 minutes to debug, it takes  1 minute instead.

>> It makes me think that
>> non-nan-able floating point types would be very useful, at least as
>> function
>> arguments, so that calling code doesn't have to introduce extra checks
>> for NaNs
>> that are either lost cycles or forgotten entirely and bug-ridden.
>
> You can use signalling NaNs, if you like.
>
>

How?  I remember reading a lot of material on NaNs in D, but I don't recall these.

>> I really wish we had a way of catching NaNs in the function or line
>> where they
>> happen, and not in completely distant parts of the code.
>
> Nobody has even mentioned this until I brought it up, so I have a hard
> time believing the current state of affairs is a terrible problem that
> requires a major redesign to fix.
>

I doubt that preventing non-local bug propagation would require any kind of major redesign at this point.  D seems very close already.

Some kind of convenient notation for optional non-nullable (and maybe non-nan-able?) types combined with strictly simple branching initializations and some kind of easy-to-use sentinel values would probably go a long way.

There seems to be a push to try and get this functionality from user-defined types.  I am skeptical that it will ever work for these things because something like

    NotNull!MyType foo( NotNull!MyType a, NotNan!float b ) { ... }

is going to be very daunting to write and read compared to something like

    MyType@ foo( MyType@ a, float@ b )

which is just a notation I've seen in previous posts.  Initialization becomes a huge pain for the user-defined types too.

Not only are proxy types like "NotNull!X" far more difficult to write in D than I would have expected, but things like non-null types and possibly non-nan types would be so common that things will probably look very nasty if people start using proxy types for this.  I'm willing to wait and see if these proxy types can be made though, and if they get used a lot.  I just hope their clumsiness doesn't inhibit their use.  I understand it's easier to add things in demand than it is to remove things that are used infrequently.


> I know that nobody wants to see NaNs in their results, but be assured
> that that is far, far better than corrupted results that are off in
> subtle ways. NaNs are also one hell of a lot easier to track backwards
> than the other.

I agree that NaNs are really cool.  They are definitely much better than "f=0;".  Thank you for doing this.

August 20, 2012
On 8/19/2012 6:33 PM, Chad J wrote:
> How?  I remember reading a lot of material on NaNs in D, but I don't recall these.

Set the control word for the x87 to turn it on. Probably have to do a little inline assembly.
August 20, 2012
See Subject :)
August 20, 2012
On Sun, 19 Aug 2012 01:21:03 -0500
Sean Cavanaugh <WorksOnMyMachine@gmail.com> wrote:
> 
> Nobody knows how floats work, without being locked in a closet for a at least a week and told to change their doubles back into floats and fix their code, since thats where 99% of precision problems actually come from.
> 

Sorry, I don't understand, where are you saying 99% of precision problems come from?

August 20, 2012
On 8/20/2012 12:41 AM, Nick Sabalausky wrote:
> On Sun, 19 Aug 2012 01:21:03 -0500
> Sean Cavanaugh<WorksOnMyMachine@gmail.com>  wrote:
>>
>> Nobody knows how floats work, without being locked in a closet for a
>> at least a week and told to change their doubles back into floats and
>> fix their code, since thats where 99% of precision problems actually
>> come from.
>>
>
> Sorry, I don't understand, where are you saying 99% of precision
> problems come from?
>

Chaining algorithms together without regard to how the floats are propagated through the system.  Also, accumulating lots of values with addition and subtraction can be problematic, as can subtracting two values to near-zero values also leaves you with a most of the error.

There is a pretty classic example in 3d graphics: the transform from object space to world space to projection space.  Even if these matrices are combined, your geometry can be transformed a very large distance from the world origin and lose a lot of precision in the process.  The way to fight this is to use camera instead of world space as much as possible.  If you don't do this all the vertices on all the meshes in your world snap to different values at varying rates when they move or the camera moves, causing one of the main forms of z-fighting.   Plus the further you get from your world origin the worse things get, which makes building something on the scale of an open-world game rather difficult.

August 20, 2012
On 18/08/12 05:03, bearophile wrote:
> F i L:
>
>> Why would it matter what is "normal"?
>
> It matters to me because I am curious.
>
> Why aren't my friends that work or study chemistry writing free small
> online articles like my programmer&CS friends do? Maybe it's systematic
> differences in their brain brain? Or it's just more easy to talk about
> coding compared to botany and chemistry and making engines? Or maybe
> programmers don't know what they are doing? Or maybe it's just I am not
> looking in the right places? :-)
>
> Bye,
> bearophile


They write journal articles instead. Producing journal articles have never been of major importance for IT, but they are crucial for science.

And if it isn't a new, publishable result, you're more likely to contribute to something like Wikipedia, than to write a blog post.

OTOH some people do blog, for example, http://terrytao.wordpress.com/
who is one of the top mathematicians on the planet.
August 20, 2012
Walter Bright, el 18 de August a las 12:11 me escribiste:
> On 8/18/2012 6:51 AM, Peter Alexander wrote:
> >Maybe it's related to the tendency for programmers to be libertarians, which would also explain the whole open source software movement. They want to share knowledge freely, and online articles would be part of that.
>
> I find this peculiar, as the open source software movement is frequently associated with communism, not libertarianism. (Although I do think it is much more correct to associate it with libertarianism.)

Well, free software[1] is closer to communism (or socialism), open
source (as in the OSD)[2] is closer to libertarianism.

"Open source is a development methodology; free software is a social movement." -- Richard Stallman

[1] http://en.wikipedia.org/wiki/The_Free_Software_Definition [2] http://opensource.org/docs/osd

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Cuando le dije si querĂ­a bailar conmigo
Se puso a hablar de Jung, de Freud y Lacan
Mi idiosincracia le causaba mucha gracia
Me dijo al girar la cumbiera intelectual
August 20, 2012
Any chance that math.isNaN() will work at compile-time in the future? http://d.puremagic.com/issues/show_bug.cgi?id=8562

I haven't had the chance to study the source since last night, but is it not possible to check to see if something is a nan without doing a cast?

On Fri, Aug 17, 2012 at 7:03 PM, Walter Bright <newshound2@digitalmars.com>wrote:

> Our discussion on this in the last few days inspired me to write a blog post about it:
>
> http://www.reddit.com/r/**programming/comments/yehz4/** nans_just_dont_get_no_respect/<http://www.reddit.com/r/programming/comments/yehz4/nans_just_dont_get_no_respect/>
>
> http://www.drdobbs.com/cpp/**nans-just-dont-get-no-respect/**240005723<http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723>
>


August 20, 2012
On 8/20/12, Walter Bright <newshound2@digitalmars.com> wrote:
> On 8/19/2012 6:33 PM, Chad J wrote:
>> How?  I remember reading a lot of material on NaNs in D, but I don't recall these.
>
> Set the control word for the x87 to turn it on. Probably have to do a little
>
> inline assembly.
>

I thought you could do by setting FloatingPointControl in std.math.