Probably a dumb mistake, but I just can't see it

6 messages Options
Embed this post
Permalink
Chris Saunders-4

Probably a dumb mistake, but I just can't see it

Reply Threaded More More options
Print post
Permalink
I'm going to include perhaps more code than is necessary here.  I've been
working fairly hard trying to find bugs in EiffelStudio 6.5.  I've created
two classes, one is an expanded version of the other.  I'm having a probem,
the source of which is, I think, in my code.  I have been inspecting an
testing this for a few days and just cannot find the source of the problem.
First the classes and then I'll describe the problem:

class
 REAL_NUMBER_32_REF

inherit
 ALGEBRAIC_REAL_NUMBER [REAL_32]
  rename
   to_eiffel_type as to_real_32
  redefine
   default_create,
   is_equal,
   make
  end

create
 default_create, make

feature {NONE} -- Initialization

 default_create
   -- Initialization for `Current'.
   -- Create `item'.
  do
   epsilon := Flt_epsilon
  ensure then
   epsilon_set: epsilon = Flt_epsilon
  end

 make (v: like item)
   -- Initialization for `Current'.
   -- Set `item' to `v'.
  do
   epsilon := Flt_epsilon
   item := v
  ensure then
   epsilon_set: epsilon = Flt_epsilon
  end

 make_from_integer (v: INTEGER)
   -- Initialization for current object.
   -- Set `item' to `v'.
  do
   item := v.to_real
   epsilon := Flt_epsilon
  ensure
   item_set: item = v.to_real
  end

 make_from_real_64 (v: REAL_64)
   -- Initialization for current object.
   -- Set `item' to `v'.
  do
   item := v.truncated_to_real
   epsilon := Flt_epsilon
  ensure
   item_set: item = v.truncated_to_real
  end

 make_from_reference (v: REAL_NUMBER_32_REF)
   -- Initialization for current object.
   -- Set `item' to `v.item'.
  do
   item := v.item
   epsilon := v.epsilon
  ensure
   item_set: item = v.item
   epsilon_set: epsilon = v.epsilon
  end

feature -- Access

 epsilon: REAL_32 assign set_epsilon
   -- Used for redifinition of `is_equal'.

feature -- Comparison

 is_equal (other: like Current): BOOLEAN
   -- Is `other' attached to an object of the same type
   -- as current object and identical to it?
  do
   Result := (item - other.item).abs <= epsilon
  end

feature -- Element change

 set_epsilon (v: like epsilon)
   -- Set `epsilon' to `v'.
  do
   epsilon := v
  ensure
   epsilon_set: epsilon = v
  end

feature -- Conversion

 to_real_64: REAL_64
   -- Convert current object to a REAL_64.
  do
   Result := item.to_double
  ensure
   good_result: Result = item.to_double
  end

feature {NONE} -- Externals

 Flt_epsilon: REAL_32
   --
   --
  external
   "C inline use <float.h>"
  alias
   "[
    return FLT_EPSILON;
   ]"
  end

invariant
 epsilon_large_enough: epsilon >= Flt_epsilon

end

expanded class
 REAL_NUMBER_32

inherit
 REAL_NUMBER_32_REF

create
 default_create,
 make,
 make_from_integer,
 make_from_real_64,
 make_from_reference

convert
 make ({REAL_32}),
 make_from_integer ({INTEGER}),
 make_from_real_64 ({REAL_64}),
 make_from_reference ({REAL_NUMBER_32_REF}),
 to_real_32: {REAL_32},
 to_real_64: {REAL_64}

end

In my test code I have this declaration "a: REAL_NUMBER_32" and what follows
is part of my test code:

 make
   -- Run application.
  do
   a := 1.2
   print ("a.epsilon = "); print (a.epsilon); cr
  end

Now, if I run the code as seen above the output is "a.epsilon = 0" and if I
comment out the line "a := 1.2" the output is "a.epsilon = 1.19209e-007".
Both `default_create' and `make_from_real_64' and all the other
initialization procedures set `epsilon' so I can't see how  `a' can ever be
created with `epsilon set to 0.  Sorry for showing this much code but I am
stumped and thought that reducing it might cause me to not include something
important.  Any help truely appreciated.

Regards
Chris Saunders

Jimmy Johnson

Re: Probably a dumb mistake, but I just can't see it

Reply Threaded More More options
Print post
Permalink
Chris,

I am by no means the expert that the ISE folks are but I am not busy right now so maybe I can help.

I tried to recreate your problem from the files you sent but I do not get "0"; I get the epsilon you expected.  However, the class ALGEGRAIC_REAL_NUMBER was missing so I made some assumptions.  Also, I am on a 32 bit machine; not sure how Eiffel handles entities declared as 64 bit.  Probably doesn't work.

If you would like, zip up your files and send them to my email and I will take a look:
jimmy.johnson at windstream.net.

jjj


--- In [hidden email], "Chris Saunders" <evas@...> wrote:

>
> I'm going to include perhaps more code than is necessary here.  I've been
> working fairly hard trying to find bugs in EiffelStudio 6.5.  I've created
> two classes, one is an expanded version of the other.  I'm having a probem,
> the source of which is, I think, in my code.  I have been inspecting an
> testing this for a few days and just cannot find the source of the problem.
> First the classes and then I'll describe the problem:
>
> class
>  REAL_NUMBER_32_REF
>
> inherit
>  ALGEBRAIC_REAL_NUMBER [REAL_32]
>   rename
>    to_eiffel_type as to_real_32
>   redefine
>    default_create,
>    is_equal,
>    make
>   end
>
> create
>  default_create, make
>
> feature {NONE} -- Initialization
>
>  default_create
>    -- Initialization for `Current'.
>    -- Create `item'.
>   do
>    epsilon := Flt_epsilon
>   ensure then
>    epsilon_set: epsilon = Flt_epsilon
>   end
>
>  make (v: like item)
>    -- Initialization for `Current'.
>    -- Set `item' to `v'.
>   do
>    epsilon := Flt_epsilon
>    item := v
>   ensure then
>    epsilon_set: epsilon = Flt_epsilon
>   end
>
>  make_from_integer (v: INTEGER)
>    -- Initialization for current object.
>    -- Set `item' to `v'.
>   do
>    item := v.to_real
>    epsilon := Flt_epsilon
>   ensure
>    item_set: item = v.to_real
>   end
>
>  make_from_real_64 (v: REAL_64)
>    -- Initialization for current object.
>    -- Set `item' to `v'.
>   do
>    item := v.truncated_to_real
>    epsilon := Flt_epsilon
>   ensure
>    item_set: item = v.truncated_to_real
>   end
>
>  make_from_reference (v: REAL_NUMBER_32_REF)
>    -- Initialization for current object.
>    -- Set `item' to `v.item'.
>   do
>    item := v.item
>    epsilon := v.epsilon
>   ensure
>    item_set: item = v.item
>    epsilon_set: epsilon = v.epsilon
>   end
>
> feature -- Access
>
>  epsilon: REAL_32 assign set_epsilon
>    -- Used for redifinition of `is_equal'.
>
> feature -- Comparison
>
>  is_equal (other: like Current): BOOLEAN
>    -- Is `other' attached to an object of the same type
>    -- as current object and identical to it?
>   do
>    Result := (item - other.item).abs <= epsilon
>   end
>
> feature -- Element change
>
>  set_epsilon (v: like epsilon)
>    -- Set `epsilon' to `v'.
>   do
>    epsilon := v
>   ensure
>    epsilon_set: epsilon = v
>   end
>
> feature -- Conversion
>
>  to_real_64: REAL_64
>    -- Convert current object to a REAL_64.
>   do
>    Result := item.to_double
>   ensure
>    good_result: Result = item.to_double
>   end
>
> feature {NONE} -- Externals
>
>  Flt_epsilon: REAL_32
>    --
>    --
>   external
>    "C inline use <float.h>"
>   alias
>    "[
>     return FLT_EPSILON;
>    ]"
>   end
>
> invariant
>  epsilon_large_enough: epsilon >= Flt_epsilon
>
> end
>
> expanded class
>  REAL_NUMBER_32
>
> inherit
>  REAL_NUMBER_32_REF
>
> create
>  default_create,
>  make,
>  make_from_integer,
>  make_from_real_64,
>  make_from_reference
>
> convert
>  make ({REAL_32}),
>  make_from_integer ({INTEGER}),
>  make_from_real_64 ({REAL_64}),
>  make_from_reference ({REAL_NUMBER_32_REF}),
>  to_real_32: {REAL_32},
>  to_real_64: {REAL_64}
>
> end
>
> In my test code I have this declaration "a: REAL_NUMBER_32" and what follows
> is part of my test code:
>
>  make
>    -- Run application.
>   do
>    a := 1.2
>    print ("a.epsilon = "); print (a.epsilon); cr
>   end
>
> Now, if I run the code as seen above the output is "a.epsilon = 0" and if I
> comment out the line "a := 1.2" the output is "a.epsilon = 1.19209e-007".
> Both `default_create' and `make_from_real_64' and all the other
> initialization procedures set `epsilon' so I can't see how  `a' can ever be
> created with `epsilon set to 0.  Sorry for showing this much code but I am
> stumped and thought that reducing it might cause me to not include something
> important.  Any help truely appreciated.
>
> Regards
> Chris Saunders
>


Chris Saunders-4

Re: Re: Probably a dumb mistake, but I just can't see it

Reply Threaded More More options
Print post
Permalink
 Thanks for the offer Jim.  I would be glad to send the entire project but I
would need your personal email as I can't send attachments through this
group.  My personal email is [hidden email] so you can reply there
is you fear making your personal email public.  I would compress the project
with WinRAR and perhaps you could let me know if this is a problem.  I do
know that 7-Zip can extract it.  I'm using a 64-bit machine and thereby it
is possible that you could have some problems with the project that, I
think, you could fix in the project settings.  Otherwise, you should not
have a problem as all classes that have "_64" at the end of their name
relate to REAL_64.  Thanks again for the offer.

Regards
Chris Saunders

----- Original Message -----
From: boxer41a
To: [hidden email]
Sent: Wednesday, September 02, 2009 4:49 PM
Subject: [eiffel_software] Re: Probably a dumb mistake, but I just can't see
it


  Chris,

I am by no means the expert that the ISE folks are but I am not busy right
now so maybe I can help.

I tried to recreate your problem from the files you sent but I do not get
"0"; I get the epsilon you expected. However, the class
ALGEGRAIC_REAL_NUMBER was missing so I made some assumptions. Also, I am on
a 32 bit machine; not sure how Eiffel handles entities declared as 64 bit.
Probably doesn't work.

If you would like, zip up your files and send them to my email and I will
take a look:
jimmy.johnson at windstream.net.

jjj

--- In [hidden email], "Chris Saunders" <evas@...> wrote:

>
> I'm going to include perhaps more code than is necessary here. I've been
> working fairly hard trying to find bugs in EiffelStudio 6.5. I've created
> two classes, one is an expanded version of the other. I'm having a probem,
> the source of which is, I think, in my code. I have been inspecting an
> testing this for a few days and just cannot find the source of the
> problem.
> First the classes and then I'll describe the problem:
>
> class
> REAL_NUMBER_32_REF
>
> inherit
> ALGEBRAIC_REAL_NUMBER [REAL_32]
> rename
> to_eiffel_type as to_real_32
> redefine
> default_create,
> is_equal,
> make
> end
>
> create
> default_create, make
>
> feature {NONE} -- Initialization
>
> default_create
> -- Initialization for `Current'.
> -- Create `item'.
> do
> epsilon := Flt_epsilon
> ensure then
> epsilon_set: epsilon = Flt_epsilon
> end
>
> make (v: like item)
> -- Initialization for `Current'.
> -- Set `item' to `v'.
> do
> epsilon := Flt_epsilon
> item := v
> ensure then
> epsilon_set: epsilon = Flt_epsilon
> end
>
> make_from_integer (v: INTEGER)
> -- Initialization for current object.
> -- Set `item' to `v'.
> do
> item := v.to_real
> epsilon := Flt_epsilon
> ensure
> item_set: item = v.to_real
> end
>
> make_from_real_64 (v: REAL_64)
> -- Initialization for current object.
> -- Set `item' to `v'.
> do
> item := v.truncated_to_real
> epsilon := Flt_epsilon
> ensure
> item_set: item = v.truncated_to_real
> end
>
> make_from_reference (v: REAL_NUMBER_32_REF)
> -- Initialization for current object.
> -- Set `item' to `v.item'.
> do
> item := v.item
> epsilon := v.epsilon
> ensure
> item_set: item = v.item
> epsilon_set: epsilon = v.epsilon
> end
>
> feature -- Access
>
> epsilon: REAL_32 assign set_epsilon
> -- Used for redifinition of `is_equal'.
>
> feature -- Comparison
>
> is_equal (other: like Current): BOOLEAN
> -- Is `other' attached to an object of the same type
> -- as current object and identical to it?
> do
> Result := (item - other.item).abs <= epsilon
> end
>
> feature -- Element change
>
> set_epsilon (v: like epsilon)
> -- Set `epsilon' to `v'.
> do
> epsilon := v
> ensure
> epsilon_set: epsilon = v
> end
>
> feature -- Conversion
>
> to_real_64: REAL_64
> -- Convert current object to a REAL_64.
> do
> Result := item.to_double
> ensure
> good_result: Result = item.to_double
> end
>
> feature {NONE} -- Externals
>
> Flt_epsilon: REAL_32
> --
> --
> external
> "C inline use <float.h>"
> alias
> "[
> return FLT_EPSILON;
> ]"
> end
>
> invariant
> epsilon_large_enough: epsilon >= Flt_epsilon
>
> end
>
> expanded class
> REAL_NUMBER_32
>
> inherit
> REAL_NUMBER_32_REF
>
> create
> default_create,
> make,
> make_from_integer,
> make_from_real_64,
> make_from_reference
>
> convert
> make ({REAL_32}),
> make_from_integer ({INTEGER}),
> make_from_real_64 ({REAL_64}),
> make_from_reference ({REAL_NUMBER_32_REF}),
> to_real_32: {REAL_32},
> to_real_64: {REAL_64}
>
> end
>
> In my test code I have this declaration "a: REAL_NUMBER_32" and what
> follows
> is part of my test code:
>
> make
> -- Run application.
> do
> a := 1.2
> print ("a.epsilon = "); print (a.epsilon); cr
> end
>
> Now, if I run the code as seen above the output is "a.epsilon = 0" and if
> I
> comment out the line "a := 1.2" the output is "a.epsilon = 1.19209e-007".
> Both `default_create' and `make_from_real_64' and all the other
> initialization procedures set `epsilon' so I can't see how `a' can ever be
> created with `epsilon set to 0. Sorry for showing this much code but I am
> stumped and thought that reducing it might cause me to not include
> something
> important. Any help truely appreciated.
>
> Regards
> Chris Saunders
>


 

Jimmy Johnson

Re: Probably a dumb mistake, but I just can't see it

Reply Threaded More More options
Print post
Permalink
In reply to this post by Chris Saunders-4
Chris,

Disclaimer first:  I'm not totally up to speed on the new attached by default behavior and do not write expanded types very often, but...

I think the line
  a := 1.2
gets expanded to
  a := create {REAL_NUMBER_32}.make_from_real_64 (1.2)

This calls default create from REAL_NUMBER_32, then applies the conversion feature `make_from_real_64'.  (I don't know why the compiler saw the "1.2" as a REAL_64, even on my 32-bit machine.  That is a question for Manu.)

Because `a' is an expanded type the assignment uses copy symantics which calls your redefined `copy' feature from ALGEBRAIC_REAL_NUMBER.  That feature cannot copy the `epsilon' attribute as `epsilon' shows up in the descendants.

Hope that helps.

Jimmy J. Johnson

Chris Saunders-4

Re: Re: Probably a dumb mistake, but I just can't see it

Reply Threaded More More options
Print post
Permalink
Ha, I know it was something dumb on my part.  I was looking at the code too
long and thought that I had redefined `copy' in REAL_NUMBER_32_REF.
Sometimes looking too long at code blinds me of the obvious.  I very much
appreciate your help Jim.  By the way, "1.2" or similar will always be
interpreted as a REAL_64 I believe.  Thanks again!

Regards
Chris Saunders

----- Original Message -----
From: boxer41a
To: [hidden email]
Sent: Thursday, September 03, 2009 2:57 AM
Subject: [eiffel_software] Re: Probably a dumb mistake, but I just can't see
it


  Chris,

Disclaimer first: I'm not totally up to speed on the new attached by default
behavior and do not write expanded types very often, but...

I think the line
a := 1.2
gets expanded to
a := create {REAL_NUMBER_32}.make_from_real_64 (1.2)

This calls default create from REAL_NUMBER_32, then applies the conversion
feature `make_from_real_64'. (I don't know why the compiler saw the "1.2" as
a REAL_64, even on my 32-bit machine. That is a question for Manu.)

Because `a' is an expanded type the assignment uses copy symantics which
calls your redefined `copy' feature from ALGEBRAIC_REAL_NUMBER. That feature
cannot copy the `epsilon' attribute as `epsilon' shows up in the
descendants.

Hope that helps.

Jimmy J. Johnson


 

Jimmy Johnson

Re: Probably a dumb mistake, but I just can't see it

Reply Threaded More More options
Print post
Permalink
Not dumb at all.  Glad I could help.

jjj


--- In [hidden email], "Chris Saunders" <evas@...> wrote:
>
> Ha, I know it was something dumb on my part.  I was looking at the code too
> long and thought that I had redefined `copy' in REAL_NUMBER_32_REF.