The following comes partially from a friend of mine. If you are busy you can
skip this post of musings.
>From the docs:
http://www.digitalmars.com/d/1.0/faq.html#nan
>Because of the way CPUs are designed, there is no NaN value for integers, so D
>uses 0 instead. It doesn't have the advantages of
== Quote from bearophile (bearophileh...@lycos.com)'s article
> The following comes partially from a friend of mine. If you are busy you can
skip this post of musings.
> From the docs:
> http://www.digitalmars.com/d/1.0/faq.html#nan
> >Because of the way CPUs are designed, there is no NaN value for
"bearophile" wrote in message
news:h237c9$or...@digitalmars.com...
> The following comes partially from a friend of mine. If you are busy you
> can skip this post of musings.
>
> From the docs:
> http://www.digitalmars.com/d/1.0/faq.html#nan
>>Because of the way CPUs are designed, there is no Na
Nick Sabalausky:
> Ie, Default initing to NaN is certainly better than
> default-initing to a commonly-used value, but it still isn't the right
> long-term solution.
Having a nan has other purposes beside initialization values. You can represent
missing values, like C# nullable ints (that are b
Hello Nick,
Interesting idea, but IMO using NaN as a default initializer is just a
crutch for not having a real system of compile-time
detecting/preventing of uninitialized variables from being read (C#'s
system for this works very well in my experience).
I think you can prove that it is impos
BCS wrote:
>> Interesting idea, but IMO using NaN as a default initializer is just a
>> crutch for not having a real system of compile-time
>> detecting/preventing of uninitialized variables from being read (C#'s
>> system for this works very well in my experience).
>
> I think you can prove that
Michiel Helvensteijn Wrote:
> BCS wrote:
>
> >> Interesting idea, but IMO using NaN as a default initializer is just a
> >> crutch for not having a real system of compile-time
> >> detecting/preventing of uninitialized variables from being read (C#'s
> >> system for this works very well in my exp
superdan wrote:
>> Complete static analysis of the flow of program control is the holy grail
>> of compiler construction. It would allow automatic proof of many program
>> properties (such as initialization). It may not be impossible, but it is
>> extremely complicated.
>
> extremely complicated?
On Sat, 27 Jun 2009 17:50:11 +0400, BCS wrote:
Hello Nick,
Interesting idea, but IMO using NaN as a default initializer is just a
crutch for not having a real system of compile-time
detecting/preventing of uninitialized variables from being read (C#'s
system for this works very well in my exp
Denis Koroskin wrote:
>> int i;
>>
>> for(int j = foo(); j > 0; j--) i = bar(j); // what if foo() returns
>> -5?
>
> This code doesn't compile in C# and fails with the following error at
> first attempt to use 'i':
>
> error CS0165: Use of unassigned local variable 'i'
Ah, so C# is overly con
Michiel Helvensteijn wrote:
* Add 'uninitialized' to the set of possible states of each type. Every time
a variable is read, assert that it is initialized first. Use the static
analysis techniques that *are* available (a set that will continue to grow)
to eliminate these tests (and the extended s
"bearophile" wrote in message
news:h250ve$1dv...@digitalmars.com...
> Nick Sabalausky:
>> Ie, Default initing to NaN is certainly better than
>> default-initing to a commonly-used value, but it still isn't the right
>> long-term solution.
>
> Having a nan has other purposes beside initialization
"Michiel Helvensteijn" wrote in message
news:h25fbk$28m...@digitalmars.com...
> Denis Koroskin wrote:
>
>>> int i;
>>>
>>> for(int j = foo(); j > 0; j--) i = bar(j); // what if foo() returns
>>> -5?
>>
>> This code doesn't compile in C# and fails with the following error at
>> first attempt to
"Nick Sabalausky" wrote in message
news:h2623m$73...@digitalmars.com...
> "Michiel Helvensteijn" wrote in message
> news:h25fbk$28m...@digitalmars.com...
>> Denis Koroskin wrote:
>>
int i;
for(int j = foo(); j > 0; j--) i = bar(j); // what if foo() returns
-5?
>>>
>>> This
Hello Denis,
On Sat, 27 Jun 2009 17:50:11 +0400, BCS wrote:
Hello Nick,
Interesting idea, but IMO using NaN as a default initializer is just
a crutch for not having a real system of compile-time
detecting/preventing of uninitialized variables from being read
(C#'s system for this works very
Hello Nick,
"Michiel Helvensteijn" wrote in
message news:h25fbk$28m...@digitalmars.com...
Ah, so C# is overly conservative. That's another option, of course.
It has the advantage of always knowing at compile time that you're
not reading an uninitialized value. The disadvantage is that C# wil
Having a nan has other purposes beside initialization values. You can represent
missing values, like C# nullable ints (that are bigger in size, 8 bytes, I
think).
You're saying C# nullable ints require more memory than native ints, but
just how would you represent int.nan with 32 bits?
The
grauzone:
> You're saying C# nullable ints require more memory than native ints, but
> just how would you represent int.nan with 32 bits?
Have you read my posts? I have said to use the value that currently is int.min
as null, and I've explained why.
I'll keep dreaming some more years,
bye,
be
Have you read my posts? I have said to use the value that currently is int.min
as null, and I've explained why.
That wasn't very explicit. Anyway, we need int.min for, you know, doing
useful stuff. We can't just define a quite random number to be a special
value. Checking math operations for
Nick Sabalausky wrote:
>> Yes, this approach is what I was getting at. In fact, I would (and
>> already have in the past) argue that this is *better* than the "holy
>> grail" approach, because because it's based on very simple and easy to
>> remember rules. Conversely, the "holy grail" approach le
Simen Kjaeraas wrote:
>> But the beauty of the holy grail is that it's neither.
>
> While the ugliness of it is that it's both.
Care to elaborate?
--
Michiel Helvensteijn
Michiel Helvensteijn wrote:
But the beauty of the holy grail is that it's neither.
While the ugliness of it is that it's both.
--
Simen
Michiel Helvensteijn escribió:
Nick Sabalausky wrote:
Yes, this approach is what I was getting at. In fact, I would (and
already have in the past) argue that this is *better* than the "holy
grail" approach, because because it's based on very simple and easy to
remember rules. Conversely, the "h
Michiel Helvensteijn wrote:
Simen Kjaeraas wrote:
But the beauty of the holy grail is that it's neither.
While the ugliness of it is that it's both.
Care to elaborate?
As has already been mentioned, one of the biggest problems with the holy
grail is that it leads to capricious states of
Ary Borenszweig wrote:
>> int i;
>> assert(foo() > 3);
>> for(int j = foo(); j > 3; j--) i = j;
>> auto k = i; // Compiles at the moment...
>>
>> Would C# swallow that?
>
> Of course not:
>
> int foo() {
>return rand() % 10;
> }
My mistake. For some reason I was assuming 'foo' was pure.
Simen Kjaeraas wrote:
But the beauty of the holy grail is that it's neither.
>>>
>>> While the ugliness of it is that it's both.
>>
>> Care to elaborate?
>
> As has already been mentioned, one of the biggest problems with the holy
> grail is that it leads to capricious states of "possibly co
"Michiel Helvensteijn" wrote in message
news:h2810s$hl...@digitalmars.com...
> Nick Sabalausky wrote:
>
>>> Yes, this approach is what I was getting at. In fact, I would (and
>>> already have in the past) argue that this is *better* than the "holy
>>> grail" approach, because because it's based o
grauzone:
> That wasn't very explicit. Anyway, we need int.min for, you know, doing
> useful stuff.
Like for what? Have you used a Lisp? Their tagged integers show that a smaller
range is fine. And I'm just talking about 1 value in 4 billions, I don't think
you will miss it much. And it's a val
Nick Sabalausky wrote:
> The fix would be one of the following, depending on what the code is
> actually doing:
>
> ---
> // Instead of knee-jerking i to 0, we default init it to
> // whatever safe value we want it to be if the loop
> // doesn't set it. This, of course, may or may not
"Nick Sabalausky" wrote in message
news:h28gqc$1du...@digitalmars.com...
> "Michiel Helvensteijn" wrote in message
> news:h2810s$hl...@digitalmars.com...
>>
>>> Additionally, in the C# approach (and this is speaking from personal
>>> experience), anytime you do come across a provably-correct ca
Nick Sabalausky wrote:
> Ie, I can agree that the compiler should be able to take advantage of a
> function's contract when determining whether or not to throw a "may not
> get inited" error, but I strongly disagree that the contract used should
> be implicity defined by the actual behavior of the
Hello Nick,
Also, keep in mind that while, under this mechanism, it is certainly
possible for a coder to cause bugs by always knee-jerking the value to
zero whenever the compiler complains, that's also a possibility under
the "holy grail" approach.
How about letting the user signal that they
I'm sorry but I think it would be an ugly feature.
What would be the NaN of uint ?
What if you actually need 2^32 different values (such as in a linear
congruential random number generator) ?
Besides, there would be no cheap way to ensure NaN propagation (no hardware
support).
Cheers.
"Michiel Helvensteijn" wrote in message
news:h28i61$1hl...@digitalmars.com...
> Nick Sabalausky wrote:
>
>> The fix would be one of the following, depending on what the code is
>> actually doing:
>>
>> ---
>> // Instead of knee-jerking i to 0, we default init it to
>> // whatever safe
ponce:
> What would be the NaN of uint ?
Having a NaN in just signed integral values (of 1, 2, 4, 8, 16 bytes) looks
enough to me, see below.
>What if you actually need 2^32 different values (such as in a linear
>congruential random number generator) ?<
I agree that there are many situations
On Sun, Jun 28, 2009 at 6:02 PM, bearophile wrote:
>>Besides, there would be no cheap way to ensure NaN propagation (no hardware
>>support).<
>
> I was talking about having hardware support, of course.
Let me know when x86 gets that.
Nick Sabalausky wrote:
> Init, assert, spell-check land, etc.
We're agreed.
>>> Also, keep in mind that while, under this mechanism, it is certainly
>>> possible for a coder to cause bugs by always knee-jerking the value to
>>> zero whenever the compiler complains, that's also a possibility unde
"Jarrett Billingsley" wrote in message
news:mailman.315.1246226874.13405.digitalmar...@puremagic.com...
> On Sun, Jun 28, 2009 at 6:02 PM, bearophile
> wrote:
>
>>>Besides, there would be no cheap way to ensure NaN propagation (no
>>>hardware support).<
>>
>> I was talking about having hardware
bearophile wrote:
grauzone:
That wasn't very explicit. Anyway, we need int.min for, you know, doing
useful stuff.
Like for what? Have you used a Lisp? Their tagged integers show that a smaller
range is fine. And I'm just talking about 1 value in 4 billions, I don't think
you will miss it muc
Frits van Bommel:
> It's fine for Lisp because any Lisp I've ever seen auto-upgrades out-of-range
> integers to (heap-allocated) bigints.
I think it can be fine even if you have just fixnums with that single value
missing from signed integrals.
> I'd like to point out you don't need a new buil
40 matches
Mail list logo
