Clarity vs. code reuse/generality

[Aahz]

sense = cmp(func(hi), func(lo))
assert sense != 0, "func is not strictly monotonic in [lo, hi]"

As already said before, unlike other languages, sense in english does
**not** mean direction. You should rewrite this part using a better
name. Wrong informations are far worse than no information at all.

Absolutely.

From Webster's Dictionary:

8. (Geom.) One of two opposite directions in which a line,
surface, or volume, may be supposed to be described by the
motion of a point, line, or surface.
[1913 Webster]


And from WordNet:

2: the meaning of a word or expression; the way in which a word
or expression or situation can be interpreted

Both meanings are relevant to the way KJ is using the word. Please take
your own advice and stop giving wrong information. As a native English
speaker, I had no difficulty understanding the meaning of "sense" in the
sense intended by KJ.

As another native English speaker, I agree with Jean-Michel; this is the
first time I've seen "sense" used to mean direction.

 

[Steven D'Aprano]

kj wrote:

sense = cmp(func(hi), func(lo))
assert sense != 0, "func is not strictly monotonic in [lo, hi]"

As already said before, unlike other languages, sense in english does
**not** mean direction. You should rewrite this part using a better
name. Wrong informations are far worse than no information at all.

Absolutely.

From Webster's Dictionary:

8. (Geom.) One of two opposite directions in which a line,
surface, or volume, may be supposed to be described by the motion
of a point, line, or surface.
[1913 Webster]


And from WordNet:

2: the meaning of a word or expression; the way in which a word
or expression or situation can be interpreted

Both meanings are relevant to the way KJ is using the word. Please take
your own advice and stop giving wrong information. As a native English
speaker, I had no difficulty understanding the meaning of "sense" in the
sense intended by KJ.

As another native English speaker, I agree with Jean-Michel; this is the
first time I've seen "sense" used to mean direction.

Just goes to show you learn something new all the time.

http://www.merriam-webster.com/dictionary/sense

7: one of two opposite directions especially of motion (as
of a point, line, or surface)


http://dictionary.reference.com/browse/sense

18. Mathematics. one of two opposite directions in which
a vector may point.



Paraphrasing the Collins Dictionary of Mathematics:

The sense of a vector is the sign of the measure, contrasted with the
magnitude. Thus the vectors AB and BA have the same direction but
opposite sense. Sense is also used to distinguish clockwise and anti-
clockwise.

Sense is, if you like, a "signed direction". "Towards north" (say) as
opposed to "along the north-south axis".

 

[Lie Ryan]

kj wrote:
sense = cmp(func(hi), func(lo))
assert sense != 0, "func is not strictly monotonic in [lo, hi]"
As already said before, unlike other languages, sense in english does
**not** mean direction. You should rewrite this part using a better
name. Wrong informations are far worse than no information at all.

Absolutely.

From Webster's Dictionary:
8. (Geom.) One of two opposite directions in which a line,
surface, or volume, may be supposed to be described by the
motion of a point, line, or surface.
[1913 Webster]


And from WordNet:

2: the meaning of a word or expression; the way in which a word
or expression or situation can be interpreted

Both meanings are relevant to the way KJ is using the word. Please take
your own advice and stop giving wrong information. As a native English
speaker, I had no difficulty understanding the meaning of "sense" in the
sense intended by KJ.

As another native English speaker, I agree with Jean-Michel; this is the
first time I've seen "sense" used to mean direction.

When people are fighting over things like `sense`, although sense may
not be strictly wrong dictionary-wise, it smells of something burning...

 

[Steven D'Aprano]

When people are fighting over things like `sense`, although sense may
not be strictly wrong dictionary-wise, it smells of something burning...

That would be my patience.

I can't believe the direction this discussion has taken. Anybody sensible
would be saying "Oh wow, I've just learned a new meaning to the word,
that's great, I'm now less ignorant than I was a minute ago". But oh no,
we mustn't use a standard meaning to a word, heaven forbid we disturb
people's ignorance by teaching them something new.

It's as simple as this: using `sense` as a variable name to record the
sense of a function is not a code smell, any more than using `flag` to
record a flag would be, or `sign` to record the sign of an object. If you
don't know the appropriate meanings of the words sense, flag or sign,
learn them, don't dumb down my language.

 

[Asun Friere]

On Jul 7, 3:05 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:

[snip]

Sense is, if you like, a "signed direction".

Or to put it another way, in the graphical representation of a vector,
'direction' is the line, 'sense' is the arrowhead.

 

[Lie Ryan]

That would be my patience.

I can't believe the direction this discussion has taken.

Me neither.

Anybody sensible
would be saying "Oh wow, I've just learned a new meaning to the word,
that's great, I'm now less ignorant than I was a minute ago". But oh no,
we mustn't use a standard meaning to a word, heaven forbid we disturb
people's ignorance by teaching them something new.

A meaning of a word is meaningless if nobody apart the writer
understands it. The purpose of code is 1) to communicate with the
computer, 2) to communicate with fellow programmer. The second point is
especially important if the code are written for pedantic purpose.
Teaching is largely one-way communication and often students that does
not understand about a slight point could not or would not communicate
their feelings because they think it is too silly. If the use of word is
criticized on a two-way communication channel (e.g. newsgroup), it
should raise a question of whether the word should be described first or
whether a synonym would be more suitable for the purpose. Most of these
do not apply on practical, non-pedantic purpose though, since in
non-pedantic settings you are expected to know and use the jargons
however (in)sensible they may be at first sight.

It's as simple as this: using `sense` as a variable name to record the
sense of a function is not a code smell, any more than using `flag` to
record a flag would be, or `sign` to record the sign of an object.

Nobody said code smell... linguistic smell is more appropriate.

 

[Jean-Michel Pichavant]

That would be my patience.

I can't believe the direction this discussion has taken. Anybody sensible
would be saying "Oh wow, I've just learned a new meaning to the word,
that's great, I'm now less ignorant than I was a minute ago". But oh no,
we mustn't use a standard meaning to a word, heaven forbid we disturb
people's ignorance by teaching them something new.

It's as simple as this: using `sense` as a variable name to record the
sense of a function is not a code smell, any more than using `flag` to
record a flag would be, or `sign` to record the sign of an object. If you
don't know the appropriate meanings of the words sense, flag or sign,
learn them, don't dumb down my language.

Can't we just calm down ? I'm really sorry my ignorance started this
thread, and my apologies go to Kj who's obviously more fluent in english
than me.
I've never used sense in that way before, nor I've seen used by others
until now. However Kj is right, and my dictionary seems wrong
(wordreference.com). I've searched through others dictionaries and find
out this is actually applicable to functions. My bad.

JM

 

[Aahz]

Can't we just calm down ? I'm really sorry my ignorance started this
thread, and my apologies go to Kj who's obviously more fluent in english
than me.
I've never used sense in that way before, nor I've seen used by others
until now. However Kj is right, and my dictionary seems wrong
(wordreference.com). I've searched through others dictionaries and find
out this is actually applicable to functions. My bad.

You were not the first person to point out that "sense" is a poor
variable name. Unless KJ is specifically using this code in the context
of a math class, I still think that "sense" is completely inappropriate.
Your English fluency is just fine.

 

[Simon Forman]

Can't we just calm down ? I'm really sorry my ignorance started this thread,
and my apologies go to Kj who's obviously more fluent in english than me.
I've never used sense in that way before, nor I've seen used by others until
now. However Kj is right, and my dictionary seems wrong (wordreference.com).
I've searched through others dictionaries and find out this is actually
applicable to functions. My bad.

JM

Well met, sir.

 

[pdpi]

LOL.

Maybe the reason for "so much buggy software" is that people
inappropriately use assert, thus changing the behaviour of code depending
on whether it is run with the -O flag or not.

I don't know what "hostility" you're seeing. The only hostility I'm
seeing is from the OP, which is bizarre considering that he asked for
advice and we gave it. What I see is a bunch of people concerned that the
OP is teaching novices a bad habit, namely, using assert for error
checking. He claims -- angrily and over and over again -- that in his
code, the assertions should never fail. Great. Good for him for knowing
when to use assert. (...)

But he doesn't.

He asserts:
assert lo < hi
but then compares:
sense = cmp(func(hi), func(lo))

sense can't ever be anything other than 1. I actually find it amusing
that this threat got to 50 posts of raving discussion about assertions
without anyone spotting that.

Personally, I think the code is an unreadable mess, but that's mostly
because of all the micro optimizations, not the generality of it.
Here's my unoptimized, but still equally generic, version:

def _binary_search(lo, hi, func, target, epsilon):
sense = cmp(func(hi), func(lo))
if sense == 0:
return None
guess = (lo + hi) / 2.
while abs(func(guess) - target) > epsilon:
guess = (lo + hi) / 2.
if func(guess) > target:
hi = guess
elif func(guess) < target:
lo = guess
elif lo == hi:
return None
return guess

This is a newbie course, right? A while True loop might be faster, but
it's all sorts of wrong for teaching newbies. Likewise, calculating a
midpoint as mid = (hi + lo) * .5 is an aberration in a beginner
environment. You want your students asking why you're calculating an
average, not asking why you're multiplying by 0.5. In the same vein, I
have no words for your target_plus/target_minus cleverness.

The right way to go about it, IMO, is to give them my version, let
them digest it, make all the necessary changes to it to turn it into
your (faster) version. Present benchmarks for both, then let the
readability/performance trade-off sink in. What you achieve with this
exercise is that, instead of making your students think "I have to
read that crud!?", they'll respect that ugly code is often the result
of eking out every last drop of performance from a program as you
possibly can.

 

[Paul Rubin]

Personally, I think the code is an unreadable mess, but that's mostly
because of all the micro optimizations, not the generality of it.
Here's my unoptimized, but still equally generic, version:

That version doesn't use "sense" inside the binary search, i.e. it
relies on the function being monotonically increasing.

 

[Andre Engels]

He asserts:
   assert lo < hi
but then compares:
   sense = cmp(func(hi), func(lo))

sense can't ever be anything other than 1.

It can - there is no necessity that func is monotonically increasing.

 

[pdpi]

It can - there is no necessity that func is monotonically increasing.

Yes, I realized that as I was walking home.

In other news, some of you may be interested in my seminar in advanced
foot-in-mouth placement.

 

[pdpi]

That version doesn't use "sense" inside the binary search, i.e. it
relies on the function being monotonically increasing.

You're right, make that:

def _binary_search(lo, hi, func, target, epsilon):
sense = cmp(func(hi), func(lo))
if sense == 0:
return None
guess = (lo + hi) / 2.
while abs(func(guess) - target) > epsilon:
guess = (lo + hi) / 2.
if sense * func(guess) > target:
hi = guess
elif sense * func(guess) < target:
lo = guess
elif lo == hi:
return None
return guess

Seems I had a serious brain cramp while posting that...

 

[pdpi]

You're right, make that:

def _binary_search(lo, hi, func, target, epsilon):
    sense = cmp(func(hi), func(lo))
    if sense == 0:
        return None
    guess = (lo + hi) / 2.
    while abs(func(guess) - target) > epsilon:
        guess = (lo + hi) / 2.
        if sense * func(guess) > target:
            hi = guess
        elif sense * func(guess) < target:
            lo = guess
        elif lo == hi:
            return None
    return guess

Seems I had a serious brain cramp while posting that...

Actually, scratch that.

def _binary_search(lo, hi, func, target, epsilon):
sense = cmp(func(hi), func(lo))
if sense == 0:
return None
guess = (lo + hi) / 2.
while abs(func(guess) - target) > epsilon:
guess = (lo + hi) / 2.
if sense * func(guess) > sense * target:
hi = guess
elif sense * func(guess) < sense * target:
lo = guess
elif lo == hi:
return None
return guess

 

[Dave Angel]

But he doesn't.

He asserts:
assert lo < hi
but then compares:
sense =mp(func(hi), func(lo))

sense can't ever be anything other than 1. I actually find it amusing
that this threat got to 50 posts of raving discussion about assertions
without anyone spotting that.

That's because the assert and the comparison are unrelated to each
other. If the function is monotonically decreasing, then by definition
lo<hi would guarantee that func(lo)>= func(hi), which would yield a
sense of 0 or -1.

Trivial example of monotonically decreasing:
def func(inp):
return 53.0 - inp

Personally, I think the code is an unreadable mess, but that's mostly
because of all the micro optimizations, not the generality of it.
Here's my unoptimized, but still equally generic, version:

def _binary_search(lo, hi, func, target, epsilon):
sense =mp(func(hi), func(lo))
if sense =0:
return None
guess =lo + hi) / 2.
while abs(func(guess) - target) > epsilon:
guess =lo + hi) / 2.
if func(guess) > target:
hi =uess
elif func(guess) < target:
lo =uess
elif lo =hi:
return None
return guess

And of course your clarified function will fail if the func is
monotonically decreasing.

I still think that rather than using sense in the loop, one should
simply swap lo and hi, and continue.

This is a newbie course, right? A while True loop might be faster, but
it's all sorts of wrong for teaching newbies. Likewise, calculating a
midpoint as mid =hi + lo) * .5 is an aberration in a beginner
environment. You want your students asking why you're calculating an
average, not asking why you're multiplying by 0.5. In the same vein, I
have no words for your target_plus/target_minus cleverness.

The right way to go about it, IMO, is to give them my version, let
them digest it, make all the necessary changes to it to turn it into
your (faster) version. Present benchmarks for both, then let the
readability/performance trade-off sink in. What you achieve with this
exercise is that, instead of making your students think "I have to
read that crud!?", they'll respect that ugly code is often the result
of eking out every last drop of performance from a program as you
possibly can.

(untested)

def _binary_search(lo, hi, func, target, epsilon):
""" lo, hi are floats representing the desired range of input values to func()
func() is a function that takes a float argument, and returns a float result
target is the desired result value of func()
epsilon is the allowable error compared to target. If set too small, this function will fail by returning None
precondition: func is monotonic over the range of floating point inputs from lo to hi """
return a float value between lo and hi (inclusive) which yields approximately target
if func(lo) > func(hi):
lo, hi = hi, lo
if not (func(lo) <= target <= func(hi)):
return None #function doesn't have target value within the input range
guess = lo
while abs(func(guess) - target) > epsilon:
guess = (lo + hi) / 2.
if func(guess) > target:
hi = guess
elif func(guess) < target:
lo = guess
elif lo == hi:
return None #function is too steep to have a value within epsilon
return guess

The reason for the "too steep" condition is that with a finite
resolution for 'guess' epsilon could be enough smaller than target as
to make a result impossible. For example, if the slope is 45 degrees,
this happens when epsilon is about 2**51 smaller.

 

[pdpi]

And of course your clarified function will fail if the func is
monotonically decreasing.

yeah, I eventually realized that and corrected it... And the assert()/
cmp() confusion too. I blame lack of sleep.

The whole sign/sense thing left a really bad taste in my mouth,
though, and the swapping lo and hi suggestion of yours seems like the
neatest solution presented.

 

[Paul Rubin]

while abs(func(guess) - target) > epsilon:
guess = (lo + hi) / 2.
if sense * func(guess) > sense * target:
hi = guess
elif sense * func(guess) < sense * target:
lo = guess
elif lo == hi:
return None
return guess

That is completely confusing. I get the, er, impression that "sense"
is supposed to change during the loop, and it takes much head
scratching to tell whether what you have there is right or not. Also,
it calls func 3 times on each loop, which could be extremely slow.
You don't know what func does, so eliminating 2/3 of the calls to it
is not a micro-optimization--it could be a major time saving.

Yet another version:

def _binary_search(x0, x1, func, target, epsilon):
y0,y1 = func(x0), func(x1)
while abs(y1 - target) > epsilon:
if x0 == x1 or cmp(y0,target) == cmp(y1,target):
return None
xn = (x0 + x1) / 2.
yn = func(xn)
if cmp(yn,target) == cmp(y0,target):
x0,y0 = xn,yn
else:
x1,y1 = xn,yn
return x1

 

[Gabriel Genellina]

En Tue, 07 Jul 2009 09:51:10 -0300, Jean-Michel Pichavant

I've never used sense in that way before, nor I've seen used by others
until now. However Kj is right, and my dictionary seems wrong
(wordreference.com). I've searched through others dictionaries and find
out this is actually applicable to functions. My bad.

Using a common word with its common meaning is important too in order to
understand the code. It's hard enough for students to grasp the algorithm
itself, why make it artificially harder by using strange variable names.

Some years ago I had to endure using an in-house framework with names like
bring_XXX and fix_XXX instead of the usual names get_XXX and set_XXX (that
was C++, emulating properties; I'm not sure of the actual verbs used,
perhaps "obtain" and "establish", but certainly not get/set/put). Add some
undecipherable comments in spanglish, profuse usage of macros that alter
the lexical appearance of the language, and even reading code was a
torture.

 

[Dennis Lee Bieber]

Paraphrasing the Collins Dictionary of Mathematics:

opposite sense. Sense is also used to distinguish clockwise and anti-
clockwise.

Which, I believe, is the only usage I've encountered of it... In
regards to quantum spin states in such things as Scientific American
(though that magazine has either gone down hill in the last 30 years, or
my expectations have gone up... Current issues read like the first years
of Discover magazine)

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/