Ok, known issues with floating point routines that can be fixed (unintentional pun:-) should be fixed.
On the other hand it is clear that a finite representation of real numbers has tradeoffs.
But only few seem to care about the cumulated errors.
My experience in engineering (simulation of casted turbine blades) was that people know that bad things can occur during complex floating point calculations but the matter was too complicated to be investigated.
Example: if during finite element simulation a timestep did not end up with a valid solution (the iterative/approximative solver of the large linear systems did not converge or even crash) just some control parameters were varied (time step, perhaps material curves) until the calculation seemed to produce some valid looking result. Needless to say, that that only obvious errors can be spotted that way.
The strange thing about all that is, that in the last years the mathematical discipline of interval analyis has been developed. Here every number is represented with its interval of known error bounds. These error intervall are kept and updated during calculations. Thus at the end of a large complex calculation, you know the error. That is a very valuable property.
More, in fact what one does so in many cases is not only a standard calculation but rather machine proof of error bounds.
This offers some unique properties, e.g. for rigorous global searches.
So we have far better technology available.
Why is this stuff not used more widely?
As far as I know, only SUN puts interval analysis enabled data types in its FORTRAN and C/C++ compilers.
But I have not seen that stuff in gcc, which would have a big impact.
Timing is a bit unlucky this year. The Erlang site is not reachable right now, just days before the ICFP contest.
Here is some info what happened:
A few people have asked me "what's happening with Erlang.org?". I
called Kent today. Seems they've moved some servers from one building
to another and it's taking longer than expected to get the external
network connection up again (i.e. several days). Until they do that,
erlang.org, erlang.se and the mailing list all don't work.
Although it is agreed that CFG's, regular expressions, FSM and compiler technologies are important, I'd wager that well under 1% of the online community -- and even under 5% of the 'technical' community every really had to wade through the proof that an NFA called N is equivalent to a DFA called D subject to the following blah blah blah.:-)
These regex books are nice to get a first grip on the topic, to see some common applications beyond del *.*.
But I personally came only past a certain level of understanding, these texts never managed to explain what NEAs are, why there are sometimes epsilon transitions or not and so on.
After this course it was considerably easier to read the dragon book and such applied regexp titles. So I would definitely recommend to read through a book like Hopcroft/Ullmann to get the foundations right.
This year I work through a
course about applied automata theory
(in German)
and it introduces great applications, the connection between finite automata and logic formulae, which is important for model checking and automata that do not work on words but on trees or even more complicated structures like pictures and grids.
The tree automata allowed to me get a better grip about the foundations of XML, DTDs, XPATH and such.
Last year there was a
course about automata theory and reactive systems (in English).
which used automata on infinite words to model parallel processes, games and such. Too bad I had no time to work throught it.
So I definitely vote to go for the theoretical computer science. It makes you see certain design decisions much, much clearer.
I thought they usually had the contest late July and early August.
Me too. For better organizing my schedule this year, I tried to find out the approximate date of the contest months ago already.
But t seems my mail never reached the final contest organizing people, or they never answered.
Only thanks to a friendly computer scientist, to whom I wrote first and who has only remotely to do with the contest, I found out about the date.. just three days in advance.
So I hope next year the date will be much less surprising, I would really like to know the date about a month in advance.
Yep, there is a nice bit about it in the "Tangram Book" (the real title is: Generative Programming).
Itentional Programming was pushed by Charles Simonyi, the guy that brought us hungarion notation for variable naming (oh how I hate that every time I have to deal with Windows programmers:)
Some time ago there was a statement that the IP crew moved from Microsoft Research to the Microsoft Development group, because their stuff should be added to a future version of visual studio.
What is it about?
Well one thing was to use the notation of an application domain rather than common programming text, the example was a piece of numerical code, where real (TeX rendered like) formulas were used instead of the rather dull text like rendering we are used to. E.g. "y:= \sqrt(x)" (you know the root symbol) instead of "y:= sqrt(x)" (the ASCII stuff).
I believe that could be nice in some domains with superior notation (maths, chemistry, music..)
Another bit was structional editing. So one doesn't edit lines of single characters but directly on the syntactic/semantic structure.
I'm not sure if I would like that. I hat too tyranic editors. Emacs or Eclipse are what I tolerate at most, not much more.
I would take this post as an obvious troll, if not for your low user number and the fact that you've posted insightful comments in the past.
A low user number just means that I stumbled a bit earlier on this site.:)
But I admitt that my mode was polemic.
When designing languages for quantum computers, it should be clear how the appropriate portions of the language would map directly onto a sequential set of operations to instruct a physical quantum computer to perform (in other words, a sequence of fundamental quantum gate operations).
I agree.
Functional languages do not provide this with the same clarity as procedural or object oriented languages.
I doubt that. The operators of course map to functions and the successive use of operators to a sequence of function applications.
What I find striking is that a thing like "a:= 12" will map to a measurement in a quantumn computer, this not a reversible operation. On the other hand that using non-destructive assignments is what functional languages use.
Let's talk again in about half a year, until then I will have accumulated more knowledge on quantumn computing (I'll read through the Gruszka book this semester).
Please add Erlang to that list of functional programming languages. It adds inbuilt support for concurrency and distribution (not the clumsy way Java does) which I expect from a future programming language which I hope is much better suited for network programming.
Let's not forget QCL (Quantum Computing Language)
[tuwien.ac.at] developed by Bernhard Oemer (a
slashdotter) in 1998.
Both languages piss me off considerably (forgive the strong language)!
First procedural (QCL) and now OOP!
But everyone knows, that
OOP is snakeoil, well except for those gready
UML tools vendors and their
greedy consultanting brothers who errected a tool industry to cure the problems they caused by pushing OOP into PHB everywhere:-)
Honestly. Quantumn physics is reversable phyics, as physical relevant quanties must be measureable and thus be represented by unitary operators.
This implies that quantumn operations are inheritently reversible and that thus a destructive update is very hard to realize!
Man, non-destructive updates (persistent data!) don't I hear "functional programming" cried out loud here?
Imagine you're responsible for a module in a big system. Over the years, well meaning aspect oriented programmers stick more and more little hooks into your code. Eventually like Gulliver, when you try to move, e.g. fix or improve your code, you simply can't without breaking the hooks that tie you down.
Not if you buy Irrational's SuperStitchItTogether (TM), a superb visual tool, that will draw impressive maps of the control flow of AOP projects which will make colleagues and visitors bow in awe once you printed them out and put them on the walls of your office. It offers reverse, forward, up and down engineering with roundtrip to Hawaii as well.
Dijkstra's criteria for allowing a feature into a language was how much it complicated the description of the "cursor position" ("textual index point") of a program at a certain time. Gotos are bad, because they make the size required to describe that position unbounded
Bounded and large would be worse enough.
Let me rather cite:
My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.
AOP, like operator overloading in C++, can introduce amazing surprises to a programmer. A small innocent source code file in the collection of hundreds of source code files can change the behaviour of a program in an unpleasant way.
Other parts of the program can then hook into these things and effect how your program runs, without them having to go through and modify your code. (Example: if they want to log a message to file everytime your "CastRay()" function is called, they can do this without going in and editing your code).
Which will inavoidably lead to very bad code.
Remember operator overloading in C++, where a similiar overuling of semantics was possible?
Because of its abusive potential it was one of features that became considered bad practice if used at all later.
Basically, imagine if you wrote a program which had "hooks" scattered through it.
Imagine what would happen if one of these AOP folks would try to sell it to Dijkstra ("Go To Statement Considered Harmful", Communications of the ACM, Vol. 11 (2), pp. 147-148, 1968).
I don't know if I am just becoming old and closed-minded, or if there were too many methodologies-de-jour in the last years.
OOP was a nice addition to structured programming, but already with UML I had my pains, because of course, it was closely connected to buying the right tools (Rose, Together..) and too much hyped for my taste.
Extreme Programming seems to have lost its impetus, or am I just not up to date?:)
AOP has great potential to reintroduce spaghetti code, something fought by structured programming in the 70ies. I believe it will lead to truely incomprehensible control flow without the right killer tool/killer IDE. From all the candidates either I grok it the least or my feeling is right that it is the gimmick-est.
And please note that some schools of programming, like some disciples of the school of functional programming think that even OOP was snake oil!
Man I wish Microsoft or Sun would hype Visual OCaml or Erlang2EE or Prolog.NET for a change. That would be refreshing.
On the downside, colleagues who come by my home or office won't see my new copy of MySQL Cookbook because it is online rather than on my shelf showing another O'Reilly animal. I might have to print out the covers and tape them to my old school books to deal with that for the time being, but I am sure that Safari Bookshelf is how I plan to spend money on technical documentation from now on.
The solution to that problem is easy.We need
a show case box, e.g. some plexi glas holder that is able to hold a postcard with a flashy sign that reads "my selection of the month" that you can bolt to your wall
either O'reilly mails you a postcard with the covers of titles in color print on the back, or you print it out yourself and put it into the show holder
to impress your friends.
an autogenerated PNG image with the titles on the oreilly site, that you can link on your web page to
This has some decoration value, still impresses your friends and you have some kind of documentation what you read, if you collect the cards.
Note: Please send me a subscription, if you steal that idea, Tim.:)
This strikes me as true: for years and years and years, researchers have been promising AI was just around the corner... And what do we have right now? Nothing!
I'm not sure if that is true for the last 20 years anymore.
Now I have the sudden urge to sponsor a price for best antigravity device!:-)
And in contrast to what the AI researchers did, I doubt that physicists will show up to participate in this event.
I have to correct myself. According to the FAQ the accumulation at the client side is not done as I expected. They will bill only afterwards,
That gives for 20 transactions a total of 1 credit card blling over at the merchant plus between 1 (client does 20 transactions in one month, client is billed monthly) and 20 transactons (client does one transaction per month, is billed monthly).
So it would depend on the billing intervall and how many transactions a client does per month.
That would work if pepercoin paid the merchants by credit card somehow and that was the fee. But its not. The fee is, always has been, will be and just plain IS on the purchaser problem..50 ==.50 no matter what you do.
As far as I understand there are two types of credit card transactions involved:
The first one is where the merchant claims his peppercoin win from peppercoin.
The second one is, when a client orders peppercoins (both winners and loosers) from peppercoin.
The scheme makes only sense, when many transactions are condensed to one transaction.
at the merchant side, this is done by increasing the value, thus a winning peppercoin is not.05 cent but 10$, 20 times the value.
at the client side, the number of coins is increased, the client buys 20 peppercoins at.05 cent for a total of 10$, for this he will get some electronic list with 20 transactions numbers or similiar, the peppercoin software knows which one is a looser, which one is a winner, the client doesn't
The rest is done by probability. The client buys 20 times, but only one winning coin will be distributed.
So we have 20 transactions and 2 credit card billings (one at the client, one at the merchant). That reduces billing cost 10 to 1, thus a saving of 90%. Not bad.
I understand the idea of using statistics to reduce the number of transactions with the same results, but I don't understand how Peppercoin makes up the difference. A credit card still needs to be billed in the end, right?
Peppercoin will not pay the merchants 100% of the money that they took from customers.
It will pay out 100% minus the fee for the real transaction costs minus a win margin for them.
The benefit is, that if e.g. only 5% of the transactions will result in a credit card fee, this scheme gives a 95% cost reduction in real transfer fees - a big big improvement.
Ok, the merchant needs many transactions to get reasonable statistical error margins.
But like with insurances on could imagine different peppercoin fees for different risk levels.
The scheme is elegant, but it makes peppercoin a mix of a bank and a lottery, areas typically keen defended by state monopolies. So guess it will be more a legal/political issue than a technical/economic one.
Slashdot Mirror
On the other hand it is clear that a finite representation of real numbers has tradeoffs. But only few seem to care about the cumulated errors.
My experience in engineering (simulation of casted turbine blades) was that people know that bad things can occur during complex floating point calculations but the matter was too complicated to be investigated.
Example: if during finite element simulation a timestep did not end up with a valid solution (the iterative/approximative solver of the large linear systems did not converge or even crash) just some control parameters were varied (time step, perhaps material curves) until the calculation seemed to produce some valid looking result. Needless to say, that that only obvious errors can be spotted that way.
The strange thing about all that is, that in the last years the mathematical discipline of interval analyis has been developed. Here every number is represented with its interval of known error bounds. These error intervall are kept and updated during calculations. Thus at the end of a large complex calculation, you know the error. That is a very valuable property.
More, in fact what one does so in many cases is not only a standard calculation but rather machine proof of error bounds.
This offers some unique properties, e.g. for rigorous global searches.
So we have far better technology available. Why is this stuff not used more widely?
As far as I know, only SUN puts interval analysis enabled data types in its FORTRAN and C/C++ compilers. But I have not seen that stuff in gcc, which would have a big impact.
Very strange.
To whom is interested, here is a homepage of the intervals community.
Regards,
Marc
Here is some info what happened:
A few people have asked me "what's happening with Erlang.org?". I called Kent today. Seems they've moved some servers from one building to another and it's taking longer than expected to get the external network connection up again (i.e. several days). Until they do that, erlang.org, erlang.se and the mailing list all don't work.
The UU mirror seems ok:
http://www.csd.uu.se/ftp/mirror/erlang/
Matthias
Regards,
Marc
Some wise man is going to make a RPPC (Readable Perl Programming Contest) some day.
Scary. It would prove several of me beliefs completely wrong.
del \Sigma^*
These regex books are nice to get a first grip on the topic, to see some common applications beyond del *.*.
But I personally came only past a certain level of understanding, these texts never managed to explain what NEAs are, why there are sometimes epsilon transitions or not and so on.
The big enlightening came after a great course in automata theory and formal languages (in German), thus some theoretical computer science.
After this course it was considerably easier to read the dragon book and such applied regexp titles. So I would definitely recommend to read through a book like Hopcroft/Ullmann to get the foundations right.
This year I work through a course about applied automata theory (in German) and it introduces great applications, the connection between finite automata and logic formulae, which is important for model checking and automata that do not work on words but on trees or even more complicated structures like pictures and grids. The tree automata allowed to me get a better grip about the foundations of XML, DTDs, XPATH and such.
Last year there was a course about automata theory and reactive systems (in English). which used automata on infinite words to model parallel processes, games and such. Too bad I had no time to work throught it.
So I definitely vote to go for the theoretical computer science. It makes you see certain design decisions much, much clearer.
Regards,
Marc
The appropriate model for racing tracks tracks might be a T(o)uring machine, where you glue the tape start and end sections together. Just kidding :-)
Me too. For better organizing my schedule this year, I tried to find out the approximate date of the contest months ago already. But t seems my mail never reached the final contest organizing people, or they never answered.
Only thanks to a friendly computer scientist, to whom I wrote first and who has only remotely to do with the contest, I found out about the date .. just three days in advance.
So I hope next year the date will be much less surprising, I would really like to know the date about a month in advance.
Regards,
Marc
Regards,
Marc
* concurrent like Erlang
* distributed like Erlang
* functional like Erlang
and point to some comments by the Erlang crowd
Regards,
Marc
Yep, there is a nice bit about it in the "Tangram Book" (the real title is: Generative Programming).
:)
:= \sqrt(x)" (you know the root symbol) instead of "y := sqrt(x)" (the ASCII stuff).
..)
Itentional Programming was pushed by Charles Simonyi, the guy that brought us hungarion notation for variable naming (oh how I hate that every time I have to deal with Windows programmers
Some time ago there was a statement that the IP crew moved from Microsoft Research to the Microsoft Development group, because their stuff should be added to a future version of visual studio.
What is it about?
Well one thing was to use the notation of an application domain rather than common programming text, the example was a piece of numerical code, where real (TeX rendered like) formulas were used instead of the rather dull text like rendering we are used to.
E.g. "y
I believe that could be nice in some domains with superior notation (maths, chemistry, music
Another bit was structional editing. So one doesn't edit lines of single characters but directly on the syntactic/semantic structure.
I'm not sure if I would like that. I hat too tyranic editors. Emacs or Eclipse are what I tolerate at most, not much more.
Regards,
Marc
A low user number just means that I stumbled a bit earlier on this site. :)
But I admitt that my mode was polemic.
When designing languages for quantum computers, it should be clear how the appropriate portions of the language would map directly onto a sequential set of operations to instruct a physical quantum computer to perform (in other words, a sequence of fundamental quantum gate operations).
I agree.
Functional languages do not provide this with the same clarity as procedural or object oriented languages.
I doubt that. The operators of course map to functions and the successive use of operators to a sequence of function applications.
What I find striking is that a thing like "a:= 12" will map to a measurement in a quantumn computer, this not a reversible operation. On the other hand that using non-destructive assignments is what functional languages use.
Let's talk again in about half a year, until then I will have accumulated more knowledge on quantumn computing (I'll read through the Gruszka book this semester).
Regards,
Marc
Regards,
Marc
Both languages piss me off considerably (forgive the strong language)!
First procedural (QCL) and now OOP! But everyone knows, that OOP is snakeoil, well except for those gready UML tools vendors and their greedy consultanting brothers who errected a tool industry to cure the problems they caused by pushing OOP into PHB everywhere :-)
Honestly. Quantumn physics is reversable phyics, as physical relevant quanties must be measureable and thus be represented by unitary operators.
This implies that quantumn operations are inheritently reversible and that thus a destructive update is very hard to realize!
Man, non-destructive updates (persistent data!) don't I hear "functional programming" cried out loud here?
Regards,
Marc
Not if you buy Irrational's SuperStitchItTogether (TM), a superb visual tool, that will draw impressive maps of the control flow of AOP projects which will make colleagues and visitors bow in awe once you printed them out and put them on the walls of your office. It offers reverse, forward, up and down engineering with roundtrip to Hawaii as well.
Regards,
Marc
Bounded and large would be worse enough. Let me rather cite:
My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.
AOP, like operator overloading in C++, can introduce amazing surprises to a programmer. A small innocent source code file in the collection of hundreds of source code files can change the behaviour of a program in an unpleasant way.
Regards,
Marc
Than this link might interest you.
Regards,
Marc
kinda of like the switch you made when going from functional programming to object oriented programming.
You mean of course structured programming, which belongs to the programming school of imperative programming.
Regards,
Marc
Which will inavoidably lead to very bad code. Remember operator overloading in C++, where a similiar overuling of semantics was possible? Because of its abusive potential it was one of features that became considered bad practice if used at all later.
Regards,
Marc
Imagine what would happen if one of these AOP folks would try to sell it to Dijkstra ("Go To Statement Considered Harmful", Communications of the ACM, Vol. 11 (2), pp. 147-148, 1968).
Regards,
Marc
I don't know if I am just becoming old and closed-minded, or if there were too many methodologies-de-jour in the last years.
And please note that some schools of programming, like some disciples of the school of functional programming think that even OOP was snake oil!
Man I wish Microsoft or Sun would hype Visual OCaml or Erlang2EE or Prolog.NET for a change. That would be refreshing.
Regards,
Marc
The solution to that problem is easy.We need
This has some decoration value, still impresses your friends and you have some kind of documentation what you read, if you collect the cards.
Note: Please send me a subscription, if you steal that idea, Tim. :)
Regards,
Marc
I'm not sure if that is true for the last 20 years anymore.
Now I have the sudden urge to sponsor a price for best antigravity device! :-)
And in contrast to what the AI researchers did, I doubt that physicists will show up to participate in this event.
Regards,
Marc
That gives for 20 transactions a total of 1 credit card blling over at the merchant plus between 1 (client does 20 transactions in one month, client is billed monthly) and 20 transactons (client does one transaction per month, is billed monthly).
So it would depend on the billing intervall and how many transactions a client does per month.
Regards,
Marc
As far as I understand there are two types of credit card transactions involved:
The scheme makes only sense, when many transactions are condensed to one transaction.
The rest is done by probability. The client buys 20 times, but only one winning coin will be distributed. So we have 20 transactions and 2 credit card billings (one at the client, one at the merchant). That reduces billing cost 10 to 1, thus a saving of 90%. Not bad.
Regards,
Marc
Peppercoin will not pay the merchants 100% of the money that they took from customers.
It will pay out 100% minus the fee for the real transaction costs minus a win margin for them.
The benefit is, that if e.g. only 5% of the transactions will result in a credit card fee, this scheme gives a 95% cost reduction in real transfer fees - a big big improvement.
Ok, the merchant needs many transactions to get reasonable statistical error margins. But like with insurances on could imagine different peppercoin fees for different risk levels.
The scheme is elegant, but it makes peppercoin a mix of a bank and a lottery, areas typically keen defended by state monopolies. So guess it will be more a legal/political issue than a technical/economic one.
Regards,
Marc