View mode: basic / threaded / horizontal-split · Log in · Help
April 20, 2005
Re: recoverable and unrecoverable errors or exceptions
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
Re: recoverable and unrecoverable errors or exceptions
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
Re: recoverable and unrecoverable errors or exceptions
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.
> >
> >
> >
Next ›   Last »
11 12 13 14 15
Top | Discussion index | About this forum | D home