Existentialist integers and the like
So, obviously I haven't had a life lately and my journal reflects this. This entry will continue the trend.
Python
I'm ready to go back on several of the points I was trying to make on the last entry. To be honest, it seems as though Python(x,y) is only good for a scant few things. Actually, it seems that it's overwhelmingly unhelpful in the area of Python modules, and mostly has utility in including applications that aid in program development.
There's that, and most of what Python(x,y) includes isn't really relevant to me. The Qt GUI stuff looks very well made, but I don't have the time or the [care] to do anything with it. And I'm only growing fonder of Crimson Editor as real IDEs continue to fail to keep my attention.
I've had a little bit more trouble in the area of compatibility. Things didn't start blowing up until I got into the domain of fancy stuff, but at one point I even tried GTK and then found out just how buggy this stuff can be. I even found ad-hock fixes for some of the compatibility issues.
Anyway, I was getting SO frustrated with all the junk I had been installing on my computer that I got to the point where I was thinking "I give up, I need a new computer!". And on that computer (if I had it), I would install from v2.5 and I've been getting together a list of files I would use in that case. Here's what I have so far.
File:PyQt-Py2.5-gpl-4.4.3-1.exe
gtk
File:pycairo-1.8.2.win32-py25.exe
File:pygobject-2.20.0.win32-py25.exe
File:pygtk-2.16.0.win32-py25.exe
File:matplotlib-0.99.1.win32-py2.5.exe
File:numpy-1.3.0-win32-superpack-python2.5.exe
File:pywin32-214.win32-py2.5.exe
File:scipy-0.7.1-win32-superpack-python2.5.exe
File:xlutils-1.4.1.win32.exe
I haven't really been able to work on this lately, but once I get around to it, I do want to get a new computer and then do crazy fun stuff on it. Getting all the left-field python modules to work on it is top of my list :D
----
Moving on, I've managed to do quite a number of useful things and while it might not have saved me time yet, every graph that I produce with Python is perfectly traceable in terms of how I arrived it, meaning that I seem to actually be developing *gasp* logically configured source that compliment my research writings.
Fortran
I'm also gaining some new abilities in Fortran. This has been prompted completely from a need I have had to do a particular thing, and in no way research for the point of learning more programing methods. I can genuinely say that the only way I've been getting into to Fortran objects is because it has become exceedingly difficult to do what I'm working on without them.
Mainly, up until now I've kept everything fairly well organized in a module/interface basis. If a set of variables are associated with a particular routine or set of routines, then fine, then I'll just attach the "use" statement for all the relevant data and pass things that way. The problem I ran into was.... I needed to have a set of routines that applied for a large set of data, with this data set replicated several times.
Do you see what I just did there? I effectively defined a class by my problem statement. I cast a type that contains all the associated data and then have routines that operates on that data. There are an awful lot of quirks associated with Fortran it would seem though. For instance, it appears that while variables are encapsulated in a user defined type, functions and subroutines only exist in modules.
Anyway, that's not even what I want to talk about here. Another neat thing that has just suddenly become invaluable to me is optional arguments. So I found and example, and noticed some odd behavior. Of course do link to the foo where credit is due.
The following program apparently works:
program footest
write(*,*) ' im a foo ',foo(1.2)
write(*,*) ' im a foo too ',foo(1.2,3)
contains
function foo(a, b)
real :: foo
real, intent(in) :: a
integer, intent(in), optional :: b
if (present(b)) then
foo = a**b
else
foo = a
end if
end function foo
end program footest
But this program does not.
program footest
write(*,*) ' im a foo ',foo(1.2)
write(*,*) ' im a foo too ',foo(1.2,3)
end program footest
function foo(a, b)
real :: foo
real, intent(in) :: a
integer, intent(in), optional :: b
if (present(b)) then
foo = a**b
else
foo = a
end if
end function foo
The optional argument stuff apparently works when you have the routine in a module or in a contains statement. I really am stretched to think of why it should not work as a stand alone function. But that's how it is it would seem.
I think the reason I don't strongly like the Fortran modules and interfaces is because I really just don't understand them. At least with Java I knew that I didn't understand them and there was ample documentation detailing exactly why I never will.
Python
I'm ready to go back on several of the points I was trying to make on the last entry. To be honest, it seems as though Python(x,y) is only good for a scant few things. Actually, it seems that it's overwhelmingly unhelpful in the area of Python modules, and mostly has utility in including applications that aid in program development.
There's that, and most of what Python(x,y) includes isn't really relevant to me. The Qt GUI stuff looks very well made, but I don't have the time or the [care] to do anything with it. And I'm only growing fonder of Crimson Editor as real IDEs continue to fail to keep my attention.
I've had a little bit more trouble in the area of compatibility. Things didn't start blowing up until I got into the domain of fancy stuff, but at one point I even tried GTK and then found out just how buggy this stuff can be. I even found ad-hock fixes for some of the compatibility issues.
Anyway, I was getting SO frustrated with all the junk I had been installing on my computer that I got to the point where I was thinking "I give up, I need a new computer!". And on that computer (if I had it), I would install from v2.5 and I've been getting together a list of files I would use in that case. Here's what I have so far.
File:PyQt-Py2.5-gpl-4.4.3-1.exe
gtk
File:pycairo-1.8.2.win32-py25.exe
File:pygobject-2.20.0.win32-py25.exe
File:pygtk-2.16.0.win32-py25.exe
File:matplotlib-0.99.1.win32-py2.5.exe
File:numpy-1.3.0-win32-superpack-python2.5.exe
File:pywin32-214.win32-py2.5.exe
File:scipy-0.7.1-win32-superpack-python2.5.exe
File:xlutils-1.4.1.win32.exe
I haven't really been able to work on this lately, but once I get around to it, I do want to get a new computer and then do crazy fun stuff on it. Getting all the left-field python modules to work on it is top of my list :D
----
Moving on, I've managed to do quite a number of useful things and while it might not have saved me time yet, every graph that I produce with Python is perfectly traceable in terms of how I arrived it, meaning that I seem to actually be developing *gasp* logically configured source that compliment my research writings.
Fortran
I'm also gaining some new abilities in Fortran. This has been prompted completely from a need I have had to do a particular thing, and in no way research for the point of learning more programing methods. I can genuinely say that the only way I've been getting into to Fortran objects is because it has become exceedingly difficult to do what I'm working on without them.
Mainly, up until now I've kept everything fairly well organized in a module/interface basis. If a set of variables are associated with a particular routine or set of routines, then fine, then I'll just attach the "use" statement for all the relevant data and pass things that way. The problem I ran into was.... I needed to have a set of routines that applied for a large set of data, with this data set replicated several times.
Do you see what I just did there? I effectively defined a class by my problem statement. I cast a type that contains all the associated data and then have routines that operates on that data. There are an awful lot of quirks associated with Fortran it would seem though. For instance, it appears that while variables are encapsulated in a user defined type, functions and subroutines only exist in modules.
Anyway, that's not even what I want to talk about here. Another neat thing that has just suddenly become invaluable to me is optional arguments. So I found and example, and noticed some odd behavior. Of course do link to the foo where credit is due.
The following program apparently works:
program footest
write(*,*) ' im a foo ',foo(1.2)
write(*,*) ' im a foo too ',foo(1.2,3)
contains
function foo(a, b)
real :: foo
real, intent(in) :: a
integer, intent(in), optional :: b
if (present(b)) then
foo = a**b
else
foo = a
end if
end function foo
end program footest
But this program does not.
program footest
write(*,*) ' im a foo ',foo(1.2)
write(*,*) ' im a foo too ',foo(1.2,3)
end program footest
function foo(a, b)
real :: foo
real, intent(in) :: a
integer, intent(in), optional :: b
if (present(b)) then
foo = a**b
else
foo = a
end if
end function foo
The optional argument stuff apparently works when you have the routine in a module or in a contains statement. I really am stretched to think of why it should not work as a stand alone function. But that's how it is it would seem.
I think the reason I don't strongly like the Fortran modules and interfaces is because I really just don't understand them. At least with Java I knew that I didn't understand them and there was ample documentation detailing exactly why I never will.