"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 incomputer programming?"
Next: "Why is it necessary to classify data according to its type in computer programming?"
From: Joshua Maurice on 9 Jul 2010 15:43 On Jul 9, 7:53 am, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > Paul N <gw7...(a)aol.com> writes: > > On 9 July, 13:14, blm...(a)myrealbox.com <blm...(a)myrealbox.com> wrote: > >> In article <87y6dnexi1....(a)kuiper.lan.informatimago.com>, > >> Pascal J. Bourguignon <p...(a)informatimago.com> wrote: > > >> > Paul N <gw7...(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 .... ? > > > As I understand it, for the majority of real numbers, it would take an > > infinite amount of space just to store one number. Which is why I > > expressed my doubts. On the other hand, if it's a number that you are > > interested in, it's probably one of the tiny minority that *can* be > > represented in a finite space. > > > Of course, any computer using a fixed size for numbers can only store > > a tiny minority of the integers and a tiny minority of the floating > > point numbers, so we're used to getting half measures anyway. > > At this point, google and wikipedia would be useful. > > Theorem: For every real number a, there corresponds a unique continued > fraction with value equal to a. This fraction is finite if a > is rational and infinite if a is irrational. > > However, continued fractions still have nice properties. For most > real numbers (those you're "interested" in), you can determine an > algorithm to compute the numbers of the serie in order. And you can > compute an approximation using these numbers of the serie in order. > Therefore you don't need to store an infinite number of parameters, > but you can just compute those you need, when you need them (ie. at > display time). > > Otherwise, it's already a big improvement over floating points, for > rational numbers. To put it in another way, the number of all texts is countably infinite, aka has cardinality of that of the natural numbers, which is also cardinality of the rationals. The cardinality of the real numbers is uncountably infinite. Thus, for any particular encoding scheme for real numbers onto paper, there will be a real number which cannot be encoded in a finite way. In fact, for any particular encoding scheme, nearly all of the real numbers are not encodable. However, let's go back to what Pascal J. Bourguignon said. It's not impossible to have a library which supports exact arithmetic on Real Numbers for a subset of the Real Numbers. An inefficient, but highly accurate and general method, would be a textual representation like what you might see in a formal math proof. The algorithm which does addition would effectively be matlab and Maple. An unfortunate side effect of this is that it's impossible for the library to be able to do simple things like compare any two arbitrary numbers for equality. (Godel's Incompleteness Theorem and all.) There might be other encoding schemes, other than the standard formal math proof textual encoding, which can encode less of the real numbers, but can always do things like equality comparison. Because of Godel's Incompleteness Theorem, there is no right answer here. It's tradeoffs between ability to encode more Real Numbers exactly, speed of computation, and solveability. Floating point arithmetic is where speed of computation and solveability are favored absolutely more than the ability to encoding lots of Real Numbers. Matlab and Maple favor the ability to exactly encode more real numbers at the cost of speed of computation and the ability to actually compute all problems in its input domain.
From: Pascal J. Bourguignon on 10 Jul 2010 11:31 blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> writes: > In article <4nXZn.485$FH2.410(a)viwinnwfe02.internal.bigpond.com>, > Fred Nurk <albert.xtheunknown0(a)gmail.com> wrote: >> blmblm(a)myrealbox.com wrote: >> > <snip> >> > Would you mind identifying the textbook? >> > <snip> >> >> You may buy it at http://au.wiley.com/WileyCDA/WileyTitle/ >> productCd-073140520X.html > > Thanks .... > > I was going to be snarky and say "why would I want to buy it?" > (given that based on the quoted excerpt I'm not very impressed), > but even if I wanted to apparently I couldn't! because when > I point a browser at the above link I get a page that tells me > this: > > "This product is not currently available for purchase from this > website." > > Maybe availability depends on geographic area? I am in the US, > and the URL suggests Australia. Oops. I wasn't aware that UPS didn't work in Australia. http://www.ups.com/?Site=Corporate&cookie=au_en_home&setCookie=yes must be fake. -- __Pascal Bourguignon__ http://www.informatimago.com/
From: blmblm on 10 Jul 2010 11:50 In article <87wrt3cq0v.fsf(a)kuiper.lan.informatimago.com>, Pascal J. Bourguignon <pjb(a)informatimago.com> wrote: > blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> writes: > > > In article <4nXZn.485$FH2.410(a)viwinnwfe02.internal.bigpond.com>, > > Fred Nurk <albert.xtheunknown0(a)gmail.com> wrote: > >> blmblm(a)myrealbox.com wrote: > >> > <snip> > >> > Would you mind identifying the textbook? > >> > <snip> > >> > >> You may buy it at http://au.wiley.com/WileyCDA/WileyTitle/ > >> productCd-073140520X.html > > > > Thanks .... > > > > I was going to be snarky and say "why would I want to buy it?" > > (given that based on the quoted excerpt I'm not very impressed), > > but even if I wanted to apparently I couldn't! because when > > I point a browser at the above link I get a page that tells me > > this: > > > > "This product is not currently available for purchase from this > > website." > > > > Maybe availability depends on geographic area? I am in the US, > > and the URL suggests Australia. > > Oops. I wasn't aware that UPS didn't work in Australia. > http://www.ups.com/?Site=Corporate&cookie=au_en_home&setCookie=yes > must be fake. Say what? What does this have to do with what I reported? What I get when I point a browser at the link cited by the OP is a page with the book's title and a picture of its cover and the text above, and that's about it. Do you get something else? -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.
From: Pascal J. Bourguignon on 10 Jul 2010 13:14 blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> writes: > In article <87wrt3cq0v.fsf(a)kuiper.lan.informatimago.com>, > Pascal J. Bourguignon <pjb(a)informatimago.com> wrote: >> blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> writes: >> >> > In article <4nXZn.485$FH2.410(a)viwinnwfe02.internal.bigpond.com>, >> > Fred Nurk <albert.xtheunknown0(a)gmail.com> wrote: >> >> blmblm(a)myrealbox.com wrote: >> >> > <snip> >> >> > Would you mind identifying the textbook? >> >> > <snip> >> >> >> >> You may buy it at http://au.wiley.com/WileyCDA/WileyTitle/ >> >> productCd-073140520X.html >> > >> > Thanks .... >> > >> > I was going to be snarky and say "why would I want to buy it?" >> > (given that based on the quoted excerpt I'm not very impressed), >> > but even if I wanted to apparently I couldn't! because when >> > I point a browser at the above link I get a page that tells me >> > this: >> > >> > "This product is not currently available for purchase from this >> > website." >> > >> > Maybe availability depends on geographic area? I am in the US, >> > and the URL suggests Australia. >> >> Oops. I wasn't aware that UPS didn't work in Australia. >> http://www.ups.com/?Site=Corporate&cookie=au_en_home&setCookie=yes >> must be fake. > > Say what? What does this have to do with what I reported? > What I get when I point a browser at the link cited by the OP is > a page with the book's title and a picture of its cover and the > text above, and that's about it. Do you get something else? I was sarcastic about these companies who cannot sell worldwide, which is what you reported in no less than three sentences, including one quotation and one rethorical question (since you don't live on Jupiter). -- __Pascal Bourguignon__ http://www.informatimago.com/
From: tm on 11 Jul 2010 18:10
On 9 Jul., 11:15, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > tm <thomas.mer...(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 ... Type checking (static and dynamic) and binding (late and early) are not the same thing. There are languages with static type checking which allow late binding (at least to some degree). Java methods and virtual C++ methods are IMHO an example of this: Types are checked statically and the dispatch (binding) is done at runtime. You seem to draw the false conclusion that static type checking does forbid dynamic behaviour (such as dynamic dispatch). > and compiler detected bugs, (which cannot be any more complete > than testing) I doubt this. Testing done with a dynamically typed language will hardly find all errors that a static type checker will find easily (without running the program). Even tests with 100% code coverage are not enough (to find type errors) since the combination of all places where (dynamic) values are created and all places where these values are used must be taken into account. A detailed argumentation can be found here: http://seed7.sourceforge.net/faq.htm#static_type_checking Since I have experience with static type checking and extensive testing I can tell you that the errors found by a static type checker are usually very different from the errors you find with testing. The two methods are a good complement. AFAIK here are no restrictions that a particular testing method cannot be applied for a statically typed language. In the end you just write better programs when you use more methods to find errors. > vs. testing detected bugs. > > Read again this linked thread, and specifically this post: > > http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/99486... Interesting, but several important arguments are missing (as my argument that 100% code coverage tests are not enough ...). > In conclusion, it's more a question of personal choice and taste. There is also something like state of the art. Let me explain: Programs consist of algorithms and data. - There are languages which concentrate on describing the algorithms such as some functional and dynamic typed languages. In such a language the structure of the data is determined implicit by the algorithms. When the data structure is complicated it will probably be described in comments, but comments and formal type declarations are something different. - There are languages which concentrate on describing data (E.g.: input data and result data). I mean the so called "fourth generation languages". This languages expect that the algorithm is generated automatically from data descriptions. I see this two approaches as extreme and opposite positions. Usually a program is more often read than written. It is therefore desireable that a program contains a good description of both: Algorithms AND Data. And I am not speaking of describing one part of the program just as comment. Type declarations are a good method to document data structures. And explicit functions (methods) and statements are also better then implicit algorithms. That way both parts of a program can be automatically checked against each other (at least to some degree). And part of this check is a static type check (which often finds different errors than testing). It is IMHO state of the art to use explicit algorithm and data descriptions. All this "do what I mean" concepts are essencially "a program should read my mind" concepts which just lead to programs that are more easiliy written but harder to test and much much harder to maintain. When you manage to halve development time with tricks that ommit parts of the program the maintenance effort will usually double. Greetings Thomas Mertes Seed7 Homepage: http://seed7.sourceforge.net Seed7 - The extensible programming language: User defined statements and operators, abstract data types, templates without special syntax, OO with interfaces and multiple dispatch, statically typed, interpreted or compiled, portable, runs under linux/unix/windows. |