View mode: basic / threaded / horizontal-split · Log in · Help
April 14, 2012
Re: floats default to NaN... why?
On Saturday, 14 April 2012 at 06:43:11 UTC, Manfred Nowak wrote:
> F i L wrote:
>
>> It sounds like circular reasoning.
>
> Several considerations pressed the design into the current form:
> 1) always changing output on unchanged input is hard to debug
> 2) GC needs to be saved from garbage, that looks like pointers
> 3) missed explicit initializations should not create syntax 
> errors
> 4) use hardware signalling to overcome some of the limitations
> impressed by 3).
> 5) more???
>
> For me the only questionable point is numer three.
>
> -manfred

1) Good argument.
2) Don't know enough about the GC. Can't comment.
3) I agree. I just disagree with how they are expected to be used 
without explicit definition.
4) I have no idea what you just said... :)
5) profit??
April 14, 2012
Re: floats default to NaN... why?
On Saturday, 14 April 2012 at 06:29:40 UTC, Ali Çehreli wrote:
> On 04/13/2012 09:00 PM, F i L wrote:
>
> > default is NaN
>
> Just to complete the picture, character types have invalid 
> initial values as well: 0xFF, 0xFFFF, and 0x0000FFFF for char, 
> wchar, and dchar, respectively.
>
> Ali

That's interesting, but what effect does appending an invalid 
char to a valid one have? Does the resulting string end up being 
"NaS" (Not a String)? Cause if not, I'm not sure that's a fair 
comparison.
April 14, 2012
Re: floats default to NaN... why?
On Saturday, April 14, 2012 09:45:57 F i L wrote:
> If D doesn't accommodate entering Laymen, how does it expect to
> gain popularity in any major way? Efficiency puts D on the map,
> convenience is what brings the tourists.

I believe that you are the first person that I have ever heard complain that D 
tries to default to error values. I think that some have asked why the types 
default to what they default to, but it's not something that people normally 
complain about. I've explained the reasoning behind it. You can like it or 
not, but as far as I can tell, this is a complete non-issue.

- Jonathan M Davis
April 14, 2012
Re: floats default to NaN... why?
On Saturday, April 14, 2012 09:58:42 F i L wrote:
> On Saturday, 14 April 2012 at 06:29:40 UTC, Ali Çehreli wrote:
> > On 04/13/2012 09:00 PM, F i L wrote:
> > > default is NaN
> > 
> > Just to complete the picture, character types have invalid
> > initial values as well: 0xFF, 0xFFFF, and 0x0000FFFF for char,
> > wchar, and dchar, respectively.
> > 
> > Ali
> 
> That's interesting, but what effect does appending an invalid
> char to a valid one have? Does the resulting string end up being
> "NaS" (Not a String)? Cause if not, I'm not sure that's a fair
> comparison.

You can't append a char to a char. You can append them to strings, but not 
each other.

Appending an invalid char results in a string with an invalid char. It won't 
blow up on its own. But any function which attempts to decode the string 
(which includes the vast majority of functions which would be called on a 
string) would result in a UTFException. So, you'll generally know that you 
have a bad string very quickly.

- Jonathan M Davis
April 14, 2012
Re: floats default to NaN... why?
On Saturday, 14 April 2012 at 07:59:25 UTC, Jonathan M Davis 
wrote:
> On Saturday, April 14, 2012 09:45:57 F i L wrote:
>> If D doesn't accommodate entering Laymen, how does it expect to
>> gain popularity in any major way? Efficiency puts D on the map,
>> convenience is what brings the tourists.
>
> I believe that you are the first person that I have ever heard 
> complain that D
> tries to default to error values. I think that some have asked 
> why the types
> default to what they default to, but it's not something that 
> people normally
> complain about. I've explained the reasoning behind it. You can 
> like it or
> not, but as far as I can tell, this is a complete non-issue.

Well my testimonial evidence against yours, eh? :) I'm not trying 
to get under anyone's skin here. You've explained the logic 
behind the decision and I think I've made some valid points 
against that logic. You obviously don't feel like arguing the 
point further, so I'll just leave it at that.
April 14, 2012
Re: floats default to NaN... why?
On Saturday, 14 April 2012 at 07:52:51 UTC, F i L wrote:
> On Saturday, 14 April 2012 at 06:43:11 UTC, Manfred Nowak wrote:
>> F i L wrote:
>>
>> 4) use hardware signalling to overcome some of the limitations
>> impressed by 3).
>
> 4) I have no idea what you just said... :)

On Saturday, 14 April 2012 at 07:58:44 UTC, F i L wrote:
> That's interesting, but what effect does appending an invalid 
> char to a valid one have? Does the resulting string end up 
> being "NaS" (Not a String)? Cause if not, I'm not sure that's a 
> fair comparison.

The initialization values chosen are also determined by the 
underlying hardware implementation of the type. Signalling NANs 
(http://en.wikipedia.org/wiki/NaN#Signaling_NaN) can be used with 
floats because they are implemented by the CPU, but in the case 
of integers or strings their aren't really equivalent values.

On Saturday, 14 April 2012 at 07:45:58 UTC, F i L wrote:
> My original post was inspired by me showing my D code to 
> another C# guy earlier, and coming up with poor explanations as 
> to why floats where required to be defaulted in my math lib. 
> His reaction what along the lines of my first post.

I think the correct mindset when working in D is to think that 
"all variables should be initialized" and if you get incorrect 
calculations with zero values, division by zero errors or nan 
errors the most likely mistake is often that this guideline was 
not followed.
April 14, 2012
Re: floats default to NaN... why?
Am 14.04.2012 07:48, schrieb F i L:
> On Saturday, 14 April 2012 at 05:19:38 UTC, dennis luehring wrote:
>>  Am 14.04.2012 06:00, schrieb F i L:
>>>       struct Foo {
>>>         int x, y;    // ready for use.
>>>         float z, w;  // messes things up.
>>>         float r = 0; // almost always...
>>>       }
>>
>>  how often in your code is 0 or 0.0 the real starting point?
>>  i can't think of any situation except counters or something
>>  where 0 is a proper start - and float 0.0 is in very very few
>>  cases a normal start - so whats your point?
>
> Every place that a structure property is designed to be mutated
> externally. Almost all Math structures, for instance.

if a float or double is initalized with nan - all operations on them 
will result to nan - that is a very good sign for missing "proper" 
initialisation

what does make float default to 0.0 better - does it just feel better?
April 14, 2012
Re: floats default to NaN... why?
On 14/04/12 09:45, F i L wrote:
> Jonathan M Davis wrote:
>> No. You always have a bug if you don't initialize a variable to the value that
>> it's supposed to be. It doesn't matter whether it's 0, NaN, 527.1209823, or
>> whatever. All having a default value that you're more likely to use means is
>> that you're less likely to have to explicitly initialize the variable. It has
>> to be initialized to the correct value regardless.
>
> Yes, I'm in favor of default values. That's not my argument here. I'm saying it makes more sense to have the default values be _usable_ (for convenience) rather than designed to catch (**cause**) bugs.
>

Why would a compiler set `real' to 0.0 rather then 1.0, Pi, .... ?
The more convenient default set certainly depends on the underlying mathematics,
and a compiler  cannot (yet) understand the encoded mathematics.
NaN is certainly the certainly the very choice as whatever the involved mathematics,
they will blow up sooner or later. And, from a practical point of view, blowing up
is easy to trace.

>
April 14, 2012
Re: floats default to NaN... why?
F i L:

> So basically, it's for debugging?

To avoid bugs it's useful for all variables to be initialized 
before use (maybe with an explicit annotation for the uncommon 
cases where you want to use uninitialized memory, like: 
http://research.swtch.com/sparse ). Having a variable not 
initialized is a common source of bugs.

C# solves this requiring explicit initialization all variables 
before use. Walter doesn't believe that flow analysis is flexible 
enough in a system language like D (or he doesn't want to 
implement it) so he has not used this idea in D.

So D uses a different worse strategy, it initializes the 
variables to something unusable, so if you try to use them, your 
program fails clearly.

The idea of setting the variables to something useful, like 
setting initialized chars to 'a' and floating point values to 0.0 
looks handy, but on the long run it's not an improvement. You 
sometimes don't initialize a char variable because you are fine 
for it to be 'a', and some other times you don't set it just 
because you forget to initialize it. The compiler can't tell 
apart the two cases, and this is may be a bug in your code.

In practice I think having FP variables initialized to NaN has 
not avoided me significant bugs in the last years. On the other 
hand I have ported some C code that uses global floating point 
arrays/variables to D, and I have had to remove some bugs caused 
by the assumption in the C code that those global FP variables 
are initialized to zero, that's false in D.

Another source of troubles is large fixed-sized FP global arrays, 
that inflate the binary a *lot*. You have to remember to 
initialize them to zero explicitly:

double[100_000] foo; // bad, inflates binary.
double[100_000] bar = 0.0; // good.
void main() {}

In D I'd like the solution used by C# + an annotation to not 
initialize a variable or array.

Bye,
bearophile
April 14, 2012
Re: floats default to NaN... why?
On 4/14/12, bearophile <bearophileHUGS@lycos.com> wrote:
> Having a variable not initialized is a common source of bugs.

I'm going to argue that this was true for C/C++ but is much less true
for D. One benefit of having integrals initialized to 0 is that you
now have a defined default that you can rely on (just as you can rely
on pointers being null by default). Personally I find this to be a big
win in productivity. If the language/runtime does something defined
for me then I can focus on more important things.

But NaN might be a good thing for all I know.. I rarely use
floating-point so I'll stay out of that, but I'd like to have this
fixed: http://d.puremagic.com/issues/show_bug.cgi?id=6303
1 2 3 4 5 6
Top | Discussion index | About this forum | D home