Re: [Liberty-eiffel] bug #44278

[Laurie Moye]

Hi everybody,

Concerning the implementation of ARRAY.slice (et. al.), I would like to
make a very general comment about library functions. Library functions
are there for convenience: they enable me to get something going easily
and quickly. To do this, their implementation has to allow their use to
be as simple and intuitive as possible. If I am writing time/space
critical code, I will always be wary of using library functions, and
will be ready to implement the function in my own code if that is more
efficient.

To take ARRAY.slice as an example. Let us say that I am processing image
data stored in a 2-D array and I want to filter it with a
finite-impulse-response filter. I have to apply the filter to sub-arrays
of the image for every position in the image. To get the code working, I
might use slice for convenience and get a very slow implementaiton which
copies out every sub-array, but for the final application I would expect
to rewrite my code to access the data directly from the original array.
The computation of array indices in the fast version might look rather
complicated, but I would be assured that I had got it right if it gives
the same results as the more readable slow code using slice.

I would say that ARRAY.slice should certainly return "like Current". I
don't want to lose all the other attributes when I take the slice. Also,
I would favour the implementation using twin as that give me the most
intuitive ease of use.

As a general rule, for library functions, ease of use should always come
first except where a speedy implementation cannot be achieved easily by
the user because it needs access to internals that the user doesn't want
to know about. In the latter case, it is reasonable to impose on the
user whatever restrictions the fast implementaton demands, but it might
be best to provide both "thing" and "fast_thing" implementations (some
of which we already have).

I would be most interested to know what other users think about this. I
am an engineer, and use Eiffel for signal-processing applications. One
charactersitic of this is the processing of huge amounts of data.
Perhaps this gives me a point of view not shared by other users!

Best wishes,
          Laurie