I'm thinking of retiring my trusty 17" laptop as my main PC and going quad core.I want to do it on the cheap, so was thinking of building from parts for hopefully arounf £400 and adding this monitor, or this TV/monitor. The screens are made by the same company and look very much the same except the TV version has extra inputs and a TV tuner. I wonder if anyone has this TV connected to a PC and can comment?
I don't play graphic-intensive games so can get away with a basic graphics card.
I want the quad cores to try out more parallel programming. I have a VCD to toggle count program that reads a large VCD file . I would like to work out how to accurately do this on the four cores and see how close to linear speed-up I can get. Our regression simulations at work leave behind approximately 20K simulation logs and coverage databases - I'm starting to think of ways of data-mining them which would be aided by parallel processing (most of works compute farm PC's have between 8 and 16 cores).
Priority would go to getting a little X-at-a-time script moved from bash to Python. Given a list of jobs to do - one per line in a file; the original bash script will execute X of them in the background, starting more, when others finish.
So, if you have any ideas of cheap bundles for creating quad-core PC's (In the UK), fire away :-)
- Paddy,
Sunday, November 30, 2008
Saturday, November 15, 2008
Smearing the Static vs Dynamic Typing Dichotomy
CPython
needs to ship with a compiler!
There, I've said it. But what
are my reasons?
I truly believe that your
programming language influences the way you go about solving a problem,
and their is a mindset to programming in a dynamic language like
Python/Perl/TCL/AWK/... that can lead to different types solutions (and
even perceived problems), than programmers in say
Java/C/C++/C#. (OK some of the differences are also down to other
factors such as IDE's and OS which also affect how you solve an issue).
Lately
I have seen
posts commenting on the 4.0 release of C# will be
adding dynamic type resolution capabilities via a keyword that will
allow C# to finally do Duck Typing. The
done this trick from its outset. Thinking about it though, I don't
think it will make C# programmers style change to mimic that of
dynamic language programmers as they would have to stick their keyword
on every definition and leave behind their perceived safety of run-time
type checking. They will, I think,rather use it as another resource
that they can dip into, forming rules/design patterns on where it fits
best and use it from overwhelmingly statically typed source code.
When
I look critically at Python, (yep - I do do that from time to time),
Python 3.0 has optional type decorations - but no compiler,
and Python distributions such as Enthoughts, include external modules
to help in creating compiled code to link to Python,, but we need to
have a complete solution out of the box i.e. CPython should be shipped
with a defined method of compiling 'Python-like' source code into
machine code as part of its standard library and enshrined in the
reference guide. That would allow Python programmers to do the opposite
of what the C# programmers can do: write a mainly dynamic program -
with dynamic language idioms, but be able to seamlessly have part of
their recognisable Python code compiled . Maybe all it would take is
the addition of a new static
keyword to apply to classes/functions/modules.
You
would need to think of static/dynamic as a continuum where instead of
having languages bunched at either end, you would have a smearing out
towards the middle.
Existing languages have too much
static vs dynamic baggage, but maybe a new language with type
inferencing and where you were forced to first define the default type
checking regime as either dynamic or static, then be given the option
of declaring particular 'things' as being at either run-time or
compile-time would lead to a language that might breed new
programmers with more interesting ways to solve problems.
-
Paddy.
needs to ship with a compiler!
There, I've said it. But what
are my reasons?
I truly believe that your
programming language influences the way you go about solving a problem,
and their is a mindset to programming in a dynamic language like
Python/Perl/TCL/AWK/... that can lead to different types solutions (and
even perceived problems), than programmers in say
Java/C/C++/C#. (OK some of the differences are also down to other
factors such as IDE's and OS which also affect how you solve an issue).
Lately
I have seen
posts commenting on the 4.0 release of C# will be
adding dynamic type resolution capabilities via a keyword that will
allow C# to finally do Duck Typing. The
done this trick from its outset. Thinking about it though, I don't
think it will make C# programmers style change to mimic that of
dynamic language programmers as they would have to stick their keyword
on every definition and leave behind their perceived safety of run-time
type checking. They will, I think,rather use it as another resource
that they can dip into, forming rules/design patterns on where it fits
best and use it from overwhelmingly statically typed source code.
When
I look critically at Python, (yep - I do do that from time to time),
Python 3.0 has optional type decorations - but no compiler,
and Python distributions such as Enthoughts, include external modules
to help in creating compiled code to link to Python,, but we need to
have a complete solution out of the box i.e. CPython should be shipped
with a defined method of compiling 'Python-like' source code into
machine code as part of its standard library and enshrined in the
reference guide. That would allow Python programmers to do the opposite
of what the C# programmers can do: write a mainly dynamic program -
with dynamic language idioms, but be able to seamlessly have part of
their recognisable Python code compiled . Maybe all it would take is
the addition of a new static
keyword to apply to classes/functions/modules.
You
would need to think of static/dynamic as a continuum where instead of
having languages bunched at either end, you would have a smearing out
towards the middle.
Existing languages have too much
static vs dynamic baggage, but maybe a new language with type
inferencing and where you were forced to first define the default type
checking regime as either dynamic or static, then be given the option
of declaring particular 'things' as being at either run-time or
compile-time would lead to a language that might breed new
programmers with more interesting ways to solve problems.
-
Paddy.
Sunday, November 02, 2008
Subscribe to:
Posts (Atom)
Hi,
I thought I'd go through your tutorial on Python and make some notes if thats OK.
"No ++ / --":
I think this was the same kind of decision as Python not allowing assignments in if conditionals. There is a a high instance of problems caused by confusion over the misuse of increment/decrement operators in languages like C. They can make it harder to read a program.
"Slow in comparison to compiled languages" - (Here comes the dynamic language supporters usual reply): Yes, but often getting something right is much more important and often never requires the speep that Python gives you. People have prototyped in Python and shipped the prototype as it fits all quality metrics in a far shorter development time. I recently had a case of that myself here.
"Whitespace for indentation": Arguably a positive feature. It should read "whitespace for block delineation" or something. Run a pretty printer on say a C source file and it will try and indent it so that the visible level of indentation mirrors the logical structure of the code. Code is hard to read if the indentation does not follow the logic. Python recognises this and goes further in saying that the common use of block start and end delimeters such as {/} or begin/end are superfluous and only help in writing misleading code.
You seem to have missed the importance of docstrings in Python.
range "(good for indexing)": True, but in idiomatic Python you are much more likely to iterate over the members of a collection object rather than create an index using range:
for x in my_list:
rather than:
for i in range(len(my_list)):
....x = my_list[i]
"Functions work in python much like they do any other language": those with only Java and C experience might miss out on the extended argument passing of Python functions if not made aware.
"Classes are more basic than what you will be use to from java": In what way? There maybe less to learn to become equally proficient but I see this as a good thing. Note that Python is dynamic, meaning that, if you wanted to, you can modify classes and instances at run-time. Its not necessarily a X language does classes better than Y. Python does things differently and if you try and constrain Python to how you use OO in Java, you won't get the best from it.
"from os import *": It's a bad Python habit. You want to warn students off this, as maintenance can suffer.
"We can raise our own exceptions": It could be but shouldn't be a string. best to use an exception type.
"Numbers": There are decimals too, which are good for financial calculations.
"Tuples": If each position in a sequence has explicit meaning then you should use a tuple, e.g. a point on a surface might be the tuple (x,y). coordinates of a car would more likely be a list of points.
"Strings": Misses triple quoted strings.
Filter and map, although present, have declined in use due to the later addition of the powerful list comprehension and generator comprehension features.
One-liners in Python: Difficult to do. Usually people write multi-line scripts in an editor. In a shell such as bash which has multi-line string delimeters you might be able to use a multi-line single quote for bash and embed a multi-line python program using Pythons -c argument and restricting your Python to double quotes if needed.
Have fun with Python.
- Paddy.
Ouch!
My notes are longer than your blog entry :-)