| | Tags: | links | | Subject: | Links + D libs updates | | Time: | 11:21 pm |
|
| Probably now I'll be able to update the blog more often.
Announce of Spyke python-to-C compiler: http://mail.python.org/pipermail/python-dev/2008-April/078469.html
Computer Graphics and Geometric Ornamental Design, Craig S. Kaplan. PhD thesis, 2002, related to metamagical themas by Douglas Hofstadter and many works by M.C. Escher: http://www.cgl.uwaterloo.ca/~csk/phd/
Scientific Computing with Python, video courses/talks: http://www.nanohub.org/resources/99/ There are quite good PDFs too, "Introduction to Scientific Computing with Python" that explains lot of good stuff: http://www.nanohub.org/site/archive/2004.10.24-Python_talk1.pdf http://www.nanohub.org/site/archive/2004.10.24-Python_talk2.pdf
Computational Photography - G22.3033-006 7, documents and articles from the course, really good stuff: http://www.cs.nyu.edu/~fergus/teaching/comp_photo/index.html
"What To Know Before Debating Type Systems", a simple basic reading on this topic: http://cdsmith.twu.net/types.html
"Gin Television and Social Surplus", a good article: http://www.shirky.com/herecomeseverybody/2008/04/looking-for-the-mouse.html
Everyone is talking about this, a small JavaScript program to run Processing code: http://ejohn.org/blog/processingjs/
"The Mysterious Memristor", by Sally Adee, that explains in a simple way this small revolution in electronics: http://www.spectrum.ieee.org/print/6207
-------------------
Updates regarding my D libs: http://www.fantascienza.net/leonardo/so/libs_d.zip
- Added: IsClass, boxArrayCmp, AttrExtract, XattrExtract, minMax, xpairs - removed StructArr - splitted module func into templates and func modules. - Globally cleaned and more tidy - renamed modules "func2" as "extra", "ppmlib" as "ppm", "geom" as geometry. - Introduced a quite tidier usage of exceptions. - xgroupby and xchain simplified and cleaned. | comments: Leave a comment  |
| Slow updates because of limited net access.
The C language is designed for the hardware of the computer. Python is designed for the programmer. The D language is designed for both the designer of its compiler and for its compiler.
-----------------------
Few links:
Many free video courses, for science and engineering, there are an couple of them for Python too, with interesting PDF files, that show how to use Python in various scientific situations: http://www.datawrangling.com/hidden-video-courses-in-math-science-and-engineering.html
Very nice, how to teach some Computer Science without computer to young children, some of the things shown are nice, like the sorting algorithms: http://csunplugged.com/ But I don't know if it's an advantage for young children to learn sorting nets and other things. I think they have more important things to learn first, like reading complex texts, writing well, some mathematics, statistics, geometry, combinatorics, etc.
A really interesting parser+interepreter, PyMeta, it's a version of OMeta+Python: http://washort.twistedmatrix.com/ OMeta is a part of a dream to create now foundations of computer programming, this is the third part of an article that discusses related matters: http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html
-----------------------
As soon as possible I'll update my D libs, there are many news. New things: - editDistance, editDistanceFast: they find the Levenshtein distance between two arrays (strings too). - ALL: template that's true if the template predicate is true for all the items of the given tuple. - MAP: template that maps a template on all the items of the given tuple and return the resulting tuple. - BKtree: fast implementation of BK-trees to find nearby objects, given a distance function. - polyCentroid: to find area and centroid coordinate of a given polygon. - delVoidC, delVoidGC, NewVoidCArray, NewVoidCMatrix, NewVoidGCArray, NewVoidGCMatrix: high-performance functions to allocate/deallocate 1D/2D void arrays. - xchain, Chainable: to chain any number of any kind of iterable, plus now all x-something lazy iterable classes support the ~ operator to chain them. Changes: - Removed boxarray and strarray functions because they are of little use. - ExprType and xsplit simplified and improved. - 'select' module renamed to 'ranking' to avoid any name clashing with func.select. - Removed dependencies from 'meta' package, it's not included anymore.
-----------------------
I have developed the editDistanceFast/BKtree code in Python and D, and I have found that there are some advantages in developing in two (quite different) languages at a time. - If during the development I put a bug in one of the two implementations, they may give different outputs, so I am able to see there's a bug. - Optimizing the code for D allows me to focus to low level things. While if I program just in Python I seem not much able to "see" some of such details; and in this code I have found that every time I have invent a way to speed up the D code, the same trick was able to speed up the Psyco (the Python JIT) version too. - Python allows me to quickly write a program that works, that is nearly bug-free. It's great for prototyping, while developing in D is slower. Later I can usually translate the code to D. Python allows me to write very short code too, and short programs are very useful, because they often hide less bugs and you can understand them better and faster. Later I may use my D libs to translate the Python code to a very short D code (using the high-order functions, etc). While if I program in D from the start I may miss spots where I can shorten the code with little performance loss. - The short original Python code, plus the wonderful doctests allow me to set a starting point, to define what's the correct output of the code. Later I can translate the Python doctests to D unittests, and even later I can use the short and easy Python version to test if the D version is correct. - So jumping between the two languages allows me to find many things that I may miss when I develop in just one language. The result is code that is readable, debugged, short, and fast :-)
As an example of the results of such language jumping, this is the D version of the editDistance, that's back-translated from Python, showing a quite short and readable code (I have created a pair of editDistance and editDistanceFast in both languages, the fast version has limits in the length of the possible input iterables/arrays, and avoid dynamic allocations):
int editDistance(T)(T[] s1, T[] s2) {
if (len(s1) > len(s2)) { auto sa = s1; s1 = s2; s2 = sa; }
auto r1 = range(len(s2) + 1);
auto r2 = new int[len(r1)];
foreach (i, c1; s1) {
r2[0] = i + 1;
foreach (j, c2; s2)
r2[j+1] = c1 == c2 ? r1[j] : min(r2[j], r1[j], r1[j+1]) + 1;
auto ra = r1; r1 = r2; r2 = ra;
}
return r1[$ - 1];
}
While the following Psyco code is essentially back-translated from the fast D version:
def editDistanceFast(s1, s2, r1=[0]*35, r2=[0]*35):
if s1 == s2: return 0
if len(s1) > len(s2):
s1, s2 = s2, s1
len_s2 = len(s2)
assert len(s2) <= 34, "Error: one input sequence"\
"is too much long (> 34), use editDistance()."
for i in xrange(len_s2 + 1):
r1[i] = i
r2[i] = 0
i = 0
for c1 in s1:
r2[0] = i + 1
j = 0
for c2 in s2:
if c1 == c2:
r2[j+1] = r1[j]
else:
a1 = r2[j]
a2 = r1[j]
a3 = r1[j+1]
if a1 > a2:
if a2 > a3:
r2[j+1] = 1 + a3
else:
r2[j+1] = 1 + a2
else:
if a1 > a3:
r2[j+1] = 1 + a3
else:
r2[j+1] = 1 + a1
j += 1
aux = r1; r1 = r2; r2 = aux
i += 1
return r1[len_s2]
There you can even see those r1=[0]*35 and r2=[0]*35 that are a way to implement a kind of the static arrays I have used in the fast D version. The end result is that the fast D version is just 4.5 times faster than the fast Psyco version.
You can find the Python version here: http://www.fantascienza.net/leonardo/so/bktree.py | comments: 2 comments or Leave a comment  |
| Similar to the usual paste sites, but this allows to run the code too (inside a sandbox, but with 40 MB RAM or more, and for some seconds, so it can run interesting programs too). It supports C++, C, D, Python, etc, in D it supports Tango too: http://codepad.org/
Photo-realistic rendering keeps improving, this is an open source renderer that shows some stunning images: http://www.luxrender.net/
"What makes Mathematics hard to learn" article on the OLPC site by the good Marvin Minsky, he talks mostly about children: http://wiki.laptop.org/go/What_makes_Mathematics_hard_to_learn%3F
An interesting (new?) way to test programs, Test-Driven Completion (TDC) (beside using ShedSkin to find types of a dynamically typed program): http://www.eigenclass.org/repos/rcodetools/head/README | comments: Leave a comment  |
| | Tags: | links, python | | Subject: | Few links, future languages | | Time: | 02:09 pm |
|
| Few links:
Inverse regex: http://japhy.perlmonk.org/sexeger/sexeger.html
How to optimize Java REs (some of this can be used in Python too): http://www.javaworld.com/cgi-bin/mailto/x_java.cgi
Automatic book creation? http://education.guardian.co.uk/egweekly/story/0,,2252153,00.html
This looks like a good and updated MinGW distribution (for Windows), based on GCC v.4.2.1, its installation is really easy, and it already contains Boost, DSL, and lots of useful libraries: http://nuwen.net/mingw.html
Maybe C# 4.0 will have a kind of dinamic typing too (like Boo): http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx
"Inconsolata" font, useful for source code: http://www.levien.com/type/myfonts/inconsolata.html I have appreciated it a lot; it's much similar to the "Consolas" font of Windows Vista, but it fixes some of its faults (like the ? lowering * and making > < bigger, larger - ). IMHO it has few problems, like ^ being too much short, a bad looking lowercase "r", having curved " and ', having a curved "!" and lowercase "t" that are too much different from the style of the other characters, etc. See here too: Non sono il solo a far attenzione ai font per programmare: http://blog.hamstu.com/2008/02/03/the-typography-of-code/
"Evolved Code vs Enterprise Code" http://carlos.bueno.org/2008/02/evolved-code-vs-enterprise-code.html A key phrase is: >The purpose of enterprise code is to have no irreplaceable parts.< That's often the diffeence between between systems built by humans (like a bridge) and the sytems created by evolution. The first ones are made of replaceable parts, while the second ones much less. But sometimes (often?) it's the use of the complexities and side effects of the subsystems to allow natural evolution to reach its high speed.
Linq e loops: http://www.moserware.com/2008/02/for-loops-using-i-i-enumerators-or-none.html
This looks like one of the best ways I have seen to put video with pages on a site: http://www.parleys.com/display/PARLEYS/The+Closures+Controversy
I think that in less than five years this will become food for robot designers: http://sciencenow.sciencemag.org/cgi/content/full/2008/128/2<
---------------------------------
Spot the bug: http://cafe.elharo.com/programming/spot-the-bug/
The little problem:
Item Subtotal 5.89 Shipping & Handling: 3.99 Total: 9.879999999999999
Python solution:
>>> 5.89 + 3.99
9.879999999999999
>>> from decimal import Decimal as D
>>> print D("5.89") + D("3.99")
9.88
C was too much slow compared to Assembly, Python was too much slow compared to C. Python 3.0 integers are multi-precision only. Now they say adopting Decimal (IEEE 854) as standard floating point for a language like Python makes it too much slow. Time will come for a new language that's higher level than Python, with IEEE 854 as floating point, multiprecision integers, and with data copy semantics, instead of reference copy semantics as Python, because the direct copy is simpler to understand by new programmers. Having a data copy semantics doesn't mean you have to copy every array or object every time you give it to a function as argument, because the interpreter/compiler can be smart, it can use copy-on-write and other tricks to make the code fast enough for scripting purposes. Python 3.0 uses lazy iterators in many places, and the programmer has to take care of managing them correctly. The successive language may be smarter, using lazy iterators inside whenever it can, but on the outside looking as a normal eager interpreter, like old versions of Python were. ShedSkin shows that such language can even allow the user to compile some routines with static typing (mostly coming from type inference) allowing it enough speed in critical routines; and a Psyco-like JIT make it keep its speed on par with Python v.2.5.
---------------------------------
The following isn't to be taken too much seriously, probably it has many faults. After learning many languages I can describe you what's the language I'd like to use at the moment: an optimizing compiler that translates the Boo/D cross source code to optimized and well readable C++ code.
- It's not meant to be revolutionary at all, I don't need revolutions to write small programs :-) - The source code is a bit like Boo/D cross, with pointers, unions, etc., that is a statically typed (at 95%) system language with explicit types, plus some type inferencing and a bit of "duck typing" (like Boo) when useful. - The purpose is to eventually write this translator into itself, this can be done early. The first version may be written in a static subset of Python, to allow a successive easy translation to itself. - The language during all its evolution is kept strictly about as fast as C++. The language allows some higher-level operations (like duck typing, higher-order operations, etc), they are allowed to be slower than C++, but they are optimized when possible. Most programs have small parts where the max speed is necessary, while most of the program doesn't need max running speed. The language is multi-level, so where you use it like a C, it's as fast as C. This reduces the overall program length, bugs, and it may keep it about as fast as writing it all in C++. - The explicit types mean it doesn't need a strong type inferencer, so the translator is quick enough (ShedSkin compiles very slowly, and the Stalin Scheme very optimizing compiler is even slower). It has some type inferencing to allow an automatic instantiation of templates where necessary, to shorten variable definition, and to help in writing lazy/functional-style code (where it's not always easy to know the type of the iterable objects you are using). - Types are first class objects during the compilation (they are static at runtime), so you can manage them in many ways. - It's a two-staged compiler, and at compile time you can run almost any code (D has a similar capability, but it's buggy still, and there are many things you can't run at compile time). - It has a GC, and it has from the beginning some optimizing capabilities like the Java HotSpot (method inlining, de-virtualizing methods, merging loops of vector operations. And maybe "automatic" usage of multicore like Fortress. Many other things are possible, but those may allow a large enough gain). - It's not a GCC front-end so it allows people to read the C++ source it spits out, to optimize the translator itself, or to fix it, etc. - The output is C++ instead of C to avoid re-inventing lot of stuff (like class management) and because C++ compilers (like GCC 4.x) are much better than DMD at optimizing. In alternative it can be used LLVM, allowing some run time operations too. - It's a simpler language than D, and it's much simpler than C++, but it's more complex than C. It's meant to be usable to learn to program too, like Pascal once was. Lot of nice things are left out, and they are meant to be implemented as libraries, written in itself. This mean it has to be flexible and it means it has enough syntactic sugar to be allow nice looking things despite having them from a library. - Like D/C++/Python, etc, it has OOP, but it's not strictly Object Oriented. - Eventually it may become a GCC front-end (to speed up the compilation a bit avoiding the C++ code generation and parsing, etc), but this is for later, for version 1.0 of the language or later. A compilation flag can be used to make it produce C++ code instead of using the C++/LLVM backend. | comments: Leave a comment  |
|