>>>>> Yes. Are you saying that tags of "improper" types need not to be >>>>> handled >>>>> by the OS? (:-))
>>>> integer ranges to me seem more like a compiler hack, so the underlying >>>> type >>>> would likely just be a plain integer...
>>> There is no such thing like "underlying type" or "plain integer". If any >>> that is an implementation detail.
>> plain integer: >> in my case is given the letter 'i' and is defined as 32 bits. >> otherwise, it is 'x' and 64 bits, or 'n' and 128 bits.
> It is not an integer. Plain integer if any is such implements the set of > integer numbers. Yours does not.
integers hold however many values will fit in the bits...
>>> It is not only wrong to think in that, it is just wrong. Consider >>> modular >>> integer of the range 1..3. Again, type is a set of values and operations >>> defined on them, period. Nothing beyond that.
>> then, the integer "can" be 8 bits, but more likely is 32...
> It cannot be, since 2+2 = 1 (mod 4)
> This illustrates the principle. The type is a set of values and > operations. > The operations of the ring modulus 4 are sufficiently different from ones > of the ring 256 (if "8-bits" means modulus 2**8).
not really, all that has to happen is that the compiler inserts a hidden modulus operator or mask, and maybe some extra hidden logic.
same difference though...
>>> Yes, if the implementation is poor... (:-))
>> well, you see if you can figure out how to allocate things without using >> any >> memory...
> That depends on what has to be in the memory...
if certain types are runtime objects (such as classes), then necessarily they need to be in memory.
OTOH, unmanaged classes don't (necessarily) need runtime memory, but one can't create them dynamically either (since the class is a fixed part of the code to be compiled, and even templates/generics are fixed post-compile).
>>>>>> a class, for example, is a list of slots and methods. >>>>>> the only methods which can exist for a given class are those defined >>>>>> for >>>>>> this class, and they are physically located "within" the class.
>>>>> This model is wrong because it does not support multi-methods. The >>>>> relation in not 1 to n, as a matter of fact.
>>>> method overloading works fine, as each method has a different >>>> signature...
>>> Methods cannot be overloaded, per definition of. Unless you mean >>> something >>> else.
> OK, you mean overloaded name "foo". What was the point?
you were making the claim that structural equivalence (or whatever is currently being argued against) would not support multi-methods (which can be noted are more or less analogous to overloaded methods), which is incorrect, since method overloading clearly works with structural equivalence (only that, in a hidden way, the signature is regarded as a part of the name...).
On Wed, 24 Jun 2009 14:17:50 -0700, cr88192 wrote: > "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message > news:mv65ymz5j45s$.2vjcwt609bi6.dlg@40tude.net... >> On Wed, 24 Jun 2009 10:23:54 -0700, cr88192 wrote:
>>>>>> Yes. Are you saying that tags of "improper" types need not to be >>>>>> handled >>>>>> by the OS? (:-))
>>>>> integer ranges to me seem more like a compiler hack, so the underlying >>>>> type >>>>> would likely just be a plain integer...
>>>> There is no such thing like "underlying type" or "plain integer". If any >>>> that is an implementation detail.
>>> plain integer: >>> in my case is given the letter 'i' and is defined as 32 bits. >>> otherwise, it is 'x' and 64 bits, or 'n' and 128 bits.
>> It is not an integer. Plain integer if any is such implements the set of >> integer numbers. Yours does not.
> integers hold however many values will fit in the bits...
Integer hold integer values. Your "plain integer" is not an integer at all. Because if X is an integer, then any provable proposition about integer set holds for X. Take the proposition if X is integer then X+1 is integer. q.e.d.
The moral: You are using a model of integers. This model is inadequate. There are other competing models, which are inadequate as well. None is "better" than other, without further considerations. Therefore there is no "plain integers". Equivalently, there is no "plain number".
>>>> It is not only wrong to think in that, it is just wrong. Consider modular >>>> integer of the range 1..3. Again, type is a set of values and operations >>>> defined on them, period. Nothing beyond that.
>>> then, the integer "can" be 8 bits, but more likely is 32...
>> It cannot be, since 2+2 = 1 (mod 4)
>> This illustrates the principle. The type is a set of values and operations. >> The operations of the ring modulus 4 are sufficiently different from ones >> of the ring 256 (if "8-bits" means modulus 2**8).
> not really, all that has to happen is that the compiler inserts a hidden > modulus operator or mask, and maybe some extra hidden logic.
That is an irrelevant implementation detail.
>>>> Yes, if the implementation is poor... (:-))
>>> well, you see if you can figure out how to allocate things without using >>> any memory...
>> That depends on what has to be in the memory...
> if certain types are runtime objects (such as classes), then necessarily > they need to be in memory.
No. You don't need full descriptions of a class in the memory. That was the starting point: what would be possible to do in order to support RTTI. Note, not reflection, nor introspection, nor type marshaling. Only RTTI.
>>>>>>> a class, for example, is a list of slots and methods. >>>>>>> the only methods which can exist for a given class are those defined >>>>>>> for this class, and they are physically located "within" the class.
>>>>>> This model is wrong because it does not support multi-methods. The >>>>>> relation in not 1 to n, as a matter of fact.
>>>>> method overloading works fine, as each method has a different >>>>> signature...
>>>> Methods cannot be overloaded, per definition of. Unless you mean >>>> something >>>> else.
>> OK, you mean overloaded name "foo". What was the point?
> you were making the claim that structural equivalence (or whatever is > currently being argued against) would not support multi-methods (which can > be noted are more or less analogous to overloaded methods), which is > incorrect,
No, I claimed that you cannot have "class = list of slots for method". That is inconsistent with multi-methods.
> since method overloading clearly works with structural > equivalence (only that, in a hidden way, the signature is regarded as a part > of the name...).
That depends on the scope of the name:
declare procedure Foo is begin null; end Foo; begin declare procedure Foo is begin null; end Foo; begin null; end; end;
But I fail to see how this is relevant to run-time. Run-time just does not care about equivalence of the objects Foo and Foo.
>>>>>>> Yes. Are you saying that tags of "improper" types need not to be >>>>>>> handled >>>>>>> by the OS? (:-))
>>>>>> integer ranges to me seem more like a compiler hack, so the >>>>>> underlying >>>>>> type >>>>>> would likely just be a plain integer...
>>>>> There is no such thing like "underlying type" or "plain integer". If >>>>> any >>>>> that is an implementation detail.
>>>> plain integer: >>>> in my case is given the letter 'i' and is defined as 32 bits. >>>> otherwise, it is 'x' and 64 bits, or 'n' and 128 bits.
>>> It is not an integer. Plain integer if any is such implements the set of >>> integer numbers. Yours does not.
>> integers hold however many values will fit in the bits...
> Integer hold integer values. Your "plain integer" is not an integer at > all. > Because if X is an integer, then any provable proposition about integer > set > holds for X. Take the proposition if X is integer then X+1 is integer. > q.e.d.
int i; ... i=i+1;
always true (even when there is an overflow).
bounds-checked arithmetic and saturating arithmetic are possible though.
> The moral: You are using a model of integers. This model is inadequate. > There are other competing models, which are inadequate as well. None is > "better" than other, without further considerations. Therefore there is no > "plain integers". Equivalently, there is no "plain number".
they are called integers. int=32 bits.
then we use longs or int128 if we need more, or short or char/sbyte if we need less...
>>>>> It is not only wrong to think in that, it is just wrong. Consider >>>>> modular >>>>> integer of the range 1..3. Again, type is a set of values and >>>>> operations >>>>> defined on them, period. Nothing beyond that.
>>>> then, the integer "can" be 8 bits, but more likely is 32...
>>> It cannot be, since 2+2 = 1 (mod 4)
>>> This illustrates the principle. The type is a set of values and >>> operations. >>> The operations of the ring modulus 4 are sufficiently different from >>> ones >>> of the ring 256 (if "8-bits" means modulus 2**8).
>> not really, all that has to happen is that the compiler inserts a hidden >> modulus operator or mask, and maybe some extra hidden logic.
> That is an irrelevant implementation detail.
implementation detail?... then what the hell then is the rest of this thread?...
grr...
but, yes, as I see it, the implementation is primarily, and the conceptual model is secondary. we will still have the implementation even with no model, but we have no (or at least, no useful) model without the implementation.
>>>> well, you see if you can figure out how to allocate things without >>>> using >>>> any memory...
>>> That depends on what has to be in the memory...
>> if certain types are runtime objects (such as classes), then necessarily >> they need to be in memory.
> No. You don't need full descriptions of a class in the memory. That was > the > starting point: what would be possible to do in order to support RTTI. > Note, not reflection, nor introspection, nor type marshaling. Only RTTI.
RTTI, to work at all, needs at least a basic skeleton of the type-system and class heirarchy (in C++, this much is usually generated by the compiler).
but, for my framework, for it to operate much at all (given the nature of the project), much of this ends up existing in memory.
>>>>>>>> a class, for example, is a list of slots and methods. >>>>>>>> the only methods which can exist for a given class are those >>>>>>>> defined >>>>>>>> for this class, and they are physically located "within" the class.
>>>>>>> This model is wrong because it does not support multi-methods. The >>>>>>> relation in not 1 to n, as a matter of fact.
>>>>>> method overloading works fine, as each method has a different >>>>>> signature...
>>>>> Methods cannot be overloaded, per definition of. Unless you mean >>>>> something >>>>> else.
>>> OK, you mean overloaded name "foo". What was the point?
>> you were making the claim that structural equivalence (or whatever is >> currently being argued against) would not support multi-methods (which >> can >> be noted are more or less analogous to overloaded methods), which is >> incorrect,
> No, I claimed that you cannot have "class = list of slots for method". > That > is inconsistent with multi-methods.
?...
a class is: a list of fields; a list of methods; ...
>> since method overloading clearly works with structural >> equivalence (only that, in a hidden way, the signature is regarded as a >> part >> of the name...).
> That depends on the scope of the name:
> declare > procedure Foo is begin null; end Foo; > begin > declare > procedure Foo is begin null; end Foo; > begin > null; > end; > end;
> But I fail to see how this is relevant to run-time. Run-time just does not > care about equivalence of the objects Foo and Foo.
it depends on how ones' project is implemented.
my project lies on the border between a (traditional) compiler and a VM, and between a static and dynamic typesystem.
actually, a lot of it is "soft-static typing", AKA, the implementation is largely statically typed in many places, but the machinery is sufficiently flexible as to allow simulation of dynamically-typed behavior.
dynamic typing can be used in some places, but I try to use it less as it is less efficient (and is less "provable"...).
> > Another daft and possibly flameworthy question... :)
> > Has anyone ever attempted writing C++ RTTI support in an OS, if not in > > a kernel? I imagine it involves the creation of an "object header" of > > sorts in memory, in the implementation of the "new" operator's malloc > > routine. Sort of like the object headers in the runtimes for both Java > > and CLR.
> > Does anyone have any resources to read up on how to achieve this, or > > ideas on how to implement typeid & dynamic_cast? Thanks!
> GCC code, if you are interested and can read it :-
Quite useful, and somewhat readable. It's actually fairly close to what I thought had to be implemented. The rest of this thread seems to have been taken over. :) Thanks Aaron!
On Thu, 25 Jun 2009 08:29:34 -0700, cr88192 wrote: > "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message > news:z4pud70x3xae$.1ton4ahqn2jsx$.dlg@40tude.net... >> On Wed, 24 Jun 2009 14:17:50 -0700, cr88192 wrote:
>>>>>>>> Yes. Are you saying that tags of "improper" types need not to be >>>>>>>> handled >>>>>>>> by the OS? (:-))
>>>>>>> integer ranges to me seem more like a compiler hack, so the >>>>>>> underlying >>>>>>> type >>>>>>> would likely just be a plain integer...
>>>>>> There is no such thing like "underlying type" or "plain integer". If >>>>>> any >>>>>> that is an implementation detail.
>>>>> plain integer: >>>>> in my case is given the letter 'i' and is defined as 32 bits. >>>>> otherwise, it is 'x' and 64 bits, or 'n' and 128 bits.
>>>> It is not an integer. Plain integer if any is such implements the set of >>>> integer numbers. Yours does not.
>>> integers hold however many values will fit in the bits...
>> Integer hold integer values. Your "plain integer" is not an integer at all. >> Because if X is an integer, then any provable proposition about integer set >> holds for X. Take the proposition if X is integer then X+1 is integer. >> q.e.d.
> int i; > ... > i=i+1;
> always true (even when there is an overflow).
Are you kidding?
> bounds-checked arithmetic and saturating arithmetic are possible though.
Neither is the integer arithmetic. You consider them integer because you ignore how arithmetic operations are implemented there. That is exactly the point. If they are supposed to implement THE integer arithmetic then they are WRONG. Otherwise they implement something ELSE, i.e. it is not integer type.
>> The moral: You are using a model of integers. This model is inadequate. >> There are other competing models, which are inadequate as well. None is >> "better" than other, without further considerations. Therefore there is no >> "plain integers". Equivalently, there is no "plain number".
>>>>>> It is not only wrong to think in that, it is just wrong. Consider modular >>>>>> integer of the range 1..3. Again, type is a set of values and operations >>>>>> defined on them, period. Nothing beyond that.
>>>>> then, the integer "can" be 8 bits, but more likely is 32...
>>>> It cannot be, since 2+2 = 1 (mod 4)
>>>> This illustrates the principle. The type is a set of values and operations. >>>> The operations of the ring modulus 4 are sufficiently different from >>>> ones of the ring 256 (if "8-bits" means modulus 2**8).
>>> not really, all that has to happen is that the compiler inserts a hidden >>> modulus operator or mask, and maybe some extra hidden logic.
>> That is an irrelevant implementation detail.
> implementation detail?...
Yes, an irrelevant to the issue what is the type.
> then what the hell then is the rest of this thread?...
It was about types and their equivalence.
> but, yes, as I see it, the implementation is primarily, and the conceptual model is secondary.
No the model is primary, its implementation is of no interest. In the context of type equivalence, the implementation is strictly irrelevant. The same type can be implemented differently at the *same* machine in the *same* program.
> we will still have the implementation even with no model, but we have no (or > at least, no useful) model without the implementation.
Implementation without model is garbage, just because you don't know what it does implement.
>> No, I claimed that you cannot have "class = list of slots for method". That >> is inconsistent with multi-methods.
> ?...
> a class is: > a list of fields; > a list of methods; > ...
>>> since method overloading clearly works with structural >>> equivalence (only that, in a hidden way, the signature is regarded as a >>> part of the name...).
>> That depends on the scope of the name:
>> declare >> procedure Foo is begin null; end Foo; >> begin >> declare >> procedure Foo is begin null; end Foo; >> begin >> null; >> end; >> end;
>> But I fail to see how this is relevant to run-time. Run-time just does not >> care about equivalence of the objects Foo and Foo.
> it depends on how ones' project is implemented.
If you put forward an existing implementation. But the question was how RTTI could/should be, rather than how it is.
Scott Balmos wrote: > Quite useful, and somewhat readable. It's actually fairly close to > what I thought had to be implemented. The rest of this thread seems to > have been taken over. :) Thanks Aaron!
Itanium C++ ABI [1] may be very useful (apart from gcc and its additional libraries source code) while implementing any runtime routines for C++.
>>>>>>>>> Yes. Are you saying that tags of "improper" types need not to be >>>>>>>>> handled >>>>>>>>> by the OS? (:-))
>>>>>>>> integer ranges to me seem more like a compiler hack, so the >>>>>>>> underlying >>>>>>>> type >>>>>>>> would likely just be a plain integer...
>>>>>>> There is no such thing like "underlying type" or "plain integer". If >>>>>>> any >>>>>>> that is an implementation detail.
>>>>>> plain integer: >>>>>> in my case is given the letter 'i' and is defined as 32 bits. >>>>>> otherwise, it is 'x' and 64 bits, or 'n' and 128 bits.
>>>>> It is not an integer. Plain integer if any is such implements the set >>>>> of >>>>> integer numbers. Yours does not.
>>>> integers hold however many values will fit in the bits...
>>> Integer hold integer values. Your "plain integer" is not an integer at >>> all. >>> Because if X is an integer, then any provable proposition about integer >>> set >>> holds for X. Take the proposition if X is integer then X+1 is integer. >>> q.e.d.
>> int i; >> ... >> i=i+1;
>> always true (even when there is an overflow).
> Are you kidding?
if integer means: scalar with no fractional part.
then an integer is an integer. even overflow does not add a fractional part or require changing the type, so all is well...
>> bounds-checked arithmetic and saturating arithmetic are possible though.
> Neither is the integer arithmetic. You consider them integer because you > ignore how arithmetic operations are implemented there. That is exactly > the > point. If they are supposed to implement THE integer arithmetic then they > are WRONG. Otherwise they implement something ELSE, i.e. it is not integer > type.
none has a fractional part...
if you mean unbounded range, well maybe, but that is a different issue, and can't be practically solved.
VLIs can help though (I use these sometimes...). but, a VLI is still limited to whatever type is used to implement the arithmetic, even if storage takes less...
>>> The moral: You are using a model of integers. This model is inadequate. >>> There are other competing models, which are inadequate as well. None is >>> "better" than other, without further considerations. Therefore there is >>> no >>> "plain integers". Equivalently, there is no "plain number".
>> they are called integers.
> They are not. They are called *machine numbers*.
you call them that.
most people call them integers (though usually with a size qualifier...).
it is like how floats are also called floats, but have little real relation to either water or concrete...
I guess byte/word/dword/qword/... could also be used, but these are usually considered ASM-specific...
>>>>>>> It is not only wrong to think in that, it is just wrong. Consider >>>>>>> modular >>>>>>> integer of the range 1..3. Again, type is a set of values and >>>>>>> operations >>>>>>> defined on them, period. Nothing beyond that.
>>>>>> then, the integer "can" be 8 bits, but more likely is 32...
>>>>> It cannot be, since 2+2 = 1 (mod 4)
>>>>> This illustrates the principle. The type is a set of values and >>>>> operations. >>>>> The operations of the ring modulus 4 are sufficiently different from >>>>> ones of the ring 256 (if "8-bits" means modulus 2**8).
>>>> not really, all that has to happen is that the compiler inserts a >>>> hidden >>>> modulus operator or mask, and maybe some extra hidden logic.
>>> That is an irrelevant implementation detail.
>> implementation detail?...
> Yes, an irrelevant to the issue what is the type.
type is what type is. if the type is a 32 bit integer, the type is a 32 bit integer. that is how the type is usually defined...
one types 'int', they usually expect 32 bits.
>> then what the hell then is the rest of this thread?...
> It was about types and their equivalence.
yes, ok.
none the less, i=i, l=l, x=x, ...
i!=x, because 32bits!=64bits...
>> but, yes, as I see it, the implementation is primarily, and the >> conceptual model is secondary.
> No the model is primary, its implementation is of no interest. In the > context of type equivalence, the implementation is strictly irrelevant. > The > same type can be implemented differently at the *same* machine in the > *same* program.
this makes little sense, things are not done this way...
when we say we have a type (say, a 64-bit double), we expect a 64 bit double. to do otherwise is in error...
when we say a struct is layed out a certain way, we can assume that it is layed out as defined, otherwise, again, this is in error...
>> we will still have the implementation even with no model, but we have no >> (or >> at least, no useful) model without the implementation.
> Implementation without model is garbage, just because you don't know what > it does implement.
we have ASM without C; we have the CPU without ASM; we have physics without the CPU; ...
just because people don't know something does not mean it is not there... even if everyone and everything were dead (and thus, no ideas or models), rocks/light/... would remain.
>>>> since method overloading clearly works with structural >>>> equivalence (only that, in a hidden way, the signature is regarded as a >>>> part of the name...).
>>> That depends on the scope of the name:
>>> declare >>> procedure Foo is begin null; end Foo; >>> begin >>> declare >>> procedure Foo is begin null; end Foo; >>> begin >>> null; >>> end; >>> end;
>>> But I fail to see how this is relevant to run-time. Run-time just does >>> not >>> care about equivalence of the objects Foo and Foo.
>> it depends on how ones' project is implemented.
> If you put forward an existing implementation. But the question was how > RTTI could/should be, rather than how it is.
I am not sure I see the distinction.
things are how things are, granted possibilities are possible, one is bound, inherently, to one of any number of possible implementations.
now, as for how one implements dynamic cast, one can make some generalizations:
dynamic_cast<classname> classinstance
since we know already that the value is an class-instance, all we have to do is verify (at runtime) that the instance is a compatible class.
if we are casting up the heirarchy, than in most cases this can be degenerated to a normal cast. if the classes are unrelated, then a warning or error may be appropriate (compiler may then treat it like a downwards cast, or reject the code).
in other cases, rejection or type-checking can be done as appropriate.
in this case, signature checking should not be necessary (and would not likely produce the correct information anyways).
the IA-64 ABI uses special info embedded in the object files (basically, a bunch of linked structures standing in for the class heirarchy...). the JVM uses the class heirarchy directly (internally via use of several special opcodes).
my approach is to do how I normally do other things in my compiler+object system: the compiler produces references to special "magic functions" (basically, link-time generated code), which would serve to return the class handle in question, and probably another intrinsic to do the check.
then again, I could merge them, thus giving me something analogous to the JVM's "instanceof" opcode.
internally, when generating the code (link-time), it requests info (such as the class handle) from the object system, and may generate a call into the object system for completing certain tasks (later, I may make the system tighter-integrated, such that the automatic code generation generates the code to implement tasks directly, rather than redirecting many of them into internal API calls...).
for checking inheritence, my system first checks the classes via a special hash table, and failing this, walks the heirarchy.
the reason I will not, as of yet, directly generate code to perform certain tasks, is that this will essentially lock down the internals of the object system, as well as possibly the physical layout of objects. a partial solution here would be to allow many classes to be declared "immutable" (basically, telling the object system that no runtime modification of the class layout will take place), allowing these classes to have more efficient code be generated (such as accessing a field being a single 'lea' instruction), but at the cost that altering the layout would break running code (that or make use of special linker/code generation ninjitsu...).
but, accessing the field with the current approach in within the 2-digit clock cycles range, so for now it is probably good enough...
cr88192 wrote: > then an integer is an integer. > even overflow does not add a fractional part or require changing the type, > so all is well...
If there is an overflow it is an undefined behavior (C++03 5/5).
> type is what type is. > if the type is a 32 bit integer, the type is a 32 bit integer. > that is how the type is usually defined...
> one types 'int', they usually expect 32 bits.
Not really. C/C++ programmer should expect 'int' to "have the natural size suggested by the architecture of the execution environment", which not always equals 32 bits.
>> Implementation without model is garbage, just because you don't know what >> it does implement.
> we have ASM without C; > we have the CPU without ASM; > we have physics without the CPU; > ... > just because people don't know something does not mean it is not there... > even if everyone and everything were dead (and thus, no ideas or models), > rocks/light/... would remain.
Even if you know something that does not mean that it is good to depend on it. Specification tells you what you can do, implementation makes it possible. If you start to take advantage of implementation details then your code may become incompatible with the specification.
> cr88192 wrote: >> then an integer is an integer. >> even overflow does not add a fractional part or require changing the >> type, >> so all is well...
> If there is an overflow it is an undefined behavior (C++03 5/5).
technically, maybe... usually this "undefined behavior" is simply to wrap around though...
>> type is what type is. >> if the type is a 32 bit integer, the type is a 32 bit integer. >> that is how the type is usually defined...
>> one types 'int', they usually expect 32 bits.
> Not really. C/C++ programmer should expect 'int' to "have the natural > size suggested by the architecture of the execution environment", which > not always equals 32 bits.
in practice, on current computers, it is de-facto defined as 32 bits.
>>> Implementation without model is garbage, just because you don't know >>> what >>> it does implement.
>> we have ASM without C; >> we have the CPU without ASM; >> we have physics without the CPU; >> ... >> just because people don't know something does not mean it is not there... >> even if everyone and everything were dead (and thus, no ideas or models), >> rocks/light/... would remain.
> Even if you know something that does not mean that it is good to depend > on it. Specification tells you what you can do, implementation makes it > possible. If you start to take advantage of implementation details then > your code may become incompatible with the specification.
typically, the specification and implementation are closely linked.
it makes little sense to consider that the specification is somehow isolated from the implementation...
it makes about as much sense and then regarding their use by humans as an "implementation detail"...
anyways, as I see it, a specification is a description of an implementation, or an abstraction over, an implementation. a specification is in no way "more fundamental" than the implementation, only that it makes it easier to gloss over the details, and allow multiple possible implementation strategies to be in use.
people speaking of "implementation detail" as a prejorative just annoys me though.
it is the implementation which is the real part, and a specification is little more than formalisms...
specifying something, similarly, does no good if it is not possible to implement it effectively.
On Thu, 25 Jun 2009 10:58:38 -0700, cr88192 wrote: > "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message > news:896rus71oc2k.1nk85oajodq9x$.dlg@40tude.net... >> On Thu, 25 Jun 2009 08:29:34 -0700, cr88192 wrote:
>> Are you kidding?
> if integer means: > scalar with no fractional part.
No, one usually expects a reference in the language or compiler manual which describes the semantics of int. A description there defines the type, of which name is int.
>>> but, yes, as I see it, the implementation is primarily, and the >>> conceptual model is secondary.
>> No the model is primary, its implementation is of no interest. In the >> context of type equivalence, the implementation is strictly irrelevant. The >> same type can be implemented differently at the *same* machine in the >> *same* program.
> this makes little sense, things are not done this way...
Of course they are. Our software works with many numeric models at once, because it communicates with sensors and actuators deploying a great variety of numeric representations.
> when we say we have a type (say, a 64-bit double), we expect a 64 bit > double.
64-bit double has no meaning. There exist a dozen of floating-point representations of 64-bit length.
> just because people don't know something does not mean it is not there...
Regarding programs it means exactly this. A program without a specification is a random collection of bits. The purpose of a program cannot be determined. This is a hard mathematical fact (see halting problem).
yes, but "real" is not "float". "float" represents "real", none the less, the term is different, so in the same way your objection to "integer" is pointless...
it might have some validity if "float" were somehow realted to water or concrete, however...
>> one types 'int', they usually expect 32 bits.
> No, one usually expects a reference in the language or compiler manual > which describes the semantics of int. A description there defines the > type, > of which name is int.
most code for maybe about the past decade has expected 'int' to be 32 bits. before this, much code was around which expected it to be 16 bits...
>>>> but, yes, as I see it, the implementation is primarily, and the >>>> conceptual model is secondary.
>>> No the model is primary, its implementation is of no interest. In the >>> context of type equivalence, the implementation is strictly irrelevant. >>> The >>> same type can be implemented differently at the *same* machine in the >>> *same* program.
>> this makes little sense, things are not done this way...
> Of course they are. Our software works with many numeric models at once, > because it communicates with sensors and actuators deploying a great > variety of numeric representations.
yet, I don't have to "know" much about any of these, and yet they still keep working despite this...
FWIW, my "conceptual model" of most of this crap is pointless, it is the implementation which makes it work...
>> when we say we have a type (say, a 64-bit double), we expect a 64 bit >> double.
> 64-bit double has no meaning. There exist a dozen of floating-point > representations of 64-bit length.
yet, only a few that we can bother to care about, this is besides the point...
>> just because people don't know something does not mean it is not there...
> Regarding programs it means exactly this. A program without a > specification > is a random collection of bits. The purpose of a program cannot be > determined. This is a hard mathematical fact (see halting problem).
no, we just will be sitting around stupidly looking at something and not knowing how it works...
by this reasoning, because for most of human history, no one had any damn idea about DNA, does this mean that humans could not exist?...
humans were around, and maybe had almost no idea about "how" they exist, only that they did. similarly, many people had some rather stupid ideas about biology (such that parents physically contained all of their offspring and all future generations, at the same time, or for that matter, spontaneous generation...).
yet, all the same, people continued to exist.
similarly, physics works even though, throughout history, people didn't know their physics either... the "implementations" existed, but there was no "conceptual model". humans figured out all this crap through figuring it out...
thus "existence" / "the implementation" is primary, and "the model" is secondary.
referencing the halting problem here is, also, pointless...
On Thu, 25 Jun 2009 16:23:39 -0700, cr88192 wrote: > "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message > news:12v66dbfgzpen.1j9hqvpsci4bp.dlg@40tude.net... >> On Thu, 25 Jun 2009 10:58:38 -0700, cr88192 wrote:
> yes, but "real" is not "float". > "float" represents "real", none the less, the term is different, so in the > same way your objection to "integer" is pointless...
"float" is an abbreviation of "floating-point", which refers to a representation of real in the form:
Fraction * Radix ** Exponent
where fraction is usually normalized.
>>> one types 'int', they usually expect 32 bits.
>> No, one usually expects a reference in the language or compiler manual >> which describes the semantics of int. A description there defines the >> type, of which name is int.
> most code for maybe about the past decade has expected 'int' to be 32 bits. > before this, much code was around which expected it to be 16 bits...
Broken code. Every decent programming guide line on C/C++ requires an explicit use of int32 (or equivalent) when the program requires the corresponding range of values.
> FWIW, my "conceptual model" of most of this crap is pointless, it is the > implementation which makes it work...
How do you know if it does? Heard anything about testing, verification and validation?
>>> when we say we have a type (say, a 64-bit double), we expect a 64 bit >>> double.
>> 64-bit double has no meaning. There exist a dozen of floating-point >> representations of 64-bit length.
> yet, only a few that we can bother to care about, this is besides the > point...
How do you identify these "few"?
> by this reasoning, because for most of human history, no one had any damn > idea about DNA, does this mean that humans could not exist?...
You are confusing the program with its medium and the execution platform.
> thus "existence" / "the implementation" is primary, and "the model" is > secondary. > referencing the halting problem here is, also, pointless...
It is not a reference, it is a proof. You cannot create a program which could tell the purpose of other programs.
"Existence" without specifying what does exist is either tautology or else meaningless. So any formal system either postulates existence of certain entities axiomatically, otherwise it proves existence *after* defining what is we are looking for. There is no third way.
So either you specify your program and them prove, verify etc, that the junk of bits is indeed the thing, or else you just present that garbage as-is giving your word that it is, well, is. (The customer must be happy, with that.)
cr88192 wrote: > in practice, on current computers, it is de-facto defined as 32 bits.
The fact that in most cases sizeof(int) equals 4 doesn't mean that you should expect it on all hardware architectures (e.g. gcc makes int 16 bit on AVR). AFAIK char is 9 bits on PDP-10, so even though sizeof(int) is 4, int is 36 bits. That's not common situation (only if you concentrate on PCs), but if one doesn't make such assumptions it will be possible to easily port programs to other architectures.
> anyways, as I see it, a specification is a description of an implementation, > or an abstraction over, an implementation. a specification is in no way > "more fundamental" than the implementation, only that it makes it easier to > gloss over the details, and allow multiple possible implementation > strategies to be in use.
> people speaking of "implementation detail" as a prejorative just annoys me > though.
> it is the implementation which is the real part, and a specification is > little more than formalisms...
Specification is an abstract. I think it can be compared to interfaces in OOP. In general it is always better to depend only on interface (or specification) instead of implementation. Even if the latter changes, code may not require any corrections. The other reason why it is vital to base on language specification is that, for example C++, still evolves. Even though everybody is trying to keep backward compatibility, they rather don't bother thinking about UDs. In other words, new version of the standard might force implementation to change behavior that is not covered by the specification.
> On Thu, 25 Jun 2009 10:58:38 -0700, cr88192 wrote: > > "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message > > news:896rus71oc2k.1nk85oajodq9x$.dlg@40tude.net... > >> On Thu, 25 Jun 2009 08:29:34 -0700, cr88192 wrote:
> > if integer means: > > scalar with no fractional part.
OK. You two have been going back and forth on this long enough. That link is "integer" as defined by mathematics. Right at the top it directs you to another definition of "integer" as defined by computer science...: http://en.wikipedia.org/wiki/Integer_(computer_science)
The C and C++ standards also _imply_ the definition of integers also. They can't explicitly define what they are, although the language appears to do so - it actually doesn't, since the standards are abstracted from real systems. That is they can't require int's or integers to be signed or unsigned, or a certain size, or one's or two's complement. Some cpu architecture might not have signed integers, even though an "int" in C has historically been a signed value and most cpu architectures since the mid-70's do have signed integers. So, the language strongly implies an int is signed, but it can't require it. That's the problem with abstracting a model from implementation: nothing can be required.
A byte has been 8-bits since Bob "The Father of ASCII" Bemer standardized 8-bit groupings, and Dr. Werner Buchholz coined the term "byte" in 1960. However, the C specification in 1989 redefined a byte to be something else (for portability). So, there is a whole group of people who don't understand that a byte is 8-bits because their reference definition is something else.
> cr88192 wrote: >> in practice, on current computers, it is de-facto defined as 32 bits.
> The fact that in most cases sizeof(int) equals 4 doesn't mean that you > should expect it on all hardware architectures (e.g. gcc makes int 16 > bit on AVR). AFAIK char is 9 bits on PDP-10, so even though sizeof(int) > is 4, int is 36 bits. That's not common situation (only if you > concentrate on PCs), but if one doesn't make such assumptions it will be > possible to easily port programs to other architectures.
whoever brought up universal portability?...
the usual idea is this: a person as 1..N targets they actually care about (usually in decreasing order), past this point, they could care less...
as such, although "some" architectures may have a quirk/issue/... if it is not in the N they care about, they are not likely to care.
"well, on the z80 and m68k there is 'this' particular issue?..." "who cares?... the targets are x86, x86-64, and PPC...".
>> anyways, as I see it, a specification is a description of an >> implementation, >> or an abstraction over, an implementation. a specification is in no way >> "more fundamental" than the implementation, only that it makes it easier >> to >> gloss over the details, and allow multiple possible implementation >> strategies to be in use.
>> people speaking of "implementation detail" as a prejorative just annoys >> me >> though.
>> it is the implementation which is the real part, and a specification is >> little more than formalisms...
> Specification is an abstract. I think it can be compared to interfaces > in OOP. In general it is always better to depend only on interface (or > specification) instead of implementation. Even if the latter changes, > code may not require any corrections. > The other reason why it is vital to base on language specification is > that, for example C++, still evolves. Even though everybody is trying to > keep backward compatibility, they rather don't bother thinking about > UDs. In other words, new version of the standard might force > implementation to change behavior that is not covered by the > specification.
I was not saying that people should ignore the generalities and only target specific implementations, rather, that what IS the underlying implementation should not be ignored.
it would be like if an engineer designed structures, only to have them collapse later, since they regard it as a mere "implementation detail" that a steel cable does not have a tensile strength of 1000000 lbs or a melting poing greater than 2000F...
then they refuse to acknowledge the complaints of the contractors that the design is absurd and that "all these trivial details" will prevent it from working as desired...
>> yes, but "real" is not "float". >> "float" represents "real", none the less, the term is different, so in >> the >> same way your objection to "integer" is pointless...
> "float" is an abbreviation of "floating-point", which refers to a > representation of real in the form:
> Fraction * Radix ** Exponent
> where fraction is usually normalized.
yes, but alas, none of this is water or concrete, for which the word "float" implies (you can "float" a boat, or use the "float" to level the concrete slab).
otherwise, one need not bother arguing about the difference between 'integer' in computers, and 'integer' in mathematics, and simply note that, in the case of computers, integers do not hold the complete set of integers.
>>>> one types 'int', they usually expect 32 bits.
>>> No, one usually expects a reference in the language or compiler manual >>> which describes the semantics of int. A description there defines the >>> type, of which name is int.
>> most code for maybe about the past decade has expected 'int' to be 32 >> bits. >> before this, much code was around which expected it to be 16 bits...
> Broken code. Every decent programming guide line on C/C++ requires an > explicit use of int32 (or equivalent) when the program requires the > corresponding range of values.
but, really, why does this matter?... after all, code can be edited easily enough...
>> FWIW, my "conceptual model" of most of this crap is pointless, it is the >> implementation which makes it work...
> How do you know if it does? Heard anything about testing, verification and > validation?
one can test, but this tests that the code is not broke, and says nothing about the universal ontology...
>>>> when we say we have a type (say, a 64-bit double), we expect a 64 bit >>>> double.
>>> 64-bit double has no meaning. There exist a dozen of floating-point >>> representations of 64-bit length.
>> yet, only a few that we can bother to care about, this is besides the >> point...
> How do you identify these "few"?
we know them because we know them, it does not exactly require a lot of thinking to figure these things out...
>> by this reasoning, because for most of human history, no one had any damn >> idea about DNA, does this mean that humans could not exist?...
> You are confusing the program with its medium and the execution platform.
the "program" IS the "medium and execution platform"...
it just happens to be the case that source code happens to be easy to transport and mechanically translate (AKA: compile...).
>> thus "existence" / "the implementation" is primary, and "the model" is >> secondary.
>> referencing the halting problem here is, also, pointless...
> It is not a reference, it is a proof. You cannot create a program which > could tell the purpose of other programs.
it is not necessary to do so in the first place.
> "Existence" without specifying what does exist is either tautology or else > meaningless. So any formal system either postulates existence of certain > entities axiomatically, otherwise it proves existence *after* defining > what > is we are looking for. There is no third way.
we know what exists, as it is already there, and simply requires looking at it enough to know how to best describe what is already there...
people study what exists, and people make new things, which then proceed to exist as well... (now, whether anything new is "created" is itself debatable, as it would all be said to just be an elaborate combination of patterns and internal reorganizations).
> So either you specify your program and them prove, verify etc, that the > junk of bits is indeed the thing, or else you just present that garbage > as-is giving your word that it is, well, is. (The customer must be happy, > with that.)
On Sat, 27 Jun 2009 14:49:57 -0700, cr88192 wrote: > "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message > news:rsxktggkb2wi.1cv48nzcbggs3.dlg@40tude.net... >> On Thu, 25 Jun 2009 16:23:39 -0700, cr88192 wrote:
> at this point, one can simply say that intergers (in computers) are a finite > bounded subset of the integer space...
Wrong. A bounded subset of Z is not Z. That is the whole point.
When we talk about the integer type, we mean Z and operations defined on it. Take anything out, and the result will be another type, not integer. You can call in "int", bounded int, whatever, but that is not integer, it has properties different from Z, like that (2**32 - 1) + 1 /= 2**32.
> otherwise, one need not bother arguing about the difference between > 'integer' in computers, and 'integer' in mathematics, and simply note that, > in the case of computers, integers do not hold the complete set of integers.
Wrong. Computer integers are exactly same as in mathematics. Computer "int" as a type can be (and is) perfectly described mathematically. The resulting mathematical structure is not of Z, yet it is a perfectly mathematical structure.
>>>>> one types 'int', they usually expect 32 bits.
>>>> No, one usually expects a reference in the language or compiler manual >>>> which describes the semantics of int. A description there defines the >>>> type, of which name is int.
>>> most code for maybe about the past decade has expected 'int' to be 32 bits. >>> before this, much code was around which expected it to be 16 bits...
>> Broken code. Every decent programming guide line on C/C++ requires an >> explicit use of int32 (or equivalent) when the program requires the >> corresponding range of values.
> but, really, why does this matter?... > after all, code can be edited easily enough...
I don't understand this remark.
>>> FWIW, my "conceptual model" of most of this crap is pointless, it is the >>> implementation which makes it work...
>> How do you know if it does? Heard anything about testing, verification and >> validation?
> one can test, but this tests that the code is not broke, and says nothing > about the universal ontology...
How do you test without specifications? What do you test without specifying it?
>>>>> when we say we have a type (say, a 64-bit double), we expect a 64 bit >>>>> double.
>>>> 64-bit double has no meaning. There exist a dozen of floating-point >>>> representations of 64-bit length.
>>> yet, only a few that we can bother to care about, this is besides the >>> point...
>> How do you identify these "few"?
> we know them because we know them, it does not exactly require a lot of > thinking to figure these things out...
So what does "double" mean without "lot of thinking"?
>>> by this reasoning, because for most of human history, no one had any damn >>> idea about DNA, does this mean that humans could not exist?...
>> You are confusing the program with its medium and the execution platform.
> the "program" IS the "medium and execution platform"...
Nonsense. A program can be printed on paper, painted on a T-shirt, represented by a composition of used beer cans...
>> "Existence" without specifying what does exist is either tautology or else >> meaningless. So any formal system either postulates existence of certain >> entities axiomatically, otherwise it proves existence *after* defining >> what is we are looking for. There is no third way.
> we know what exists, as it is already there, and simply requires looking at > it enough to know how to best describe what is already there...
>> at this point, one can simply say that intergers (in computers) are a >> finite >> bounded subset of the integer space...
> Wrong. A bounded subset of Z is not Z. That is the whole point.
> When we talk about the integer type, we mean Z and operations defined on > it. Take anything out, and the result will be another type, not integer. > You can call in "int", bounded int, whatever, but that is not integer, it > has properties different from Z, like that (2**32 - 1) + 1 /= 2**32.
>> otherwise, one need not bother arguing about the difference between >> 'integer' in computers, and 'integer' in mathematics, and simply note >> that, >> in the case of computers, integers do not hold the complete set of >> integers.
> Wrong. Computer integers are exactly same as in mathematics. Computer > "int" > as a type can be (and is) perfectly described mathematically. The > resulting > mathematical structure is not of Z, yet it is a perfectly mathematical > structure.
close enough, and it is traditionally called 'int' or 'integer' either way...
to do anything differently is a violation of long-held and authoritative programmer tradition.
>>>>>> one types 'int', they usually expect 32 bits.
>>>>> No, one usually expects a reference in the language or compiler manual >>>>> which describes the semantics of int. A description there defines the >>>>> type, of which name is int.
>>>> most code for maybe about the past decade has expected 'int' to be 32 >>>> bits. >>>> before this, much code was around which expected it to be 16 bits...
>>> Broken code. Every decent programming guide line on C/C++ requires an >>> explicit use of int32 (or equivalent) when the program requires the >>> corresponding range of values.
>> but, really, why does this matter?... >> after all, code can be edited easily enough...
> I don't understand this remark.
if code only works in one case, and can be edited to work in another, it is thus not "broken"... one can argue, why does it matter, if one can just edit it and make it work as-needed?...
>>>> FWIW, my "conceptual model" of most of this crap is pointless, it is >>>> the >>>> implementation which makes it work...
>>> How do you know if it does? Heard anything about testing, verification >>> and >>> validation?
>> one can test, but this tests that the code is not broke, and says nothing >> about the universal ontology...
> How do you test without specifications? What do you test without > specifying > it?
one tests for behaviors, and that nothing "out of place" happens.
none the less, it is the combination of the code and implementation that defines the "reality" of the matter (it runs, and we see the results, ...).
editing and testing thus forges it more into what we want it to be and do, and as it so happens, code is not too difficult to edit.
>>>>>> when we say we have a type (say, a 64-bit double), we expect a 64 bit >>>>>> double.
>>>>> 64-bit double has no meaning. There exist a dozen of floating-point >>>>> representations of 64-bit length.
>>>> yet, only a few that we can bother to care about, this is besides the >>>> point...
>>> How do you identify these "few"?
>> we know them because we know them, it does not exactly require a lot of >> thinking to figure these things out...
> So what does "double" mean without "lot of thinking"?
IEEE 754 / IEEE 754r
it also means that the CPU architecture is x86, x86-64, or (maybe) PPC...
since the CPU does something a certain way, the CPU is the authority for what is double. since given CPU types are in common use, they are the authority. given the dependence of the existing software base on particular CPUs, the software base gives the CPU authority. the mass of users/developers/... give the software authority. ...
it is much like how a governments/... are composed of large numbers of individuals, and thus become the rightful authority over the lives and behaviors of said individuals...
>>>> by this reasoning, because for most of human history, no one had any >>>> damn >>>> idea about DNA, does this mean that humans could not exist?...
>>> You are confusing the program with its medium and the execution >>> platform.
>> the "program" IS the "medium and execution platform"...
> Nonsense. A program can be printed on paper, painted on a T-shirt, > represented by a composition of used beer cans...
these are different representations, and due to their difference in representation, are essentially different entities.
only that it is possible to convert from one representation to another.
for example, source code and machine code are different simply by a matter of translation, yet the compiled program is a different entity from the source representation of the program.
the machine code version is more solidly connected to existence than is the source-code, but the source code is anchored into existence in large part because of the existence of compilers.
both exist in large part due to the existence of CPU's and hard drives, ...
>>> "Existence" without specifying what does exist is either tautology or >>> else >>> meaningless. So any formal system either postulates existence of certain >>> entities axiomatically, otherwise it proves existence *after* defining >>> what is we are looking for. There is no third way.
>> we know what exists, as it is already there, and simply requires looking >> at >> it enough to know how to best describe what is already there...
On Sun, 28 Jun 2009 06:52:58 -0700, cr88192 wrote: > "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message > news:1cwr1of458xeo.1q0n62ber19cp.dlg@40tude.net... >> Wrong. Computer integers are exactly same as in mathematics. Computer "int" >> as a type can be (and is) perfectly described mathematically. The resulting >> mathematical structure is not of Z, yet it is a perfectly mathematical >> structure.
> close enough, and it is traditionally called 'int' or 'integer' either way...
> to do anything differently is a violation of long-held and authoritative > programmer tradition.
I never heard about such. Maybe you meant a tradition of buffer overruns in C programs? Anyway, no tradition can serve as an excuse for ignorance.
>>>>>>> one types 'int', they usually expect 32 bits.
>>>>>> No, one usually expects a reference in the language or compiler manual >>>>>> which describes the semantics of int. A description there defines the >>>>>> type, of which name is int.
>>>>> most code for maybe about the past decade has expected 'int' to be 32 bits. >>>>> before this, much code was around which expected it to be 16 bits...
>>>> Broken code. Every decent programming guide line on C/C++ requires an >>>> explicit use of int32 (or equivalent) when the program requires the >>>> corresponding range of values.
>>> but, really, why does this matter?... >>> after all, code can be edited easily enough...
>> I don't understand this remark.
> if code only works in one case, and can be edited to work in another, it is > thus not "broken"...
This is called "fixing broken code".
If the code weren't broken there would be no need to fix it. If it were designed properly in first place, e.g. following C/C++ guide lines and elementary common sense, you would not need to fix this kind of errors.
>>>>> FWIW, my "conceptual model" of most of this crap is pointless, it is the >>>>> implementation which makes it work...
>>>> How do you know if it does? Heard anything about testing, verification >>>> and validation?
>>> one can test, but this tests that the code is not broke, and says nothing >>> about the universal ontology...
>> How do you test without specifications? What do you test without >> specifying it?
> one tests for behaviors, and that nothing "out of place" happens.
How "behaviours" and "out of place" are specified? Note the word "specified".
> none the less, it is the combination of the code and implementation that > defines the "reality" of the matter (it runs, and we see the results, ...).
>>>>>>> when we say we have a type (say, a 64-bit double), we expect a 64 bit >>>>>>> double.
>>>>>> 64-bit double has no meaning. There exist a dozen of floating-point >>>>>> representations of 64-bit length.
>>>>> yet, only a few that we can bother to care about, this is besides the >>>>> point...
>>>> How do you identify these "few"?
>>> we know them because we know them, it does not exactly require a lot of >>> thinking to figure these things out...
>> So what does "double" mean without "lot of thinking"?
> IEEE 754 / IEEE 754r
> it also means that the CPU architecture is x86, x86-64, or (maybe) PPC... > since the CPU does something a certain way, the CPU is the authority for > what is double.
So, how are you talking about "double" without mentioning the CPU? What are you talking about? About CPU? Mass culture? Program? In the program, you have:
#define double char*
what is double?
>>>>> by this reasoning, because for most of human history, no one had any >>>>> damn >>>>> idea about DNA, does this mean that humans could not exist?...
>>>> You are confusing the program with its medium and the execution >>>> platform.
>>> the "program" IS the "medium and execution platform"...
>> Nonsense. A program can be printed on paper, painted on a T-shirt, >> represented by a composition of used beer cans...
> these are different representations, and due to their difference in > representation, are essentially different entities.
One nonsensical statement derived from another. A program remains the same entity independently on whether it is stored at the hard drive or memory steak.
That is one of the key ideas of programming to separate means of computing from algorithms.
Instructions how to walk to the next bus station can be followed by anybody who has a head and feet.
>>> Wrong. Computer integers are exactly same as in mathematics. Computer >>> "int" >>> as a type can be (and is) perfectly described mathematically. The >>> resulting >>> mathematical structure is not of Z, yet it is a perfectly mathematical >>> structure.
>> close enough, and it is traditionally called 'int' or 'integer' either >> way...
>> to do anything differently is a violation of long-held and authoritative >> programmer tradition.
> I never heard about such. Maybe you meant a tradition of buffer overruns > in > C programs? Anyway, no tradition can serve as an excuse for ignorance.
C, C++, Java, C#, ... all generally use the terms 'int' and 'integer' to refer to fixed-size subsets of the integer space...
since these are some of the main programming languages, their use of terms is authoritative.
>>>>>>>> one types 'int', they usually expect 32 bits.
>>>>>>> No, one usually expects a reference in the language or compiler >>>>>>> manual >>>>>>> which describes the semantics of int. A description there defines >>>>>>> the >>>>>>> type, of which name is int.
>>>>>> most code for maybe about the past decade has expected 'int' to be 32 >>>>>> bits. >>>>>> before this, much code was around which expected it to be 16 bits...
>>>>> Broken code. Every decent programming guide line on C/C++ requires an >>>>> explicit use of int32 (or equivalent) when the program requires the >>>>> corresponding range of values.
>>>> but, really, why does this matter?... >>>> after all, code can be edited easily enough...
>>> I don't understand this remark.
>> if code only works in one case, and can be edited to work in another, it >> is >> thus not "broken"...
> This is called "fixing broken code".
> If the code weren't broken there would be no need to fix it. If it were > designed properly in first place, e.g. following C/C++ guide lines and > elementary common sense, you would not need to fix this kind of errors.
it is only needed to change it: firstly, if the behavior is depended on; in porting to an arch where this is not upheld...
'int32_t' and friends were not added until C99, and so it is an ongoing tradition (from pre-C99) to use base types and assume that they are the intended sizes...
languages such as Java and C# also standardize the size of these various base types (for example, standardizing on int being 32 bits and long being 64).
>>>>>> FWIW, my "conceptual model" of most of this crap is pointless, it is >>>>>> the >>>>>> implementation which makes it work...
>>>>> How do you know if it does? Heard anything about testing, verification >>>>> and validation?
>>>> one can test, but this tests that the code is not broke, and says >>>> nothing >>>> about the universal ontology...
>>> How do you test without specifications? What do you test without >>> specifying it?
>> one tests for behaviors, and that nothing "out of place" happens.
> How "behaviours" and "out of place" are specified? Note the word > "specified".
we generally "know" when a behavior is out of place, and so usually it is not necessary to say what is not the expected behavior, only what is the expected behavior.
now, that one can say what they want code to do, however, says little about which aspect is more fundamental.
>> none the less, it is the combination of the code and implementation that >> defines the "reality" of the matter (it runs, and we see the results, >> ...).
> Buggy code defines bugs. That's is only reality.
yes, and these bugs are a part of the reality of the compiled program... so, what is the issue?...
bugs are just as much apart of reality as non-bugs. things like sickness and death also just happen to exist.
we don't write somewhere that someone will get sick, and then they do. rather, they get sick, and we note that they have gotten sick.
>>>>>>>> when we say we have a type (say, a 64-bit double), we expect a 64 >>>>>>>> bit >>>>>>>> double.
>>>>>>> 64-bit double has no meaning. There exist a dozen of floating-point >>>>>>> representations of 64-bit length.
>>>>>> yet, only a few that we can bother to care about, this is besides the >>>>>> point...
>>>>> How do you identify these "few"?
>>>> we know them because we know them, it does not exactly require a lot of >>>> thinking to figure these things out...
>>> So what does "double" mean without "lot of thinking"?
>> IEEE 754 / IEEE 754r
>> it also means that the CPU architecture is x86, x86-64, or (maybe) PPC...
>> since the CPU does something a certain way, the CPU is the authority for >> what is double.
> So, how are you talking about "double" without mentioning the CPU? What > are > you talking about? About CPU? Mass culture? Program? In the program, you > have:
> #define double char*
> what is double?
this is a preprocessor issue, and so in the code "double" no longer refers to double...
>>>>>> by this reasoning, because for most of human history, no one had any >>>>>> damn >>>>>> idea about DNA, does this mean that humans could not exist?...
>>>>> You are confusing the program with its medium and the execution >>>>> platform.
>>>> the "program" IS the "medium and execution platform"...
>>> Nonsense. A program can be printed on paper, painted on a T-shirt, >>> represented by a composition of used beer cans...
>> these are different representations, and due to their difference in >> representation, are essentially different entities.
> One nonsensical statement derived from another. A program remains the same > entity independently on whether it is stored at the hard drive or memory > steak.
I disagree...
a copy of a program on a hard-drive and on a memory stick are different entities (one is located in the hard drive, and the other may go in ones' pocket...).
they, however, may remain as a single conceptual entity due to all of the machinery existing to translate from one form to another.
> That is one of the key ideas of programming to separate means of computing > from algorithms.
even as such, this is itself an abstraction over the implementation, and does not change which is more fundamental.
> Instructions how to walk to the next bus station can be followed by > anybody > who has a head and feet.
yes, however, one person is not another, and said "instructions" do not exist apart from either the individuals or the mediums and forms by which they are transferred...
> If the code weren't broken there would be no need to fix it. If it were > designed properly in first place, e.g. following C/C++ guide lines and > elementary common sense, you would not need to fix this kind of errors.
Oh, well, I just see that claim as untrue... C has had quite a few changes to the way the language works. Implicit int's which are allowed in K&R C create parsing conflicts with typedef's in ANSI C. Use of ANSI C's void and void *'s catch a few common programming errors, but are unavailable in K&R C. The defintion of NULL changed. pre- and post-decrement operators no longer work properly due to ANSI C's insertion of "sequence points". The language has been continually reworked to support larger integer types or generic parameters behind the scenes. etc. etc.
> Buggy code defines bugs. That's is only reality.
Um... humorously:
So, buggy code can't define non-bugs? ;-)
So, non-buggy code can't define non-bugs, since that would imply an alternate and additional reality...? :)
Seriously, having done my fair share of professional and non-professional software development, I can say that the bugs that are found relatively soon are those that are either expected and tested for, or those that expose themselves through basic usage of the program. Unfortunately, you only test for problems where you expect problems are likely to occur, and you can test a program only so thoroughly in a development environment. Your production environment will reveal bugs that were missed in the most painful way. Bugs that are in low use code, are trivially incorrect, are due to unforeseen logic complexities or unexpected interactions of code modifications, or require review by other "experts" such as accountants and lawyers, are likely to not be found for a long time.
On Sun, 28 Jun 2009 10:16:12 -0700, cr88192 wrote: > "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message > news:5ejfdcqynoc9.1d6ph1h33llz2.dlg@40tude.net... >> On Sun, 28 Jun 2009 06:52:58 -0700, cr88192 wrote:
>> I never heard about such. Maybe you meant a tradition of buffer overruns >> in C programs? Anyway, no tradition can serve as an excuse for ignorance.
> C, C++, Java, C#, ... all generally use the terms 'int' and 'integer' to > refer to fixed-size subsets of the integer space...
> since these are some of the main programming languages, their use of terms > is authoritative.
And the Moon is made of cheese...
>>>> How do you test without specifications? What do you test without >>>> specifying it?
>>> one tests for behaviors, and that nothing "out of place" happens.
>> How "behaviours" and "out of place" are specified? Note the word >> "specified".
> we generally "know" when a behavior is out of place, and so usually it is > not necessary to say what is not the expected behavior, only what is the > expected behavior.
How this "knowledge" is communicated? Or is it so that all humankind is born with this knowledge?
>>> none the less, it is the combination of the code and implementation that >>> defines the "reality" of the matter (it runs, and we see the results, >>> ...).
>> Buggy code defines bugs. That's is only reality.
> yes, and these bugs are a part of the reality of the compiled program... > so, what is the issue?...
The issue is that bug is defined as a behavior different from specified. There is neither bug, nor behavior, nor even program without a specification. It is the specification of sine, which makes a program computing sine what it is. With the specification of text processor this program is garbage.
> bugs are just as much apart of reality as non-bugs. > things like sickness and death also just happen to exist.
> we don't write somewhere that someone will get sick, and then they do. > rather, they get sick, and we note that they have gotten sick.
>>>>>>>>> when we say we have a type (say, a 64-bit double), we expect a 64 >>>>>>>>> bit >>>>>>>>> double.
>>>>>>>> 64-bit double has no meaning. There exist a dozen of floating-point >>>>>>>> representations of 64-bit length.
>>>>>>> yet, only a few that we can bother to care about, this is besides the >>>>>>> point...
>>>>>> How do you identify these "few"?
>>>>> we know them because we know them, it does not exactly require a lot of >>>>> thinking to figure these things out...
>>>> So what does "double" mean without "lot of thinking"?
>>> IEEE 754 / IEEE 754r
>>> it also means that the CPU architecture is x86, x86-64, or (maybe) PPC...
>>> since the CPU does something a certain way, the CPU is the authority for >>> what is double.
>> So, how are you talking about "double" without mentioning the CPU? What are >> you talking about? About CPU? Mass culture? Program? In the program, you have:
>> #define double char*
>> what is double?
> this is a preprocessor issue, and so in the code "double" no longer refers > to double...
Which code you are talking about? The source code is the content of the text files with the extensions .h and .c.
>>>>>>> by this reasoning, because for most of human history, no one had any damn >>>>>>> idea about DNA, does this mean that humans could not exist?...
>>>>>> You are confusing the program with its medium and the execution >>>>>> platform.
>>>>> the "program" IS the "medium and execution platform"...
>>>> Nonsense. A program can be printed on paper, painted on a T-shirt, >>>> represented by a composition of used beer cans...
>>> these are different representations, and due to their difference in >>> representation, are essentially different entities.
>> One nonsensical statement derived from another. A program remains the same >> entity independently on whether it is stored at the hard drive or memory >> steak.
> I disagree...
> a copy of a program on a hard-drive and on a memory stick are different > entities (one is located in the hard drive, and the other may go in ones' > pocket...).
I have nothing to add to this. It speaks for itself.
>> If the code weren't broken there would be no need to fix it. If it were >> designed properly in first place, e.g. following C/C++ guide lines and >> elementary common sense, you would not need to fix this kind of errors.
> Oh, well, I just see that claim as untrue... C has had quite a few changes > to the way the language works. Implicit int's which are allowed in K&R C > create parsing conflicts with typedef's in ANSI C. Use of ANSI C's void and > void *'s catch a few common programming errors, but are unavailable in K&R > C. The defintion of NULL changed. pre- and post-decrement operators no > longer work properly due to ANSI C's insertion of "sequence points". The > language has been continually reworked to support larger integer types or > generic parameters behind the scenes. etc. etc.
So? The point is, when the range of an integer number is known, the program shall use an integer type which range is 1) defined and 2) corresponds to the required range. What is here to disagree with?
My opponent claimed, something like that a long standing tradition of indiscriminate use of int everywhere, should justify its use to represent readings of a sensor with the range of 0..2**93-1 even if the machine number corresponding to int is -2**15-1..2**15. That is an obvious rubbish.
>> Buggy code defines bugs. That's is only reality.
> Um... humorously:
> So, buggy code can't define non-bugs? ;-)
False |= True (:-))
> So, non-buggy code can't define non-bugs, since that would imply an > alternate and additional reality...? :)
The inverse wrong. (:-))
> Seriously, having done my fair share of professional and non-professional > software development, I can say that the bugs that are found relatively soon > are those that are either expected and tested for, or those that expose > themselves through basic usage of the program. Unfortunately, you only test > for problems where you expect problems are likely to occur, and you can test > a program only so thoroughly in a development environment. Your production > environment will reveal bugs that were missed in the most painful way. Bugs > that are in low use code, are trivially incorrect, are due to unforeseen > logic complexities or unexpected interactions of code modifications, or > require review by other "experts" such as accountants and lawyers, are > likely to not be found for a long time.
Yes. This can be stated in a simpler way: what happens with the bugs in the specifications? They are worse, much worse than "first-order" bugs.
> >> If the code weren't broken there would be no need to fix it. If it were > >> designed properly in first place, e.g. following C/C++ guide lines and > >> elementary common sense, you would not need to fix this kind of errors.
> > Oh, well, I just see that claim as untrue... C has had quite a few changes > > to the way the language works. Implicit int's which are allowed in K&R C > > create parsing conflicts with typedef's in ANSI C. Use of ANSI C's void and > > void *'s catch a few common programming errors, but are unavailable in K&R > > C. The defintion of NULL changed. pre- and post-decrement operators no > > longer work properly due to ANSI C's insertion of "sequence points". The > > language has been continually reworked to support larger integer types or > > generic parameters behind the scenes. etc. etc.
> So?
All examples of situations where the C code isn't broken, but must be fixed.
> My opponent claimed, something like that a long standing tradition of > indiscriminate use of int everywhere, should justify its use to represent > readings of a sensor with the range of 0..2**93-1 even if the machine > number corresponding to int is -2**15-1..2**15. That is an obvious
rubbish.
With what do you intend to read in a value of range of 0..2**93-1, if you can only read in values with a range of -2**15-1..2**15?
I think it's clearly not rubbish. In general, you can't read a float or double directly from a device, but you can read in data via bounded integers or more typically via bytes.
For example, you'll need to construct an artificial type with the range of 0..2**93-1 to represent the data received from the sensor. Then, you'll need to read in the value from the sensor using multiple reads of values with range of -2**15-1..2**15. Then, you'll need to convert those multiple values of -2**15-1..2**15 to your artificial type with the range of 0..2**93-1.
On Mon, 29 Jun 2009 04:35:40 -0400, Rod Pemberton wrote: > "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message > news:w9tbp6x90lp7.1vhwoz3dnplg3.dlg@40tude.net... >> On Sun, 28 Jun 2009 16:35:41 -0400, Rod Pemberton wrote:
>>>> If the code weren't broken there would be no need to fix it. If it were >>>> designed properly in first place, e.g. following C/C++ guide lines and >>>> elementary common sense, you would not need to fix this kind of errors.
>>> Oh, well, I just see that claim as untrue... C has had quite a few changes >>> to the way the language works. Implicit int's which are allowed in K&R C >>> create parsing conflicts with typedef's in ANSI C. Use of ANSI C's void and >>> void *'s catch a few common programming errors, but are unavailable in K&R >>> C. The defintion of NULL changed. pre- and post-decrement operators no >>> longer work properly due to ANSI C's insertion of "sequence points". The >>> language has been continually reworked to support larger integer types or >>> generic parameters behind the scenes. etc. etc.
>> So?
> All examples of situations where the C code isn't broken, but must be fixed.
I see. No, it was broken. When you change the language that may break the code. You can argue that it is rather the language which is broken, but that is equivalent. (And regarding C, it was always broken... (:-))
>> My opponent claimed, something like that a long standing tradition of >> indiscriminate use of int everywhere, should justify its use to represent >> readings of a sensor with the range of 0..2**93-1 even if the machine >> number corresponding to int is -2**15-1..2**15. That is an obvious >> rubbish.
> With what do you intend to read in a value of range of 0..2**93-1, if you > can only read in values with a range of -2**15-1..2**15?
Who said that? Surely I can read values. I need to deploy an integer type with the range of the value read.
Formally: between the model type and the domain type there must be a bijective mapping of the sets of values.
> I think it's clearly not rubbish. In general, you can't read a float or > double directly from a device, but you can read in data via bounded integers > or more typically via bytes.
No, there is plenty of hardware (some I have on my desk) that communicates floating-point numbers.
Automation makes some progress too, believe me. (:-))
> For example, you'll need to construct an artificial type with the range of > 0..2**93-1 to represent the data received from the sensor. Then, you'll > need to read in the value from the sensor using multiple reads of values > with range of -2**15-1..2**15.
That depends on the hardware protocol. Whether acquiring a value requires multiple I/O operations is irrelevant. Normally there are multiple layered protocols which connects you to the sensor.
|
