April 20, 2005
I think you missed the point.  The number 64 isn't arbitrary.  It's a function of the binary effect of the hardware's wiring.  Yes, you can do what ever you want with the data that fits in those 64 bits, but you need a way to know what they are first... and the standard 64 bit integer representations are there for that purpose.

TZ

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:42669804.2060705@nospam.org...
> Walter wrote:
> >> Is it possible at all to have the Old Farts, who hold the keys to Programming World, to become susceptible to our demands?
> >
> > LOL.
>
> Suppose the "over 60" bit type was actually 63 bits.
>
> How many would seriously start crying about 63 bits being seriously deficient? Their opposition would surely suggest 127 bits for those purposes.
>
> Well now we would have 2^64 - 1 values. We lose one single value. A national Disaster.
>
> And we'd lose this value _only_ in situations where we're dealing with a possibly uninitialized value.
>
> Not a huge loss, IMHO.
>
> The specific issue here is that "they" are so old, that they'd have a
> hard time noticing all of a sudden that we actually do have values to
> spare. Extending this thought, it should be equally hard to have them
> designate one single value for NAN even with 1024 bit integers. (Seriously.)
>
> I can see the worries of these guys. Traditionally a lot of code has been dependent on "integer" overflow hardware traps, wich have been extensively used when doing integer arithmetic wider than the accumulator in the processor.
>
> And even today, with all kinds of encryption getting increasingly important, that is not going to go away.
>
> I think this would not be hampered in any way with a compiler that initialises ints with this NAN value (in the cases where it can't immediately see for sure that the variable is assigned a value before first use).
>
> By the same token, at reading the value in all places where the compiler "knows" that the variable is already initialised, the NAN checks would not be done.
>
> -----
>
> While I'm not suggesting or demanding, I still write the following:
>
> (Oh, and don't anybody even think of D 1.0 here. This is purely academic
> at this stage.)
>
> There are several alternative things one could do here:
>
> 1) Suppose we create a new data type, called GuardedInt64. This type
> would always be checked against the NAN value upon retrieval. (A single
> machine instruction comparing with an immediate value. Not Enormously Slow.)
>
> 2) Or, we could decide that non-release builds check against NAN if there is reason to be unsure whether the variable is already initialised. If the compiler can see that there is no danger of that, then it would not bother to check. (This NAN thing would also be switchable on the command line, and/or with a pragma.)
>
> 3) Or, in non-release code, for every int there could be a "shadow variable", whose purpose would only be to know whether the real variable was already initialised. (This would be slow, but hey, non-release code in D is already slower -- which is OK.) (The naïve implementation being that every time you write to your int, the shadow int gets written a 1. And every time you read yuor int, the shadow int gets checked for null. Null denoting that we have a read before any write.)
>
> 4-300) And probably hundreds of other variations. :-)
>
> -----------
>
> It's a shame that we don't yet have the Micro Forks releases (those "Everyone Tinker Yourself Instead of Crowding the Newsgroup with Demands and Dreams" packages.)
>
> It would be so easy for someone to create a (for example) GuardedInt64 type, and let others use that particular compiler for a while, for some real-world experiences.
>
> With the same effort, probably anybody doing that would implement the same for 32bit ints, both signed and unsigned. This would give us even more real world experience.
>
> (( Aahh, the Micro Forks releases! Man, we could
>     speed up D research and development! We'd
>     multiply the speed, instead of merely adding.
>
>     Why do you think open source runs circles
>     around Bill, and even Larry E? It's not that
>     there are thousands of developers. It's that
>     everyone gets the code to tinker with, doing
>     his on pet peeve, or his own dream. A lot
>     of tiny springs make the Amazon.
>
>     We need them now, not when D is at 5.5.
>
>     Ha, the C++ Beards wouldn't even know what hit
>     them, by that time we'd be in Jupiter!
> ))
>
> Actually, this could be done with my (still in planning ;-( ) "D
> preprocessor / D language lab / D meta language compiler". But, alas,
> that's at least months away (if not Quarters). I wish I were 30 years
> younger!
>
> But more practical, sooner, and for the common good a lot better solution would really be the Micro Forks tinkering distro. (Be it Walter's, Anders', David's or somebody else's.)
>
> -----------
>
> A language that has the audacity to screw up thoroughly established practices ("bit" booleans, a serious language with GC, etc. (disclaimer: IMHO the latter is good)), could very well be the one forerunner with int-NANs.
>
> _Somebody_ has to take the first step.


April 20, 2005
TechnoZeus wrote:
> I think you missed the point.  The number 64 isn't arbitrary.  It's a
> function of the binary effect of the hardware's wiring.  Yes, you can
> do what ever you want with the data that fits in those 64 bits, but
> you need a way to know what they are first... and the standard 64 bit
> integer representations are there for that purpose.

Oh, ok, I must be getting old and dumb.

> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
> news:42669804.2060705@nospam.org...
> 
>> Walter wrote:
>> 
>>>> Is it possible at all to have the Old Farts, who hold the keys
>>>> to Programming World, to become susceptible to our demands?
>>> 
>>> LOL.
>> 
>> Suppose the "over 60" bit type was actually 63 bits.
>> 
>> How many would seriously start crying about 63 bits being seriously
>>  deficient? Their opposition would surely suggest 127 bits for
>> those purposes.
>> 
>> Well now we would have 2^64 - 1 values. We lose one single value. A
>>  national Disaster.
>> 
>> And we'd lose this value _only_ in situations where we're dealing
>> with a possibly uninitialized value.
>> 
>> Not a huge loss, IMHO.
>> 
>> The specific issue here is that "they" are so old, that they'd have
>> a hard time noticing all of a sudden that we actually do have
>> values to spare. Extending this thought, it should be equally hard
>> to have them designate one single value for NAN even with 1024 bit
>> integers. (Seriously.)
>> 
>> I can see the worries of these guys. Traditionally a lot of code
>> has been dependent on "integer" overflow hardware traps, wich have
>> been extensively used when doing integer arithmetic wider than the accumulator in the processor.
>> 
>> And even today, with all kinds of encryption getting increasingly important, that is not going to go away.
>> 
>> I think this would not be hampered in any way with a compiler that initialises ints with this NAN value (in the cases where it can't immediately see for sure that the variable is assigned a value
>> before first use).
>> 
>> By the same token, at reading the value in all places where the
>> compiler "knows" that the variable is already initialised, the NAN
>> checks would not be done.
>> 
>> -----
>> 
>> While I'm not suggesting or demanding, I still write the following:
>> 
>> 
>> (Oh, and don't anybody even think of D 1.0 here. This is purely
>> academic at this stage.)
>> 
>> There are several alternative things one could do here:
>> 
>> 1) Suppose we create a new data type, called GuardedInt64. This
>> type would always be checked against the NAN value upon retrieval.
>> (A single machine instruction comparing with an immediate value.
>> Not Enormously Slow.)
>> 
>> 2) Or, we could decide that non-release builds check against NAN if
>>  there is reason to be unsure whether the variable is already initialised. If the compiler can see that there is no danger of
>> that, then it would not bother to check. (This NAN thing would also
>> be switchable on the command line, and/or with a pragma.)
>> 
>> 3) Or, in non-release code, for every int there could be a "shadow variable", whose purpose would only be to know whether the real
>> variable was already initialised. (This would be slow, but hey,
>> non-release code in D is already slower -- which is OK.) (The naïve
>> implementation being that every time you write to your int, the
>> shadow int gets written a 1. And every time you read yuor int, the
>> shadow int gets checked for null. Null denoting that we have a read
>> before any write.)
>> 
>> 4-300) And probably hundreds of other variations. :-)
>> 
>> -----------
>> 
>> It's a shame that we don't yet have the Micro Forks releases (those
>>  "Everyone Tinker Yourself Instead of Crowding the Newsgroup with
>> Demands and Dreams" packages.)
>> 
>> It would be so easy for someone to create a (for example)
>> GuardedInt64 type, and let others use that particular compiler for
>> a while, for some real-world experiences.
>> 
>> With the same effort, probably anybody doing that would implement
>> the same for 32bit ints, both signed and unsigned. This would give
>> us even more real world experience.
>> 
>> (( Aahh, the Micro Forks releases! Man, we could speed up D
>> research and development! We'd multiply the speed, instead of
>> merely adding.
>> 
>> Why do you think open source runs circles around Bill, and even
>> Larry E? It's not that there are thousands of developers. It's that
>>  everyone gets the code to tinker with, doing his on pet peeve, or
>> his own dream. A lot of tiny springs make the Amazon.
>> 
>> We need them now, not when D is at 5.5.
>> 
>> Ha, the C++ Beards wouldn't even know what hit them, by that time
>> we'd be in Jupiter! ))
>> 
>> Actually, this could be done with my (still in planning ;-( ) "D preprocessor / D language lab / D meta language compiler". But,
>> alas, that's at least months away (if not Quarters). I wish I were
>> 30 years younger!
>> 
>> But more practical, sooner, and for the common good a lot better solution would really be the Micro Forks tinkering distro. (Be it Walter's, Anders', David's or somebody else's.)
>> 
>> -----------
>> 
>> A language that has the audacity to screw up thoroughly established
>>  practices ("bit" booleans, a serious language with GC, etc.
>> (disclaimer: IMHO the latter is good)), could very well be the one
>> forerunner with int-NANs.
>> 
>> _Somebody_ has to take the first step.
> 
> 
> 
April 20, 2005
Actually,  I would say just the opposite.

Fact is, there's no reason an "additional" data type couldn't become
a new standard representation for use in higher level languages and such...
as long as the underlying "base standard" is still supported.

As I mentioned, there are many such derived data types possible.  I think the real challange would be to come up with one that gets used enough to be considered a potential standard.

Hmmm... I like challanges.  Maybe some day, if I get the time.  :)  Would you mind?

TZ


"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4266E2BD.2070804@nospam.org...
> TechnoZeus wrote:
> > I think you missed the point.  The number 64 isn't arbitrary.  It's a function of the binary effect of the hardware's wiring.  Yes, you can do what ever you want with the data that fits in those 64 bits, but you need a way to know what they are first... and the standard 64 bit integer representations are there for that purpose.
>
> Oh, ok, I must be getting old and dumb.
>
> > "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:42669804.2060705@nospam.org...
> >
> >> Walter wrote:
> >>
> >>>> Is it possible at all to have the Old Farts, who hold the keys to Programming World, to become susceptible to our demands?
> >>>
> >>> LOL.
> >>
> >> Suppose the "over 60" bit type was actually 63 bits.
> >>
> >> How many would seriously start crying about 63 bits being seriously
> >>  deficient? Their opposition would surely suggest 127 bits for
> >> those purposes.
> >>
> >> Well now we would have 2^64 - 1 values. We lose one single value. A
> >>  national Disaster.
> >>
> >> And we'd lose this value _only_ in situations where we're dealing with a possibly uninitialized value.
> >>
> >> Not a huge loss, IMHO.
> >>
> >> The specific issue here is that "they" are so old, that they'd have a hard time noticing all of a sudden that we actually do have values to spare. Extending this thought, it should be equally hard to have them designate one single value for NAN even with 1024 bit integers. (Seriously.)
> >>
> >> I can see the worries of these guys. Traditionally a lot of code has been dependent on "integer" overflow hardware traps, wich have been extensively used when doing integer arithmetic wider than the accumulator in the processor.
> >>
> >> And even today, with all kinds of encryption getting increasingly important, that is not going to go away.
> >>
> >> I think this would not be hampered in any way with a compiler that initialises ints with this NAN value (in the cases where it can't immediately see for sure that the variable is assigned a value before first use).
> >>
> >> By the same token, at reading the value in all places where the compiler "knows" that the variable is already initialised, the NAN checks would not be done.
> >>
> >> -----
> >>
> >> While I'm not suggesting or demanding, I still write the following:
> >>
> >>
> >> (Oh, and don't anybody even think of D 1.0 here. This is purely
> >> academic at this stage.)
> >>
> >> There are several alternative things one could do here:
> >>
> >> 1) Suppose we create a new data type, called GuardedInt64. This type would always be checked against the NAN value upon retrieval. (A single machine instruction comparing with an immediate value. Not Enormously Slow.)
> >>
> >> 2) Or, we could decide that non-release builds check against NAN if
> >>  there is reason to be unsure whether the variable is already
> >> initialised. If the compiler can see that there is no danger of
> >> that, then it would not bother to check. (This NAN thing would also
> >> be switchable on the command line, and/or with a pragma.)
> >>
> >> 3) Or, in non-release code, for every int there could be a "shadow variable", whose purpose would only be to know whether the real variable was already initialised. (This would be slow, but hey, non-release code in D is already slower -- which is OK.) (The naïve implementation being that every time you write to your int, the shadow int gets written a 1. And every time you read yuor int, the shadow int gets checked for null. Null denoting that we have a read before any write.)
> >>
> >> 4-300) And probably hundreds of other variations. :-)
> >>
> >> -----------
> >>
> >> It's a shame that we don't yet have the Micro Forks releases (those
> >>  "Everyone Tinker Yourself Instead of Crowding the Newsgroup with
> >> Demands and Dreams" packages.)
> >>
> >> It would be so easy for someone to create a (for example) GuardedInt64 type, and let others use that particular compiler for a while, for some real-world experiences.
> >>
> >> With the same effort, probably anybody doing that would implement the same for 32bit ints, both signed and unsigned. This would give us even more real world experience.
> >>
> >> (( Aahh, the Micro Forks releases! Man, we could speed up D research and development! We'd multiply the speed, instead of merely adding.
> >>
> >> Why do you think open source runs circles around Bill, and even
> >> Larry E? It's not that there are thousands of developers. It's that
> >>  everyone gets the code to tinker with, doing his on pet peeve, or
> >> his own dream. A lot of tiny springs make the Amazon.
> >>
> >> We need them now, not when D is at 5.5.
> >>
> >> Ha, the C++ Beards wouldn't even know what hit them, by that time
> >> we'd be in Jupiter! ))
> >>
> >> Actually, this could be done with my (still in planning ;-( ) "D
> >> preprocessor / D language lab / D meta language compiler". But,
> >> alas, that's at least months away (if not Quarters). I wish I were
> >> 30 years younger!
> >>
> >> But more practical, sooner, and for the common good a lot better solution would really be the Micro Forks tinkering distro. (Be it Walter's, Anders', David's or somebody else's.)
> >>
> >> -----------
> >>
> >> A language that has the audacity to screw up thoroughly established
> >>  practices ("bit" booleans, a serious language with GC, etc.
> >> (disclaimer: IMHO the latter is good)), could very well be the one
> >> forerunner with int-NANs.
> >>
> >> _Somebody_ has to take the first step.
> >
> >
> >


5 6 7 8 9 10 11 12 13 14 15
Next ›   Last »