View mode: basic / threaded / horizontal-split · Log in · Help
August 19, 2012
Re: NaNs Just Don't Get No Respect
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
Re: NaNs Just Don't Get No Respect
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
Re: NaNs Just Don't Get No Respect
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
By the way, you can make Linux signal on NaN creation. man feenableexcept (FE_ALL_EXCEPT) (nt)
See Subject :)
August 20, 2012
Re: NaNs Just Don't Get No Respect
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
Re: NaNs Just Don't Get No Respect
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
Re: NaNs Just Don't Get No Respect
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
Re: NaNs Just Don't Get No Respect
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
Re: NaNs Just Don't Get No Respect
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
Re: NaNs Just Don't Get No Respect
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.
2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home