"Why is it necessary to classify data according to its type in computer programming?"
in [General Programming]
|
Prev: "Why is it necessary to classify data according to its type in computer programming?"
Next: The syntax of C (note: homework task)
From: Pascal J. Bourguignon on 7 Jul 2010 18:29 Paul N <gw7rib(a)aol.com> writes: > Incidentally, I would be a bit surprised if a language actually > provided a type for real numbers. This is not impossible, using the right representation. Eg. continued fractions. There are libraries, that you could integrate like gmp in a given language. -- __Pascal Bourguignon__ http://www.informatimago.com/
From: Ben Bacarisse on 8 Jul 2010 09:36 tm <thomas.mertes(a)gmx.at> writes: <snip> > ... I wrote a little C program to show the > different representations: Three small points: > ==================================================================== > # include "stdio.h" > # include "string.h" <>s are better the ""s. With "" what gets included can vary from one system to another (indeed from compile to compile in the worst case). With <> you get the standard ones. > int main (int argc, char *argv[]) > { > int int32 = 128; > float float32 = 128.0; > char char32[4] = "128\0"; > > union { > int int32value; > float float32value; > char char32value[4]; > } hardcast; By using a union you force the example to use representations of the same size, but one of the things that can vary between representations is the size! I'd simply use typed vobjects and print the representation directly with a function: void show_rep(const void *p, size_t sz) { const unsigned char *cp = p; while (sz--) printf("%2x", *cp++) } /* ... */ long double ld = 128; show_rep(&ld, sizeof ld); > printf("int int32 = %d, sizeof(int32) = %d, bits in int32: > 0x%08x\n", > int32, sizeof(int32), int32); sizeof yields a size_t value, not an int. You need a cast: int32, (int)sizeof(int32), int32); or you need to use C99's %zu format. In general, casting to unsigned long is the best C89 solution, but here you know the number is a small one so int is fine. > hardcast.float32value = float32; > printf("float float32 = %0.0f, sizeof(float32) = %d, bits in > float32: 0x%08x\n", > float32, sizeof(float32), hardcast.int32value); > memcpy(hardcast.char32value, char32, 4); > printf("char char32[4] = %s, sizeof(char32) = %d, bits in char32: > 0x%08x\n", > char32, sizeof(char32), hardcast.int32value); > return 0; > } > ==================================================================== <snip> -- Ben.
From: Pascal J. Bourguignon on 8 Jul 2010 21:20 Malcolm McLean <malcolm.mclean5(a)btinternet.com> writes: > Many high-level languages carry type information about with them. > > Whilst in some ways this makes programming easier, in many ways it > makes it harder. Many variables must inherently be integers, or > scalars, or strings. Expicit typing acts as a sort of documentation of > this, and attempts to, as ypu say, divide an integer by a string will > be caught at compile time. But many other variables have no inherent type, and could be as well any number or of any other kind. See my factorial example in another answer! -- __Pascal Bourguignon__ http://www.informatimago.com/
From: Pascal J. Bourguignon on 9 Jul 2010 05:15 tm <thomas.mertes(a)gmx.at> writes: > On 9 Jul., 03:20, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: >> Malcolm McLean <malcolm.mcle...(a)btinternet.com> writes: >> > Many high-level languages carry type information about with them. >> >> > Whilst in some ways this makes programming easier, in many ways it >> > makes it harder. Many variables must inherently be integers, or >> > scalars, or strings. Expicit typing acts as a sort of documentation of >> > this, and attempts to, as ypu say, divide an integer by a string will >> > be caught at compile time. >> >> But many other variables have no inherent type, and could be as well >> any number or of any other kind. >> See my factorial example in another answer! > > When you use a dynamic typed solution for the 'fact' function > the following can happen: > > - fact(15/4) might be wrong since for x < 1 you return 1, but > some people might prefer x instead (This might be a problem, > but lets assume that your definition of 'fact' is the right one). > > - fact("abcd") will, in the optimal case, give you a run-time > error and in the not so optimal case some implied automatic type > conversion rule (or a "clever" * or - function) will give you a > wrong result which later leads to severe problems. > > Why not make it explicit that you intend to reuse a function for > several types and specify exactly for which types you will do that. > > In Seed7 you do exactly that: Specify a template which defines the > function 'fact' for the given type 'aType' (Note that the Seed7 > template below is just a function with type parameter which contains > definitions in the body). After the template is defined it is > instantiated explicitly. This explicit instantiation is done on > purpose to improve the readability of the program. Please don't > praise implicit template instantiations since they save just one > line per instantiation. > > ==================================================================== > $ include "seed7_05.s7i"; > include "float.s7i"; > include "bigint.s7i"; > include "bigrat.s7i"; > include "complex.s7i"; > > const proc: FACT_DECL (in type: aType) is func > begin > > const func aType: fact (in var aType: argument) is func > result > var aType: result is aType conv 1; > begin > if argument >= (aType conv 1) then > result := argument * fact(argument - aType conv 1); > end if; > end func; > > end func; > > FACT_DECL(integer); > FACT_DECL(float); > FACT_DECL(bigInteger); > FACT_DECL(bigRational); > FACT_DECL(complex); > > const proc: main is func > begin > noop; > end func; > ==================================================================== > > When you try this program you will get the compile time error: > > fact3.sd7(14):51: Match for {argument >= {complex conv 1 } } failed > if argument >= (aType conv 1) then > > It tells you that >= is not defined for the type 'complex'. > > *** SURPRISE, SURPRISE *** > > Mathematicians will tell you >= cannot be defined reasonable for > 'complex' values. > > You get this error at compile time for free without heavy testing. > > Now you can define >= for 'complex' or decide for something else. We're just back to the classic antagonism between early and late binders and compiler detected bugs, (which cannot be any more complete than testing) vs. testing detected bugs. Read again this linked thread, and specifically this post: http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/9948645b27a2d49e/b7b737c6f3c6e00c?hl=en&q=compile+time+debug+test+group:comp.lang.lisp+author:pascal+author:costanza#b7b737c6f3c6e00c In conclusion, it's more a question of personal choice and taste. -- __Pascal Bourguignon__ http://www.informatimago.com/
From: blmblm on 9 Jul 2010 08:14
In article <87y6dnexi1.fsf(a)kuiper.lan.informatimago.com>, Pascal J. Bourguignon <pjb(a)informatimago.com> wrote: > Paul N <gw7rib(a)aol.com> writes: > > > Incidentally, I would be a bit surprised if a language actually > > provided a type for real numbers. > > This is not impossible, using the right representation. Eg. continued > fractions. There are libraries, that you could integrate like gmp in > a given language. Are there libraries that allow representing *all* real numbers, including the irrationals? I'm trying to imagine how that could work .... ? -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor. |