Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #14684

Re: Placing 'zeros' in front of a number ?

Followups directed to: comp.lang.javascript

Show all headers | View raw

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > Any argument with regards to compatibility concerns is not
>> > very useful without explicit constraints.
>> 
>> Yes, it is.  We are talking about a scripting language, where the runtime
>> environment defines the implementation.
> 
> But you haven't defined what the environments in question are.

Irrelevant.  There is a solution that can fail in a conforming 
implementation, and another that cannot.  Which one do you choose?
  
>> > I am of the belief that such concerns are best left to an ES current ->
>> > ES legacy compiler. Many defensive programming techniques
>> > are also better left to this methodology as well.
>> 
>> If you are talking religion instead of logic now, EOD for me.
> 
> Nothing illogical. There are tools that can be leveraged for these
> issues similar to Traceur and Caja.

You are arguing that writing code that can fail is justified because there 
are third-party tools – that may or may not be available, or applicable – to 
convert it to code that cannot fail, when code that cannot fail could be 
very easily written in the first place.  I fail to see the logic in that.

>>  We do know that function calls are rather expensive, don't we?
> 
> We do not since the implementations have not been defined.

That means all possible implementations are included.  Including the worst 
(but conforming of them).  Check your assumptions.

> I do know that current JITs do quite well with inlining functions.

What does that matter when the code can be exposed to a not-so-current 
script engine that is still a sufficiently conforming implementation of 
ECMAScript?

>> So we should avoid them when not necessary and when
>> there is a risk attached to using them, shouldn't we?
> 
> _IF_ they were expensive

They are, it has been shown before.

> AND avoidable,

They are avoidable in this case, I have showed it already.

> then I would agree with reservations.

If you are thinking logical, you will have to agree in this case.

> The reality is they are not in current implementations.

Irrelevant.

> Tail calls also look to be in for ES6, so future implementations
> I do not expect to be slower in general.

Irrelevant.

>> Be wary of basing design decisions solely on benchmark results of today.
>> Especially when you are not certain of the method behind the benchmark.
> 
> Since the current discussion seems to be focused on performance, it
> seems relevant to present a benchmark to give weight to claims.
> 
> Are you not using the same argument against my implementation based on
> benchmark results of yester-year?

No, I am talking about algorithms.

>> It is not only plausible and likely, it is certain that a longer string
>> of characters requires more memory than a shorter string of characters.
> 
> Since most, if not all of the padding implementations return the same
> result, I don't see the point of this argument.

The point of my argument is to show that your argument is fallacious.

> The final string is the same size all around.

True.

> You can't make assumption that the construction of that string will
> consume more memory as the intermediate values can be constructed lazily.

Whatever that means, it is rather obvious that the memory required in each 
recursion will grow arithmetically, if not geometrically.

>> > but if memory was a concern, I find it unlikely that the developer
>> > would be padding a massive string in the first place.
>> Argument from probability.
> 
> Without anything more concrete in the form of explicit requirements,
> probability seems sound.

That is the fallacy.

>> > Even so, I think it is also worth noting that strings are constructed
>> > lazily in more than one current browser.
>> 
>> Name two.
> 
> At least two: IE8 and greater [1] and Fx since at least March of 2011 [2]
> 
> [1]
> [<https://blogs.msdn.com/b/jscript/archive/2008/03/19/insight-into-string-
concatenation-in-jscript.aspx?Redirected=true>
> [2] <https://bugzilla.mozilla.org/show_bug.cgi?id=639979#c2>

Thank you, I will look into it.  Of course, the fact would still be 
irrelevant in this case.
 
>> > It is also well known that tracing JITs do quite well with such code as
>> > it is type stable and easily converted to loop
>> 
>> References?
> 
> I assumed this was relatively well known. From what I have seen the
> current major browsers use similar techniques, so I will refer you to this
> as a starter:
> <http://www.scribd.com/doc/37617913/Mozilla-Tracemonkey-PLDI-09>
> 
> Keyword searching for inlining and type stability for your choice of
> browser yields relevant results.

See above.

>> > Stack overflow probability? I believe the worst offender would
>> > be Safari 3.2 which has a 500 level limit.
>> 
>> There is that word again.  You should like to *know*.  And never limit
>> yourself to *desktop* *browsers*.
> 
> Since neither the original questioner, nor yourself have given any
> requirements it is not possible to know, only to guess based on current
> usage trends.

No, the logical course of action, given unknown runtime environments, is to 
compare the runtime and memory efficiency of the involved algorithms, not 
considering possible optimizations, and considering the detrimental 
possibilities that are known to exist (such as limited stack memory).

>> > So what is the probability that a developer is performing a left pad of
>> > 500 characters for a legacy client?
>> Argument from probability.
> 
> See above.

Yes.

>> > I wouldn't pretend to know without more information.
>> 
>> That's the point.  You never know.  So be slow to take the risk of not
>> working code when it is not necessary.  It is more important to have
>> working code than fast code, because it does not matter that code could
>> be fast when it does not work in the first place, and as you say
>> yourself, with working code internal optimization is still possible.
> 
> The code works as I have intended.

That would mean you have *intended* it to work where you tested it and 
nowhere else.  I do not consider that a responsible approach to software 
development.  It is where jQuery & friends come from.  This path leads to 
the Dark Side.

> Your solution has more potential failing points than mine does.

Name them.


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Placing 'zeros' in front of a number ? "Mel Smith" <med_cutout_syntel@aol.com> - 2012-06-21 18:37 -0600
  Re: Placing 'zeros' in front of a number ? Gene Wirchenko <genew@ocis.net> - 2012-06-21 18:59 -0700
  Re: Placing 'zeros' in front of a number ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-06-21 20:18 -0700
    Re: Placing 'zeros' in front of a number ? "Mel Smith" <med_cutout_syntel@aol.com> - 2012-06-21 22:51 -0600
    Re: Placing 'zeros' in front of a number ? Gregor Kofler <usenet@gregorkofler.com> - 2012-06-22 10:34 +0200
      Re: Placing 'zeros' in front of a number ? Scott Sauyet <scott.sauyet@gmail.com> - 2012-06-22 04:49 -0700
        Re: Placing 'zeros' in front of a number ? "Mel Smith" <med_cutout_syntel@aol.com> - 2012-06-22 08:39 -0600
        Re: Placing 'zeros' in front of a number ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-06-22 13:05 -0700
        Re: Placing 'zeros' in front of a number ? Gene Wirchenko <genew@ocis.net> - 2012-06-22 14:10 -0700
      Re: Placing 'zeros' in front of a number ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-06-22 22:58 +0000
        Re: Placing 'zeros' in front of a number ? Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-06-23 18:47 +0200
          Re: Placing 'zeros' in front of a number ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-06-23 21:44 +0000
            Re: Placing 'zeros' in front of a number ? "Mel Smith" <med_cutout_syntel@aol.com> - 2012-06-23 16:48 -0600
        Re: Placing 'zeros' in front of a number ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-06-23 16:56 -0700
      Re: Placing 'zeros' in front of a number ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-23 19:47 +0200
        Re: Placing 'zeros' in front of a number ? Gregor Kofler <usenet@gregorkofler.com> - 2012-06-23 20:52 +0200
          Re: Placing 'zeros' in front of a number ? Gregor Kofler <usenet@gregorkofler.com> - 2012-06-23 21:01 +0200
        Re: Placing 'zeros' in front of a number ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-06-23 17:05 -0700
          Re: Placing 'zeros' in front of a number ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-24 03:51 +0200
            Re: Placing 'zeros' in front of a number ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-06-25 20:19 -0700
              Re: Placing 'zeros' in front of a number ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-26 09:04 +0200
                Re: Placing 'zeros' in front of a number ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-06-26 08:32 -0700
                Re: Placing 'zeros' in front of a number ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-26 22:12 +0200
                Re: Placing 'zeros' in front of a number ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-06-30 13:41 -0700
              Re: Placing 'zeros' in front of a number ? Dr J R Stockton <reply1226@merlyn.demon.co.uk.not.invalid> - 2012-06-27 19:34 +0100
  Re: Placing 'zeros' in front of a number ? Dr J R Stockton <reply1225@merlyn.demon.co.uk.not.invalid> - 2012-06-23 20:00 +0100

csiph-web