Re: Javascript Best Practices Document v1.0

Matt Kruse wrote:
> Richard Cornford wrote:
>> I unequivocally assert that a general algorithm must consider
>> every possible permutation, or is it not a general algorithm.
>
> Semantic games bore me. Stop playing them.

You certainly don't seem to like being asked to pin down the precise
meaning of the statements you make.

> To me, you are describing an "exhaustive solution".

I would not use the word 'solution' here at all, because in the context
of problem solving I regard a solution as an absolute, and so not
requiring qualification. But we seem to agree that an algorithm that
exhaustively covers every possible permutation is a general algorithm.

> To me, a "general solution" is one which is written so as
> to not be specific to a single situation, but can be applied
> to a number of different situations (but not necessarily all).

And yesterday you were saying :-

| In fact, a "general" solution need only be tested in the
| situations that it claims to cover ...

- suggesting that the characteristic that made an algorithm 'general'
were the qualifications that accompanied it. An assertion that became
self-evidently ludicrous when demonstrated to be applicable to a totally
specific function.

Today you assert that the algorithm becomes 'general' when it applies to
more than one situation. This is a similarly hopeless criteria for
labelling an algorithm general as:-

function getYPosition(elRef){
return elRef.offsetTop;
}

- applies to more than one situation, but is a long way from deserving
the label 'general'.

> You understand what I mean.

I understand a meaning of the sequences of words that you are using.
What I am not seeing is how they can be usefully applied to the practice
of writing computer software. Mostly because the terms that could be
precise are constantly undermined with questionable qualifications.

> If you would like to use different words to describe
> what you know I am talking about, let me know what your
> preferred words are.

I am a linguistic nominalist so I don't really care about the terms
used. You can make-up and use entirely new terms for all I care, the
only impotent consideration is the we both understand how the terms used
relate to the other terms in statements that employ them. If we cannot
share an understanding of how a term is being used we cannot communicate
and use that term at the same time.

Your use of 'solution' is a good example. I may not approve of your
definition but I can understand it, and so I can understand the
statements that you make that employ it. Because you understand that
when I use the term 'solution' I am referring to 'that which negates the
problem as analysed' you can understand my use of the term 'solution'.
And because I understand that when you use the term 'solution' you mean:
'that which may or may not negate the problem as analysed, but sounds
positive regardless', I can understand your sue of 'solution'. So, for
example, when you write "partial solution" I know hat you mean the
category of solutions that do not negate the problem as analysed but
still sound positive.

Those mutual understandings facilitate communication.

What I am asking for here is that you explain what it is that you mean
when you use the term 'general' (which seems quite significant when you
assert that you are seeking general solutions/algorithms).

But lets not get hung up on the term 'general' as such. Instead lets
ditch the loaded term and substitute the arbitrary term 'x', and analyse
the relationship between x and algorithms more abstractly:-

The a-priory assumption is: -

1. x is a quality that an algorithm may or may not have.

And the axiomatic 'truths' are:-

1. An algorithm that is totally specific to a single context
and task does not exhaustively cover all possible
permutations (and the inverse).

2. An algorithm that exhaustively covers all possible
permutations has the quality x.

3. An algorithm that is totally specific to a single context
and task does not have the quality x.

Unfortunately the statements are not enough to deduce a definition of x.
To that end another statement needs to be added, and given that x
appears to relate to specificity-exhaustiveness we can expect this
statement to be couched in those terms.

One obvious candidate is that; 'An algorithm has the quality x if it is
not totally specific to a single context and task'. The second and third
statements above can be deduced from this assumption and the remaining
one and so they can then be removed. And the new assumption becomes the
definition of x.

The other obvious candidate is that; 'An algorithm does not have the
quaintly x if it does not exhaustively cover all possible permutations'.
Again the second and third statements can be deduced from this
assumption and the remaining one. And this assumption becomes the
definition of x.

The remaining, and unavoidable, possibility is that an algorithm's
possession of the quality x relates to something other. That a fourth
statement needs to be added defining a relationship between
specificity-exhaustiveness and x, or fourth and fifth statements, one
relating x to something else and the other relating that something else
back to specificity-exhaustiveness. This (these) addition(s) (if
satisfactory) should again allow statements 2 and 3 to be deduced.
Possibly, but not necessarily, when combined with the first.

So, any statement (or consistent sequence of statements) that,
independently of, or when combined with, the first statement made above,
allows the second and third statements above to be deduced is a
satisfactory definition of x.

Relating this back to the applicability of the term 'general'. Today you
have gone for; "To me, a "general solution" is one which is written so
as to not be specific to a single situation, but can be applied to a
number of different situations (but not necessarily all)". Thus 'all
algorithms are general if they are not totally specific to a single
context/task'. I don't like that definition because it is the most
inclusive definition possible, and leaves the term 'general' meaning
very little. But if that is the meaning you would like attached when you
use the term 'general' then that is fine. Say so and we can have an end
of it. Though don't be too surprised if you are taken at your word.

As I have said, I prefer the most exclusive definition; 'all algorithms
are not general if they do not exhaustively cover all possible
permutations'.

On the other hand I am happy to entertain any other definitions of
'general' that prescribes a cut-off somewhere in the spectrum between
the totally specific and the exhaustive. The important thing is to be
able to look at any algorithm and ask 'does this algorithm qualify for
the label "general" by the definition of general being used?' with the
expectation of being able to answer 'yes' or 'no'.

> Then maybe you can stop arguing about words and
> start discuss the concepts behind them.

Put the concept behind being 'general' into words that say something
about the subjects to which you want to apply the label and maybe the
concept can be discussed.

>>> When the browser lays out the page, it calculates the
>>> offsets for the element, given its position and display
>>> type.
>> And when a browser calculates an offset where is it an
>> offset from?
>
> Depends on the browser, of course. And the page contents.

And the CSS suggestions applying to the elements and their ancestors (as
defaulted or assigned).

>>> See my test page at:
>>> http://www.mattkruse.com/javascript/ObjectPositionTest.php
>>> It covers some of your conditions,
>> My conditions?
>
> Yes, the long list of things that you said could be applied
> to a given page to make a general position-finding function
> impossible.

If you go back and read what I actually said you will find that I was
listing some of the factors that have to be taken into account in order
to make the general (by my preferred definition of the term) position
finding algorithm possible.

> Things like adding borders, margins, etc. My example page
> has test cases for some of those things, and no extra
> consideration was needed to handle them correctly.

That is right, keep looking at test cases where the code works and
patting yourself on the back for their success. After all, you had your
general (by your apparently preferred definition) position finding
algorithm even before you realised a need to take scrollable elements
into account.

>> I saved your HTML locally, added one style attribute,
>> setting one CSS property, to one element on the page
>> and suddenly your little marker is half a page away
>> from where it was supposed to be.
>
> What exactly was it that you changed?

I changed the value of one applicable CSS property on one element. You
will only find out where your code breaks by trying to break it.

> Oh, wait, let me guess... "I'm not going to tell you,
> because you don't deserve my help." Right?

Why do you act offended when I won't help you? All else being equal, am
I likely to go out of my way to help someone who insults me?

> Making empty claims is rather dubious.

And disregarding warnings without testing is rather dangerous.

>> Frankly, I am already using components that I would never
>> dream of describing as "general" that already handle more
>> possible (and actually likely) permutations that your code
>> would.
>
> Even if you do have such components, they're useless to anyone
> but yourself,

And my employers.

> since you refuse to share your work with the world.

You are not the world.

> You just brag about it. How nice of you.

You won't goad me into sharing anything with you but the warnings I have
already given you. You don't seem to appreciate it but the reason that
you are interested in knowing the algorithms that I use for this task is
that I have already trodden the path that your have barley started
along.

You think my code might help you along that path, it won't. I came to
the point of being able to see that the path was a dead end, turned back
and took an alternative route. The code I use now deliberately
side-steps the issues inherent in the general position/dimension finding
problem, and in doing so it delivers results. But those issues cannot be
side-stepped on the rout you have chosen.


> I have a time machine, you know.
<snip>

Excellent, problem solved then. All you have to do is go forward in time
to just after you publish the totally exhaustive general
position/dimension finding code, make a note of it, return home and
publish it. Then the only remaining question is whether I was right and
the result is too big and slow to be viable in any but the least
demanding circumstances.

Richard.



.

Relevant Pages

  • Re: Strategy or Iterator?
    ... private int count; ... Dijkstra's algorithm generates permutations, ... All possible subsequences of length N of the input (considered to be ...
    (comp.lang.java.programmer)
  • Re: Help with Permutations
    ... >>>In order to keep track of the progress through the algorithm, ... >>>be able to calculate the total number of permutations in advance. ... >> gives 1265, as quasi reported. ... either Maple has a bug or there's a bug in my program. ...
    (sci.math)
  • Re: Permuatations [was: Please Help!!Daughter...]
    ... mathematical purity of exchanging elements. ... ", and then unifies them into a framework based on exchanges), ... It isn't that I don't know how to generate permutations. ... generate-and-discard algorithm with a bit of early pruning). ...
    (comp.lang.java.programmer)
  • Re: Help with Permutations
    ... >>>In order to keep track of the progress through the algorithm, ... >>>be able to calculate the total number of permutations in advance. ... >> Derek Holt. ... >is inside the sum or outside but not 1265. ...
    (sci.math)
  • Re: free tool to encrypt php?
    ... That way - I have a unique password for every site and never have to write down a password ever. ... All I gotta do is remember ONE password, and the algorithm. ... They crack your algorithm, ... First you deduce things from write data that are incorrect, secondly you assert as fact that which you cannot know. ...
    (comp.lang.php)