info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How to code the Towers of Hanoi in Object Oriented Fortran?
165 views
Skip to first unread message
drik...@gmail.com
May 14, 2017, 11:10:34 AM5/14/17
to
Hi,
As a learning exercise, I have coded the Towers of Hanoi in Fortran by examining sample code from Wikipedia, "fortran.com", and "Fortran Cafe".
The implemented solution uses an auxiliary stack and I have faced two problems. At first I had to duplicate the function "push" for operator overloading. At second, I couldn't figure out how to define a function named size. Both problems are marked with a "!how-to?" comment below.
Can you recommend a workaround and perhaps a gfortran PR (maybe 79440) if applicable that would allow me combine the two push functions in one?
Ev. Drikos
PS: I don't want to upgrade gfortran now!
----------------------------------------------------------------------
module util
type Vector
integer, allocatable :: array(:)
integer :: elements=0;
integer :: size=0;
CONTAINS
procedure add ;
end type Vector
type, extends(Vector) :: Stack
CONTAINS
procedure top ;
procedure pop ;
procedure push ;
end type Stack
INTERFACE OPERATOR (+)
PROCEDURE op_push
END INTERFACE OPERATOR (+)
INTERFACE OPERATOR (==)
PROCEDURE equals
END INTERFACE OPERATOR (==)
!Obviously, a casual constructor insn't the
!best approach in Fortran. But let's try it!
interface Stack
module procedure new_Stack
end interface Stack
contains
function new_Stack(i)
integer, intent(in) :: i
type(Stack) new_Stack
allocate(new_Stack%array(i))
new_Stack%size = i
do j=1,i
new_Stack%array(j)=0;
enddo
end function
subroutine add (self, element)
class(Vector), intent(inout) :: self
integer, intent(in) :: element
integer, allocatable :: tmp(:);
if ( self%elements >= self%size ) then
!realloc (if you know Fortran)
allocate(tmp(2*size(self%array)))
tmp(1:size(self%array)) = self%array
deallocate(self%array)
self%array=tmp
endif
self%elements=self%elements+1;
self%array( self%elements ) = element;
end subroutine add
integer function pop(self)
class(Stack), intent(inout) :: self
if ( self%elements > 0 ) then
pop=self%array(self%elements)
self%array(self%elements)=0; !for display purposes!
self%elements = self%elements - 1 ;
endif
end function pop
! Instead of a function size, finally the Vector has a variable size
! integer function size(self)
! class(Vector), intent(inout) :: self
!
! size= size(self%array) !how-to?
!
! end function size
integer function top(self)
class(Stack), intent(inout) :: self
if ( self%elements > 0 ) then
top=self%array(self%elements)
else
write (*,*) "examine the stack before you try to pop an element";
error stop -1;
endif
end function top
function push(self,e)
class(Stack), intent(inout) :: self
INTEGER, INTENT (IN) :: e
type(Stack) :: push
call self%add(e);
!push=self; !how-to?
!gfortran-4.8.5
!main.f90:118:0: internal compiler error: in fold_convert_loc, at fold-const.c:2044
end function push
FUNCTION op_push(s, element)
TYPE(Stack), INTENT(IN) :: s
INTEGER, INTENT(IN) :: element
TYPE(Stack) :: op_push
op_push=s;
call op_push%add(element);
END FUNCTION op_push
FUNCTION equals(v1, v2)
class(Vector), INTENT(IN) :: v1
class(Vector), INTENT(IN) :: v2
logical :: equals
if ( v1%elements /= v2%elements) then
equals=.false.;
return ;
end if
do i=1,v2%elements
if ( v1%array(i) /=v2%array(i)) then
equals=.false.;
return ;
end if
end do;
equals=.true.;
END FUNCTION equals
end module util
PROGRAM TowersOfHanoi
use util
integer :: i,stat;
character(32) :: arg
integer :: disk, disks = 4 ;
type( Stack) A, B, C ;
! Allow user to specify number of disks
if ( command_argument_count() > 0 ) then
CALL get_command_argument(1, arg)
read(arg,*,iostat=stat) disks;
if ( stat/=0 ) then
write (*,*) "Invalid number of disks."
disks=4;
end if
END if
A = Stack(disks) ;
B = Stack(disks) ;
C = Stack(disks) ;
! Push all Disks into Stack One, from larger to smaller
do disk=disks,1,-1
A = A + disk;
end do
call show;
call move(disks, A, C, B)
if ( A == B .and. A%elements == 0 .and. C%elements == disks ) then
write (*,*) "Stacks of Hanoi have been swapped in the right order!!"
endif
CONTAINS
RECURSIVE SUBROUTINE move(disks, source, target, auxiliary)
INTEGER, INTENT (IN) :: disks
type(Stack) source, target, auxiliary
if ( disks > 0 ) THEN
call move(disks - 1, source, auxiliary, target);
target=target + source%pop() ;
call show;
call move(disks - 1, auxiliary, target , source) ;
endif
END SUBROUTINE move
subroutine show()
write (*,*) "--";
write (*,*) "A=[", a%array , " ]";
write (*,*) "B=[", b%array , " ]";
write (*,*) "C=[", c%array , " ]";
write (*,*) "--";
END SUBROUTINE show
END PROGRAM TowersOfHanoi
As a learning exercise, I have coded the Towers of Hanoi in Fortran by examining sample code from Wikipedia, "fortran.com", and "Fortran Cafe".
The implemented solution uses an auxiliary stack and I have faced two problems. At first I had to duplicate the function "push" for operator overloading. At second, I couldn't figure out how to define a function named size. Both problems are marked with a "!how-to?" comment below.
Can you recommend a workaround and perhaps a gfortran PR (maybe 79440) if applicable that would allow me combine the two push functions in one?
Ev. Drikos
PS: I don't want to upgrade gfortran now!
----------------------------------------------------------------------
module util
type Vector
integer, allocatable :: array(:)
integer :: elements=0;
integer :: size=0;
CONTAINS
procedure add ;
end type Vector
type, extends(Vector) :: Stack
CONTAINS
procedure top ;
procedure pop ;
procedure push ;
end type Stack
INTERFACE OPERATOR (+)
PROCEDURE op_push
END INTERFACE OPERATOR (+)
INTERFACE OPERATOR (==)
PROCEDURE equals
END INTERFACE OPERATOR (==)
!Obviously, a casual constructor insn't the
!best approach in Fortran. But let's try it!
interface Stack
module procedure new_Stack
end interface Stack
contains
function new_Stack(i)
integer, intent(in) :: i
type(Stack) new_Stack
allocate(new_Stack%array(i))
new_Stack%size = i
do j=1,i
new_Stack%array(j)=0;
enddo
end function
subroutine add (self, element)
class(Vector), intent(inout) :: self
integer, intent(in) :: element
integer, allocatable :: tmp(:);
if ( self%elements >= self%size ) then
!realloc (if you know Fortran)
allocate(tmp(2*size(self%array)))
tmp(1:size(self%array)) = self%array
deallocate(self%array)
self%array=tmp
endif
self%elements=self%elements+1;
self%array( self%elements ) = element;
end subroutine add
integer function pop(self)
class(Stack), intent(inout) :: self
if ( self%elements > 0 ) then
pop=self%array(self%elements)
self%array(self%elements)=0; !for display purposes!
self%elements = self%elements - 1 ;
endif
end function pop
! Instead of a function size, finally the Vector has a variable size
! integer function size(self)
! class(Vector), intent(inout) :: self
!
! size= size(self%array) !how-to?
!
! end function size
integer function top(self)
class(Stack), intent(inout) :: self
if ( self%elements > 0 ) then
top=self%array(self%elements)
else
write (*,*) "examine the stack before you try to pop an element";
error stop -1;
endif
end function top
function push(self,e)
class(Stack), intent(inout) :: self
INTEGER, INTENT (IN) :: e
type(Stack) :: push
call self%add(e);
!push=self; !how-to?
!gfortran-4.8.5
!main.f90:118:0: internal compiler error: in fold_convert_loc, at fold-const.c:2044
end function push
FUNCTION op_push(s, element)
TYPE(Stack), INTENT(IN) :: s
INTEGER, INTENT(IN) :: element
TYPE(Stack) :: op_push
op_push=s;
call op_push%add(element);
END FUNCTION op_push
FUNCTION equals(v1, v2)
class(Vector), INTENT(IN) :: v1
class(Vector), INTENT(IN) :: v2
logical :: equals
if ( v1%elements /= v2%elements) then
equals=.false.;
return ;
end if
do i=1,v2%elements
if ( v1%array(i) /=v2%array(i)) then
equals=.false.;
return ;
end if
end do;
equals=.true.;
END FUNCTION equals
end module util
PROGRAM TowersOfHanoi
use util
integer :: i,stat;
character(32) :: arg
integer :: disk, disks = 4 ;
type( Stack) A, B, C ;
! Allow user to specify number of disks
if ( command_argument_count() > 0 ) then
CALL get_command_argument(1, arg)
read(arg,*,iostat=stat) disks;
if ( stat/=0 ) then
write (*,*) "Invalid number of disks."
disks=4;
end if
END if
A = Stack(disks) ;
B = Stack(disks) ;
C = Stack(disks) ;
! Push all Disks into Stack One, from larger to smaller
do disk=disks,1,-1
A = A + disk;
end do
call show;
call move(disks, A, C, B)
if ( A == B .and. A%elements == 0 .and. C%elements == disks ) then
write (*,*) "Stacks of Hanoi have been swapped in the right order!!"
endif
CONTAINS
RECURSIVE SUBROUTINE move(disks, source, target, auxiliary)
INTEGER, INTENT (IN) :: disks
type(Stack) source, target, auxiliary
if ( disks > 0 ) THEN
call move(disks - 1, source, auxiliary, target);
target=target + source%pop() ;
call show;
call move(disks - 1, auxiliary, target , source) ;
endif
END SUBROUTINE move
subroutine show()
write (*,*) "--";
write (*,*) "A=[", a%array , " ]";
write (*,*) "B=[", b%array , " ]";
write (*,*) "C=[", c%array , " ]";
write (*,*) "--";
END SUBROUTINE show
END PROGRAM TowersOfHanoi
Jos Bergervoet
May 14, 2017, 1:44:21 PM5/14/17
to
I would think the ordinary solution is clearer:
program Hail_to_the_Great_Leader
implicit none
integer :: N_start
print *, "How many on stack 1 to start with?"
read *, N_start
print *, "OK, now moving them from stack 1 to stack 2,", &
" with use of stack 3."
call move_pile(N_start, 1, 2, 3)
contains
recursive subroutine move_pile(N, start, finish, other)
!-- Move top N items from stack "start" to stack "finish",
!-- using stack "other" as a temporary.
integer :: N, start, finish, other
if(N<1) then
!-- do nothing (recursion to the end, a la Dijkstra.)
else
call move_pile(N-1, start, other, finish)
print *, "Moving item from stack", start, " to stack", finish
call move_pile(N-1, other, finish, start)
endif
end
end
--
Jos
gera...@rrt.net
May 14, 2017, 1:59:56 PM5/14/17
to
On Sunday, May 14, 2017 at 10:10:34 AM UTC-5, drikos wrote:
> Hi,
>
> As a learning exercise, I have coded the Towers of Hanoi in Fortran by examining sample code from Wikipedia, "fortran.com", and "Fortran Cafe".
>
> The implemented solution uses an auxiliary stack and I have faced two problems. At first I had to duplicate the function "push" for operator overloading. At second, I couldn't figure out how to define a function named size. Both problems are marked with a "!how-to?" comment below.
>
> Can you recommend a workaround and perhaps a gfortran PR (maybe 79440) if applicable that would allow me combine the two push functions in one?
----[----snipped----]----
> Hi,
>
> As a learning exercise, I have coded the Towers of Hanoi in Fortran by examining sample code from Wikipedia, "fortran.com", and "Fortran Cafe".
>
> The implemented solution uses an auxiliary stack and I have faced two problems. At first I had to duplicate the function "push" for operator overloading. At second, I couldn't figure out how to define a function named size. Both problems are marked with a "!how-to?" comment below.
>
> Can you recommend a workaround and perhaps a gfortran PR (maybe 79440) if applicable that would allow me combine the two push functions in one?
The computer programming chrestomathy site Rosetta Code contains
(among other computer programming languages) Fortran examples.
For the Towers of Hanoi, the Fortran solution is:
http://rosettacode.org/wiki/Towers_of_Hanoi#Fortran
For pushing things on the stack:
http://rosettacode.org/wiki/Stack#Fortran
I can't speak if these examples use O-O techniques or not, but there
are over 515 different Fortran entries for over a 1,000 different
tasks/problems. _________________________________ Gerard Schildberger
drik...@gmail.com
May 14, 2017, 2:45:45 PM5/14/17
to
The computer programming chrestomathy site Rosetta Code contains
> (among other computer programming languages) Fortran examples.
>
Thanks for the data, I'll try to have a look at those examples.
> (among other computer programming languages) Fortran examples.
>
> For the Towers of Hanoi, the Fortran solution is:
> http://rosettacode.org/wiki/Towers_of_Hanoi#Fortran
>
Unluckily, the function pop ie returns 0 when empty and any programming errors might go unnoticed.
drik...@gmail.com
May 14, 2017, 3:12:57 PM5/14/17
to
On Sunday, May 14, 2017 at 8:44:21 PM UTC+3, Jos Bergervoet wrote:
.
> I would think the ordinary solution is clearer:
>
The example below doesn't look exactly as the classic Fortran solution or perhaps it is a Dutch translation?
> On 5/14/2017 5:10 PM, drikosev wrote:
> > Hi,
> >
> > As a learning exercise, I have coded the Towers of Hanoi in Fortran by examining sample code from Wikipedia, "fortran.com", and "Fortran Cafe".
> > ..
> > Hi,
> >
> > As a learning exercise, I have coded the Towers of Hanoi in Fortran by examining sample code from Wikipedia, "fortran.com", and "Fortran Cafe".
.
> And? What is your conclusion? Does "Object Oriented Fortran" help?
If I ever manage to learn Fortran, I may answer to your question. Meanwhile your answer doesn't' help.
> I would think the ordinary solution is clearer:
>
Jos Bergervoet
May 14, 2017, 3:47:47 PM5/14/17
to
On 5/14/2017 9:12 PM, drik...@gmail.com wrote:
> On Sunday, May 14, 2017 at 8:44:21 PM UTC+3, Jos Bergervoet wrote:
>> On 5/14/2017 5:10 PM, drikosev wrote:
>>> Hi,
>>>
>>> As a learning exercise, I have coded the Towers of Hanoi in Fortran by examining sample code from Wikipedia, "fortran.com", and "Fortran Cafe".
>>> ..
> .
>> And? What is your conclusion? Does "Object Oriented Fortran" help?
>
> If I ever manage to learn Fortran, I may answer to your question. Meanwhile your answer doesn't' help.
Of course I'll leave it to the well-known magical advantages of
> On Sunday, May 14, 2017 at 8:44:21 PM UTC+3, Jos Bergervoet wrote:
>> On 5/14/2017 5:10 PM, drikosev wrote:
>>> Hi,
>>>
>>> As a learning exercise, I have coded the Towers of Hanoi in Fortran by examining sample code from Wikipedia, "fortran.com", and "Fortran Cafe".
>>> ..
> .
>> And? What is your conclusion? Does "Object Oriented Fortran" help?
>
> If I ever manage to learn Fortran, I may answer to your question. Meanwhile your answer doesn't' help.
Object Oriented Programming to solve all problems!
>> I would think the ordinary solution is clearer:
>>
>
> The example below doesn't look exactly as the classic Fortran solution
> or perhaps it is a Dutch translation?
was a classic, that is correct!
http://en.wikipedia.org/wiki/Edsger_W._Dijkstra )
Stefano Zaghi
May 14, 2017, 4:01:46 PM5/14/17
to
Dear Jos,
Il giorno domenica 14 maggio 2017 21:47:47 UTC+2, Jos Bergervoet ha scritto:
> On 5/14/2017 9:12 PM, drik...@gmail.com wrote:
> Of course I'll leave it to the well-known magical advantages of
> Object Oriented Programming to solve all problems!
As you know, being so old..., your is simply a silly, harsh, provocation: you know, OOP is not suitable for all problems, neither it is magical and often it is really a disadvantage, but sometimes it could be applied to not suited problems just for learning...
What is surprising magical is how a distinguished scientist like you disseminate provocations on the web. Hopefully, the new generation of Fortraners will forget about "real programmers" like you that "leaves out so much without teaching nothing to who is asking for help".
My best regards.
Il giorno domenica 14 maggio 2017 21:47:47 UTC+2, Jos Bergervoet ha scritto:
> On 5/14/2017 9:12 PM, drik...@gmail.com wrote:
> Of course I'll leave it to the well-known magical advantages of
> Object Oriented Programming to solve all problems!
What is surprising magical is how a distinguished scientist like you disseminate provocations on the web. Hopefully, the new generation of Fortraners will forget about "real programmers" like you that "leaves out so much without teaching nothing to who is asking for help".
My best regards.
drik...@gmail.com
May 14, 2017, 4:39:07 PM5/14/17
to
On Sunday, May 14, 2017 at 10:47:47 PM UTC+3, Jos Bergervoet wrote:
>
> O, so you do actually know Fortran already, then?!
>
Wrong conclusion I'm afraid. Anyone who can search the WEB can compare similar solutions. Basic Fortran skills don't help too much to design a more complex solution, so came my question.
>
> O, so you do actually know Fortran already, then?!
>
Neither I'm a fan of object orientation nor I can tell how useful it could be in certain scientific applications that might interest you.
Yet, I think that recursive function calls that operate (push & pop) on the program execution stack are more expensive than operations on a user defined stack (perhaps wrong but this what I remember from my studies 25 years ago).
>
> The name Dijkstra is the only Dutch word used in it. (And he
> was a classic, that is correct!
> http://en.wikipedia.org/wiki/Edsger_W._Dijkstra )
Richard Maine
May 14, 2017, 10:26:31 PM5/14/17
to
You can define a function named size just fine, but I wouldn't recommend
it because of exactly the sort of problem you ran into. If you name a
function size, then you can't also use the intrinsic function size in
the same scope, as you try to do. That's a pretty general rule - that
you can't use the same name for two different things in the same scope.
The exact rule is more complicated (by quite a bit) and allows several
exceptions, but that's a reasonable first approximation.
I suspect that what you might want is to extend the generic size
funnction so that it can also be applied to your type. If so, you start
by defining your function, giving it some name other than size; a name
like vector_size might be a plausible choice. Then extend the generic
size with your function, probably using something like (if I recall the
syntax correctly, as I don't do this sort of thing much)
interface size
procedure vector_size
end interface size
--
Richard Maine
email: last name at domain . net
domain: summer-triangle
it because of exactly the sort of problem you ran into. If you name a
function size, then you can't also use the intrinsic function size in
the same scope, as you try to do. That's a pretty general rule - that
you can't use the same name for two different things in the same scope.
The exact rule is more complicated (by quite a bit) and allows several
exceptions, but that's a reasonable first approximation.
I suspect that what you might want is to extend the generic size
funnction so that it can also be applied to your type. If so, you start
by defining your function, giving it some name other than size; a name
like vector_size might be a plausible choice. Then extend the generic
size with your function, probably using something like (if I recall the
syntax correctly, as I don't do this sort of thing much)
interface size
procedure vector_size
end interface size
--
Richard Maine
email: last name at domain . net
domain: summer-triangle
drik...@gmail.com
May 15, 2017, 2:27:10 AM5/15/17
to
On 5/15/17 5:26 AM, Richard Maine wrote:
> I suspect that what you might want is to extend the generic size
> funnction so that it can also be applied to your type. If so, you start
> by defining your function, giving it some name other than size; a name
> like vector_size might be a plausible choice. Then extend the generic
> size with your function, probably using something like (if I recall the
> syntax correctly, as I don't do this sort of thing much)
>
> interface size
> procedure vector_size
> end interface size
>
>
This worked but only inside the module, ie subroutine add:
if ( self%elements >= size(self) ) then
end if
It is not available in the main program though and what I know to do here is nothing more than a public variable size (or perhaps no variable).
Thank you,
Ev. Drikos
> <drikosev@...> wrote:
>
>> At second, I couldn't figure out how to define a function named size.
>
> You can define a function named size just fine, but I wouldn't recommend
> it because of exactly the sort of problem you ran into. If you name a
> function size, then you can't also use the intrinsic function size in
> the same scope, as you try to do. That's a pretty general rule - that
> you can't use the same name for two different things in the same scope.
> The exact rule is more complicated (by quite a bit) and allows several
> exceptions, but that's a reasonable first approximation.
>
This doesn't make me really happy but answers my question!
>
>> At second, I couldn't figure out how to define a function named size.
>
> You can define a function named size just fine, but I wouldn't recommend
> it because of exactly the sort of problem you ran into. If you name a
> function size, then you can't also use the intrinsic function size in
> the same scope, as you try to do. That's a pretty general rule - that
> you can't use the same name for two different things in the same scope.
> The exact rule is more complicated (by quite a bit) and allows several
> exceptions, but that's a reasonable first approximation.
>
> I suspect that what you might want is to extend the generic size
> funnction so that it can also be applied to your type. If so, you start
> by defining your function, giving it some name other than size; a name
> like vector_size might be a plausible choice. Then extend the generic
> size with your function, probably using something like (if I recall the
> syntax correctly, as I don't do this sort of thing much)
>
> interface size
> procedure vector_size
> end interface size
>
>
if ( self%elements >= size(self) ) then
end if
It is not available in the main program though and what I know to do here is nothing more than a public variable size (or perhaps no variable).
Thank you,
Ev. Drikos
Stefano Zaghi
May 15, 2017, 5:31:09 AM5/15/17
to
Dear Drikos,
I have created a gist for you
https://gist.github.com/szaghi/0db612b4662ad2f0e3840a8a191b242d
It contains your exercise slightly refactored in order to show the "size" builtin overloading. It works also outside the module where it is defined.
I also added some things that I think a new Fortraner should care about (implicit none, purity, kind parametrization...), but not strictly related to your exercise.
The full code is here
https://gist.githubusercontent.com/szaghi/0db612b4662ad2f0e3840a8a191b242d/raw/5b04093762540042ddddcb62c0275787ed7c3a19/hanoi_towers.f90
A minimal description is here
https://gist.github.com/szaghi/0db612b4662ad2f0e3840a8a191b242d#oop-refactoring-of-drikos-fortran-exercise
Note that I have not your compiler (I guess a GNU gfortran 4.x): my refactor works with GNU gfortran 6.3.1 or higher. If you are using older GNU gfortran compiler, I strongly suggest to update it.
My best regards.
I have created a gist for you
https://gist.github.com/szaghi/0db612b4662ad2f0e3840a8a191b242d
It contains your exercise slightly refactored in order to show the "size" builtin overloading. It works also outside the module where it is defined.
I also added some things that I think a new Fortraner should care about (implicit none, purity, kind parametrization...), but not strictly related to your exercise.
The full code is here
https://gist.githubusercontent.com/szaghi/0db612b4662ad2f0e3840a8a191b242d/raw/5b04093762540042ddddcb62c0275787ed7c3a19/hanoi_towers.f90
A minimal description is here
https://gist.github.com/szaghi/0db612b4662ad2f0e3840a8a191b242d#oop-refactoring-of-drikos-fortran-exercise
Note that I have not your compiler (I guess a GNU gfortran 4.x): my refactor works with GNU gfortran 6.3.1 or higher. If you are using older GNU gfortran compiler, I strongly suggest to update it.
My best regards.
Jos Bergervoet
May 15, 2017, 4:01:37 PM5/15/17
to
On 5/14/2017 10:01 PM, Stefano Zaghi wrote:
> Il giorno domenica 14 maggio 2017 21:47:47 UTC+2, Jos Bergervoet ha scritto:
>> On 5/14/2017 9:12 PM, drik...@gmail.com wrote:
...
> Il giorno domenica 14 maggio 2017 21:47:47 UTC+2, Jos Bergervoet ha scritto:
>> On 5/14/2017 9:12 PM, drik...@gmail.com wrote:
...
...
>> Of course I'll leave it to the well-known magical advantages of
>> Object Oriented Programming to solve all problems!
>
> As you know, being so old..., your is simply a silly, harsh, provocation:
Where do you see something that it is "harsh" in what I wrote? You
>> Object Oriented Programming to solve all problems!
>
> As you know, being so old..., your is simply a silly, harsh, provocation:
seem to suggest now that OOP is in such a disarray that it's at the
mercy of people politely refraining to criticize it any further..
> you know, OOP is not suitable for all problems, neither it is
> magical and often it is really a disadvantage,
s'accuse".
> but sometimes it could be applied to not suited
> problems just for learning...
what OP (not to be confused with OOP) had learned from his exercise!
> Hopefully, the new generation of Fortraners will forget about
> "real programmers" like you that "leaves out so much without
> teaching nothing to who is asking for help".
slavishly solving their exercises in the way their teacher
(from the previous generation that worships OOP) thinks is right.
And of course what they want to read here then if thay ask for
help is just simple answers to their homework problems.
NB: I'm *not* saying that this is the attitude of drikosev! I'm
only admitting that you may be right in general.
--
Jos
Stefano Zaghi
May 15, 2017, 5:05:37 PM5/15/17
to
Dear Jos,
Il giorno lunedì 15 maggio 2017 22:01:37 UTC+2, Jos Bergervoet ha scritto:
> Where do you see something that it is "harsh" in what I wrote?
You wrote: "Of course I'll leave it to the well-known magical advantages of
Object Oriented Programming to solve all problems!" that is harsh because you are clearly conveying the assumption that OOP is the evil while propagating the false myth that who use OOP demonstrates the OOP advantages by means of non measurable, verifiable, reproducible, "magic" proofs.
> you seem to suggest now that OOP is in such a disarray that it's at the
> Now you do it again! You give OOP an overdose of "qui s'excuse
> s'accuse".
It could be surprising for a superb Dutch, but Latins know this before "excusatio non petita, accusatio manifesta". Nope, this is not the case. Simply your are adding silly rumor: OP is learning OOP, not applying to a real problem, thus it is common that OOP could be not suited to the problem, but this does not matter, it is really meaningless that your plain imperative version is cleaner than the OOP version: he is learning OOP Fortran...
> Exactly why I asked "what is your conclusion?" I was interested in
> what OP (not to be confused with OOP) had learned from his exercise!
He learned how overload "builtin size" by the kindness of Richard, while from your comments learned that there are still "real programmers" out there...
The point is clearly not about "to solve Hanoi's problem is better OOP or functional or other paradigm" rather to learn OOP.
> It's entirely possible. Many of them may only be interested in
> slavishly solving their exercises in the way their teacher
> (from the previous generation that worships OOP) thinks is right.
> And of course what they want to read here then if thay ask for
> help is just simple answers to their homework problems.
I hope that, reading here that there are not only "real programmers" in Fortran then they will not think that Fortran is only FORTRAN 66 where goto-is-faster...
> NB: I'm *not* saying that this is the attitude of drikosev! I'm
> only admitting that you may be right in general.
What a great step Jos, you admitting that other could be right... escusatio non petita...
My best regards.
Il giorno lunedì 15 maggio 2017 22:01:37 UTC+2, Jos Bergervoet ha scritto:
> Where do you see something that it is "harsh" in what I wrote?
Object Oriented Programming to solve all problems!" that is harsh because you are clearly conveying the assumption that OOP is the evil while propagating the false myth that who use OOP demonstrates the OOP advantages by means of non measurable, verifiable, reproducible, "magic" proofs.
> you seem to suggest now that OOP is in such a disarray that it's at the
> mercy of people politely refraining to criticize it any further..
On the contrary, I experimented a lot with OOP and I am simply honest: it is very helpful in some scenario whereas it is not in some other. You are simply prejudiced, a priori negative.
> Now you do it again! You give OOP an overdose of "qui s'excuse
> s'accuse".
> Exactly why I asked "what is your conclusion?" I was interested in
> what OP (not to be confused with OOP) had learned from his exercise!
The point is clearly not about "to solve Hanoi's problem is better OOP or functional or other paradigm" rather to learn OOP.
> It's entirely possible. Many of them may only be interested in
> slavishly solving their exercises in the way their teacher
> (from the previous generation that worships OOP) thinks is right.
> And of course what they want to read here then if thay ask for
> help is just simple answers to their homework problems.
> NB: I'm *not* saying that this is the attitude of drikosev! I'm
> only admitting that you may be right in general.
My best regards.
drik...@gmail.com
May 15, 2017, 5:14:56 PM5/15/17
to
On 5/15/17 11:01 PM, Jos Bergervoet wrote:
> On 5/14/2017 10:01 PM, Stefano Zaghi wrote:
>> Il giorno domenica 14 maggio 2017 21:47:47 UTC+2, Jos Bergervoet ha
>
> On 5/14/2017 10:01 PM, Stefano Zaghi wrote:
>> Il giorno domenica 14 maggio 2017 21:47:47 UTC+2, Jos Bergervoet ha
>
> Exactly why I asked "what is your conclusion?" I was interested in
> what OP (not to be confused with OOP) had learned from his exercise!
>
>
> what OP (not to be confused with OOP) had learned from his exercise!
>
>
> It's entirely possible. Many of them may only be interested in
> slavishly solving their exercises in the way their teacher
> (from the previous generation that worships OOP) thinks is right.
> And of course what they want to read here then if thay ask for
> help is just simple answers to their homework problems.
>
My question was what I asked and your answers are out of topic.
> slavishly solving their exercises in the way their teacher
> (from the previous generation that worships OOP) thinks is right.
> And of course what they want to read here then if thay ask for
> help is just simple answers to their homework problems.
>
As it seems, the answer to my question came from Richard Main who explained that what I was trying to do isn't supported in Fortran.
drik...@gmail.com
May 15, 2017, 5:21:05 PM5/15/17
to
On Monday, May 15, 2017 at 12:31:09 PM UTC+3, Stefano Zaghi wrote:
> Dear Drikos,
>
> I have created a gist for you
>
Thanks a lot for your time and effort.
> Dear Drikos,
>
> I have created a gist for you
>
Ev. Drikos
Jos Bergervoet
May 15, 2017, 5:22:51 PM5/15/17
to
On 5/15/2017 11:05 PM, Stefano Zaghi wrote:
> Dear Jos,
>
> Il giorno lunedì 15 maggio 2017 22:01:37 UTC+2, Jos Bergervoet ha scritto:
>
>> Where do you see something that it is "harsh" in what I wrote?
>
> You wrote: "Of course I'll leave it to the well-known magical advantages of
> Object Oriented Programming to solve all problems!" that is harsh because
> you are clearly conveying the assumption that OOP is the evil
Why is that "clearly" following from my statement that does not
> Dear Jos,
>
> Il giorno lunedì 15 maggio 2017 22:01:37 UTC+2, Jos Bergervoet ha scritto:
>
>> Where do you see something that it is "harsh" in what I wrote?
>
> You wrote: "Of course I'll leave it to the well-known magical advantages of
> Object Oriented Programming to solve all problems!" that is harsh because
> you are clearly conveying the assumption that OOP is the evil
say so?
> while propagating the false myth that who use OOP demonstrates the OOP
> advantages by means of non measurable, verifiable, reproducible, "magic"
> proofs.
making any reference to any putative habits of those who use OOP?
It would seem that such an *automatic* implication of much more
than what I simply wrote is only possible if, in fact, there really
is an elephant in the room!
So you're doing it again..
--
Jos
Stefano Zaghi
May 15, 2017, 5:24:19 PM5/15/17
to
Dear Drikos,
Il giorno lunedì 15 maggio 2017 23:14:56 UTC+2, drik...@gmail.com ha scritto:
> As it seems, the answer to my question came from Richard Main who explained that what I was trying to do isn't supported in Fortran.
why do you think it is not supported?
Richard gives you the way, have you see my example? Overloading "size" to accept your types is supported. Feel free to ask for any further help.
My best regards.
Il giorno lunedì 15 maggio 2017 23:14:56 UTC+2, drik...@gmail.com ha scritto:
> As it seems, the answer to my question came from Richard Main who explained that what I was trying to do isn't supported in Fortran.
Richard gives you the way, have you see my example? Overloading "size" to accept your types is supported. Feel free to ask for any further help.
My best regards.
Stefano Zaghi
May 15, 2017, 5:30:08 PM5/15/17
to
Il giorno lunedì 15 maggio 2017 23:22:51 UTC+2, Jos Bergervoet ha scritto:
> How do I propagate that without even mentioning it? Without even
> making any reference to any putative habits of those who use OOP?
>
> It would seem that such an *automatic* implication of much more
> than what I simply wrote is only possible if, in fact, there really
> is an elephant in the room!
>
> So you're doing it again..
>
> --
> Jos
Dear Jos,
> How do I propagate that without even mentioning it? Without even
> making any reference to any putative habits of those who use OOP?
>
> It would seem that such an *automatic* implication of much more
> than what I simply wrote is only possible if, in fact, there really
> is an elephant in the room!
>
> So you're doing it again..
>
> --
> Jos
if your "well known magical advantages of OOP to solve all problems" is a positive, sincere assertion in flavor to the fact OOP has advantages and it is not "pulling the legs who use OOP", my bad, I am very sorry to misunderstand your brilliant words... I have done it again :-)
My best regards.
drik...@gmail.com
May 15, 2017, 6:36:59 PM5/15/17
to
Could I add the following three lines in the program?
write (*,*) "START MOVING DISKS..."
write (*,*) "size(A%array)= ", size(A%array)
write (*,*) "---------------------------------- ", " whereas size(A) = ", size(A)
Thank you,
Ev. Drikos
Richard Maine
May 15, 2017, 7:04:58 PM5/15/17
to
Stefano Zaghi <stefan...@gmail.com> wrote:
> Dear Jos,
>
> Il giorno lunedì 15 maggio 2017 22:01:37 UTC+2, Jos Bergervoet ha scritto:
>
> > Where do you see something that it is "harsh" in what I wrote?
>
> You wrote: "Of course I'll leave it to the well-known magical advantages
> of Object Oriented Programming to solve all problems!" that is harsh
> because you are clearly conveying the assumption that OOP is the evil
> while propagating the false myth that who use OOP demonstrates the OOP
> advantages by means of non measurable, verifiable, reproducible, "magic"
> proofs.
I see nothing at all harsh about Jos's statement. He was making
> Dear Jos,
>
> Il giorno lunedì 15 maggio 2017 22:01:37 UTC+2, Jos Bergervoet ha scritto:
>
> > Where do you see something that it is "harsh" in what I wrote?
>
> You wrote: "Of course I'll leave it to the well-known magical advantages
> of Object Oriented Programming to solve all problems!" that is harsh
> because you are clearly conveying the assumption that OOP is the evil
> while propagating the false myth that who use OOP demonstrates the OOP
> advantages by means of non measurable, verifiable, reproducible, "magic"
> proofs.
sarcastic fun (deservedly) of people who think that OOP is the solution
to everything. That might not be you (and he did not say or imply such),
but such people do exist. It is a major nonsequitur to jump from "OOP is
not the solution to everything" to "OOP is evil." Jos sad nothing
particularly close to that OOP was evil.
Your response, on the other hand, made me majorly wince in it's harsh
and personal nature. That's the sort of thing that tempts me to swear
off this forum for a while, and that temptation was certainly renewed in
reading what I regarded as your very harsh and personal response to Jos,
both in the above quote and throughout the rest of the response.
drik...@gmail.com
May 15, 2017, 8:38:16 PM5/15/17
to
On Tuesday, May 16, 2017 at 2:04:58 AM UTC+3, Richard Maine wrote:
>
There is another thread active, "All Things Object-oriented Fortran", which seems more suitable for such a general statement.
> Stefano Zaghi wrote:
>
> > Dear Jos,
> >
> > Il giorno lunedì 15 maggio 2017 22:01:37 UTC+2, Jos Bergervoet ha scritto:
> >
> > > Where do you see something that it is "harsh" in what I wrote?
> >
> > You wrote: "Of course I'll leave it to the well-known magical advantages
> > of Object Oriented Programming to solve all problems!" that is harsh
> > because you are clearly conveying the assumption that OOP is the evil
> > while propagating the false myth that who use OOP demonstrates the OOP
> > advantages by means of non measurable, verifiable, reproducible, "magic"
> > proofs.
>
> I see nothing at all harsh about Jos's statement. He was making
> sarcastic fun (deservedly) of people who think that OOP is the solution
> to everything. ...
>
> > Dear Jos,
> >
> > Il giorno lunedì 15 maggio 2017 22:01:37 UTC+2, Jos Bergervoet ha scritto:
> >
> > > Where do you see something that it is "harsh" in what I wrote?
> >
> > You wrote: "Of course I'll leave it to the well-known magical advantages
> > of Object Oriented Programming to solve all problems!" that is harsh
> > because you are clearly conveying the assumption that OOP is the evil
> > while propagating the false myth that who use OOP demonstrates the OOP
> > advantages by means of non measurable, verifiable, reproducible, "magic"
> > proofs.
>
> I see nothing at all harsh about Jos's statement. He was making
> sarcastic fun (deservedly) of people who think that OOP is the solution
>
There is another thread active, "All Things Object-oriented Fortran", which seems more suitable for such a general statement.
FortranFan
May 15, 2017, 11:37:14 PM5/15/17
to
On Monday, May 15, 2017 at 8:38:16 PM UTC-4, drik...@gmail.com wrote:
> On Tuesday, May 16, 2017 at 2:04:58 AM UTC+3, Richard Maine wrote:
> ..
> On Tuesday, May 16, 2017 at 2:04:58 AM UTC+3, Richard Maine wrote:
> >
> > I see nothing at all harsh about Jos's statement. He was making
> > sarcastic fun (deservedly) of people who think that OOP is the solution
> > to everything. ...
> >
>
> There is another thread active, "All Things Object-oriented Fortran", which seems more suitable for such a general statement.
Indeed. In that thread, readers will note no claim is made along the lines "OOP is the solution to everything". Rather, through the text and code examples, a point is illustrated that OO paradigm can result in a lot of extra verbosity in terms of library code which will require considerable 'support infrastructure'. But the benefits can be realization of an approach to structured programming in one's libraries that is quite generalized by now in the programming domain, thus domain experts of the knowledge that is encapsulated in a 'class' can more readily understand the code, even if their programming persuasions considerably vary e.g., from Python to C++. Moreover calling programs can be compact and clear, something which the users of your libraries, which may be you yourself in a different avatar, will find useful.
> > I see nothing at all harsh about Jos's statement. He was making
> > sarcastic fun (deservedly) of people who think that OOP is the solution
> > to everything. ...
> >
>
> There is another thread active, "All Things Object-oriented Fortran", which seems more suitable for such a general statement.
@Ev. Drikos,
I suppose a point being made by Jos Bergervoet and others to you is that *as presented*, your example does NOT seem well-suited to the OO approach, especially because the important action is done by the contained procedure of your main program. What you may want to look into is one of the basic premise of OO which is encapsulation and information hiding. Accordingly, you can consider creating a 'Tower of Hanoi' class which captures all the details in a Fortran derived type; the calling program then simply intantiates an object corresonding to such a type, specifies the 'data', asks to solve the puzzle, and requests a report:
-- pseudo code --
<program> or <subprogram>
use tower_of_hanoi_m, only : tower_of_hanoi_t
..
type(tower_of_hanoi_t) :: puzzle
..
! specify the data for the puzzle
call puzzle%set_data( disks=xx, pegs=yy, cyclic=.false., ..)
! report initial state; say all the disks in right order on peg A
write( .. ) puzzle ! say using defined IO
! specify the solution approach
puzzle%solution_algorithm = <enum_hanoi>%RECURSIVE ! or iterative, or binary, or Gray-Code, etc.; specification can based on ENUMERATIONs, a fancier ! way of using named constants
! attempt a solution
call puzzle%solve( .., istat=xx, ..)
if (istat /= 0) then
! failed to solve for whatever reason; actions elided
..
end if
! report final state, including say the number of moves
write( .. ) puzzle ! say using defined IO
..
end <program> or <subprogram>
-- end pseudo code --
Once something like above has been implemented robustly for a general, broad-purpose application of the Tower of Hanoi puzzle with encapsulation of many different solution algorihtms and scenarios (e.g., different number of disks and/or pegs, cyclic arrangement of pegs, etc.), the 'class' that may be part of some program library can be 'consumed' more readily by a calling program which may a simulation program for neurological research that facilitates, say, analysis of certain psychological factors, or one that is simply doing some animations of disks getting moved for some visual presentation layer, and so forth. The idea is easier reuse of the library code. In the absence of such a broad-based approach, the use of OO can become an overkill - it's something to keep in mind as part of your learning exercise.
By the way, if you are interested in learning OO facilities in Fortran further, then please note your compiler version of gfortran 4.8 will pose debilitating limitations due to missing feature implementations relative to the current Fortran standard as well as compiler bugs. I personally would suggest version 4.9.1 or greater, preferably 6.2 if not the latest 7.1.
Stefano Zaghi
May 15, 2017, 11:42:55 PM5/15/17
to
Dear Richard,
Il giorno martedì 16 maggio 2017 01:04:58 UTC+2, Richard Maine ha scritto:
> I see nothing at all harsh about Jos's statement. He was making
> sarcastic fun (deservedly) of people who think that OOP is the solution
> to everything.
"Sarcastic fun" is quite close to "pulling the legs". If my answer was too much hard, my bad, you have sincere apologize.
> That might not be you (and he did not say or imply such),
> but such people do exist.
You can surely leave out "might", it is so obvious that seems you are doing a slight "sarcastic fun". I know such people exist, but I cannot remember one posting into this group, can you cite someone?
> It is a major nonsequitur to jump from "OOP is
> not the solution to everything" to "OOP is evil." Jos sad nothing
> particularly close to that OOP was evil.
You are right, he does not this nothing such explicit, all was "implicit" like a "real programmer" should do. If it is not clear, my is sarcastic fun, not harsh :-)
> Your response, on the other hand, made me majorly wince in it's harsh
> and personal nature. That's the sort of thing that tempts me to swear
> off this forum for a while, and that temptation was certainly renewed in
> reading what I regarded as your very harsh and personal response to Jos,
> both in the above quote and throughout the rest of the response.
My bad, I hope you never leave us. I'll try be more kind with Jos that is probably the only here that is able to dig out my "sarcastic fun" nature.
My best regards.
Il giorno martedì 16 maggio 2017 01:04:58 UTC+2, Richard Maine ha scritto:
> I see nothing at all harsh about Jos's statement. He was making
> sarcastic fun (deservedly) of people who think that OOP is the solution
> to everything.
> That might not be you (and he did not say or imply such),
> but such people do exist.
> It is a major nonsequitur to jump from "OOP is
> not the solution to everything" to "OOP is evil." Jos sad nothing
> particularly close to that OOP was evil.
> Your response, on the other hand, made me majorly wince in it's harsh
> and personal nature. That's the sort of thing that tempts me to swear
> off this forum for a while, and that temptation was certainly renewed in
> reading what I regarded as your very harsh and personal response to Jos,
> both in the above quote and throughout the rest of the response.
My best regards.
Richard Maine
May 15, 2017, 11:58:02 PM5/15/17
to
Stefano Zaghi <stefan...@gmail.com> wrote:
> Il giorno martedì 16 maggio 2017 01:04:58 UTC+2, Richard Maine ha scritto:
> > He was making
> > sarcastic fun (deservedly) of people who think that OOP is the solution
> > to everything.
> > ...
> Il giorno martedì 16 maggio 2017 01:04:58 UTC+2, Richard Maine ha scritto:
> > He was making
> > sarcastic fun (deservedly) of people who think that OOP is the solution
> > to everything.
> > That might not be you (and he did not say or imply such),
> > but such people do exist.
>
> You can surely leave out "might", it is so obvious that seems you are
>doing a slight "sarcastic fun". I know such people exist, but I cannot
>remember one posting into this group, can you cite someone?
The "might" was more to say that I was not commenting about you at all.
> > but such people do exist.
>
> You can surely leave out "might", it is so obvious that seems you are
>doing a slight "sarcastic fun". I know such people exist, but I cannot
>remember one posting into this group, can you cite someone?
Not really sarcastic, but more a fairly common form of avoidance of
something that otherwise could possibly be misinterpreted as making a
statement about someone in particular when it was not meant to.
I can't cite a case off-hand. I recall it has happened, but that's not
the sort of thing I'd recall the details of and it isn't worth trying to
search (besides which, that would not be a trivial thing to search for,
as it generaly doesn't involve the literal words "OOP is the solution to
everything.") It doesn't tend to happen a lot here and i'm not sure I
recall it happening recently.
Stefano Zaghi
May 16, 2017, 12:11:00 AM5/16/17
to
Dear Richard,
Il giorno martedì 16 maggio 2017 05:58:02 UTC+2, Richard Maine ha scritto:
> The "might" was more to say that I was not commenting about you at all.
I knew, mine was "sarcastic fun" not your.
> I can't cite a case off-hand. I recall it has happened, but that's not
> the sort of thing I'd recall the details of and it isn't worth trying to
> search (besides which, that would not be a trivial thing to search for,
> as it generaly doesn't involve the literal words "OOP is the solution to
> everything.") It doesn't tend to happen a lot here and i'm not sure I
> recall it happening recently.
Thank you for your insight. My memory cannot go far from "recently".
My best regards.
Il giorno martedì 16 maggio 2017 05:58:02 UTC+2, Richard Maine ha scritto:
> The "might" was more to say that I was not commenting about you at all.
> I can't cite a case off-hand. I recall it has happened, but that's not
> the sort of thing I'd recall the details of and it isn't worth trying to
> search (besides which, that would not be a trivial thing to search for,
> as it generaly doesn't involve the literal words "OOP is the solution to
> everything.") It doesn't tend to happen a lot here and i'm not sure I
> recall it happening recently.
My best regards.
Stefano Zaghi
May 16, 2017, 12:16:13 AM5/16/17
to
yes you can, surely with GNU gfortran 6.3+, but I think it does not with GNU gfortran 4.x.
As FortranFan pointed out, doing Fortran OOP with GNU gfortran 4.x is a very complicated mission: note that PGI has not complete support of Fortran 2003/2008. If you can install PGI why do you not update GNU gfortran? Compiling GNU gcc from source is quite easy in GNU Linux and I think here there are many who can help you install recent versions on MS Windows or iOS.
My best regards.
0 new messages