On 1/5/2014 9:23 AM, wxjmfa...@gmail.com wrote:
Le samedi 4 janvier 2014 23:46:49 UTC+1, Terry Reedy a écrit :
On 1/4/2014 2:10 PM, wxjmfa...@gmail.com wrote:
And I could add, I *never* saw once one soul, who is
explaining what I'm doing wrong in the gazillion
of examples I gave on this list.
If this is true, it is because you have ignored and not read my
numerous, relatively polite posts. To repeat very briefly:
1. Cherry picking (presenting the most extreme case as representative).
2. Calling space saving a problem (repeatedly).
>> 3. Ignoring bug fixes.
...
My examples are ONLY ILLUSTRATING, this FSR
is wrong by design, can be on the side of
memory, performance, linguistic or even
typography.
Let me expand on 3 of my points. First, performance == time:
Point 3. You correctly identified a time regression in finding a
character in a string. I saw that the slowdown was *not* inherent in the
FSR but had to be a glitch in the code, and reported it on pydev with
the hope that someone would fix it even if it were not too important in
real use cases. Someone did.
Point 1. You incorrectly generalized that extreme case. I reported (a
year ago last September) that the overall stringbench results were about
the same. I also pointed out that there is an equally non-representative
extreme case in the opposite direction, and that it would equally be
wrong of me to use that to claim that FSR is faster. (It turns out that
this FSR speed advantage *is* inherent in the design.)
Memory: Point 2. A *design goal* of FSR was to save memory relative to
UTF-32, which is what you apparently prefer. Your examples show that FSF
successfully met its design goal. But you call that success, saving
memory, 'wrong'. On what basis?
You *claim* the FSR is 'wrong by design', but your examples only show
that is was temporarily wrong in implementation as far as speed and
correct by design as far as memory goes.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
