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

Groups > comp.lang.javascript > #14608 > unrolled thread

Placing 'zeros' in front of a number ?

Back to article view | Back to comp.lang.javascript

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#14665

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> Having reviewed these two solutions (see below), I still prefer
>> >> mine...
>> > 
>> > I would have preferred my second solution mentioned to be evaluated,
>> > which was added to the jsperf website:
>> 
>> The disadvantage of Google Groups postings to the interested poster is
>> that I do not see them (which is an advantage to me in most other cases),
>> except when they are followups to my postings and the poster was not
>> killfiled. Since I am not alone in this, I strongly suggest you switch to
>> a more responsible Usenet access provider.
>>  
>> > function padLeft(str, ch, len){
>> >     return str.length >= len ? str : padLeft(ch + str, ch, len);
>> > }
>> 
>> I do not think this recursive solution is very efficient or compatible
>> either.  Instead of a fixed number of 2 function calls, there are now
>> len - str function calls.  And the greater the difference between
>> original string length and desired string length, the more likely a stack
>> overflow.
> 
> 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.

> Even if they were presented, they would be debateable anyway.

Of that I am sure.  It would not end up to be a overly logical debate, 
though.

> 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.
 
> Your efficiency argument is valid in part. I could make an
> argument in reference to brevity and network traffic,

I was referring to the potentially increased number of function calls 
necessary to compute the result.  We do know that function calls are rather 
expensive, don't we?  So we should avoid them when not necessary and when 
there is a risk attached to using them, shouldn't we?

> […]
> I doubt you were refering to anything beyond time/space
> with the efficiency criticism.

Correct.

> IRT speed, JSPerf demonstrates that this is not an issue in
> relationto the other approaches presented there.

Be wary of basing design decisions solely on benchmark results of today.  
Especially when you are not certain of the method behind the benchmark.
 
> IRT to memory, it is indeed plausible (however unlikely)
> that a string which needs to be padded to a significant
> length could consume more memory than is desirable

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.

> 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.

> Even so, I think it is also worth noting that strings are constructed
> lazily in more than one current browser.

Name two.

> 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?

> (which is probably what is demonstrated on the test page)

Maybe.  Maybe not.

> 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*.

> So what is the probability that a developer is performing a left pad of
> 500 characters for a legacy client?

Argument from probability.

> 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.


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#14667

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.
 
> > Even if they were presented, they would be debateable anyway.
> 
> Of that I am sure.  It would not end up to be a overly logical debate, 
> though.
> 
> > 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.

>  We do know that function calls are rather expensive, don't we?

We do not since the implementations have not been defined. I 
do know that current JITs do quite well with inlining functions.

> 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 AND avoidable, then I would agree with
reservations. The reality is they are not in current implementations.
Tail calls also look to be in for ES6, so future implementations
I do not expect to be slower in general.

> 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? 
 
> 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 final string is the same size all around. You can't make assumption that the construction of that string will consume more memory as the intermediate values can be constructed lazily.
 
> > 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.


> > 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>

> > 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.

> > 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.

> > 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.

> > 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. Your solution has more potential failing points than mine does.

[toc] | [prev] | [next] | [standalone]

#14684

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>

[toc] | [prev] | [next] | [standalone]

#14786

Michael Haufe (TNO) wrote:
> But you haven't defined what the environments in question are.

Thomas 'PointedEars' Lahn wrote:
> Irrelevant.  There is a solution that can fail in a conforming
> implementation, and another that cannot.  Which one do you choose?

The problem is that you have an open world assumption. As such, it
cannot be known if the implementation is conforming or not. What I
choose is to write clear and concise code targeting a known set of
platforms either directly or indirectly. Do I succeed in such
endeavors? Usually, but even when I do not, I can do something about
it as I would know what platform the code is running on.

If you are implying that your code will NOT fail in a conforming
implementation, you're wrong. For example: plug in Number.MAX_VALUE
(or another value sufficiently large) in both of our implementations
and you will see mine throw an exception rather quickly, whereas
yours will continue to consume memory until it has most likely eaten
it all and starts swapping to disk. Maybe it would eventually return
an answer, but I was not willing to wait and find out. My hardware
is too delicate for such a test. Regardless, I'm certain this is
not intended behavior.

Thomas 'PointedEars' Lahn wrote:
> 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.

Writing code that can fail when it was advertised to succeed is not
justified. I don't make the claim or assumption that a given solution
is going to work in all possible implementations. Since the original
questioner did not specify what implementations he expected a solution
to run on, anything provided would need to have one or more caveats
attached. As such, a minimal, concise implementation seems quite
sufficient. Issues of backwards/sideways compatibility are best
managed elsewhere. You may enjoy playing the role of compiler, but I
do
not. Also, "...very easily written..." is a subjective claim.

Thomas 'PointedEars' Lahn wrote:
> We do know that function calls are rather expensive, don't we?

Michael Haufe (TNO) wrote:
> We do not since the implementations have not been defined.

Thomas 'PointedEars' Lahn wrote:
> That means all possible implementations are included.  Including the worst
> (but conforming of them).  Check your assumptions.

There is no reason to assume a conforming implementation.

[snipping some related arguments]

Michael Haufe (TNO) wrote:
> 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.

Thomas 'PointedEars' Lahn wrote:
> 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).

If you don't know what the runtime environment is, you can't come to a
conclusion about the runtime efficiency of said algorithms.

Michael Haufe (TNO) wrote:
> The code works as I have intended.

Thomas 'PointedEars' Lahn wrote:
> That would mean you have *intended* it to work where you tested it and
> nowhere else.

This is our primary difference, and you are correct. If the code works
in a place I never intended, then I would consider that a bonus. If
it does not work in an environment it was not intended for, then
I won't lose sleep over it.

Thomas 'PointedEars' Lahn wrote:
> I do not consider that a responsible approach to software
> development.

I do, as I can provide a set of guarantees given a set of
environments.

Thomas 'PointedEars' Lahn wrote:
> It is where jQuery & friends come from.  This path leads to
> the Dark Side.

I don't want to wander too far off into a separate argument on this
particular point, but I claim there is are key differences here.
Primarily that jQuery & friends tend to make false claims to their
supported platforms, and to the behavior of a given set of functions
and methods (I'm sure that specific examples of these don't need
to be given by me as David Mark has done plenty of legwork here.)

Michael Haufe (TNO) wrote:
> Your solution has more potential failing points than mine does.

Thomas 'PointedEars' Lahn wrote:
> Name them.

Since you have an open world assumption, I could not name them all.
Just
a cursory glance reveals that you would have to contend with numerous
potentially
overwritten methods/constructors (assuming the originals worked
correctly in
the first place anyway). Not limited to toString(), valueOf(),
constructor, String,
the existence of array literals, correct behavior of join, and
pow()...

Context is king, and if you don't know the execution context, you are
at its mercy.

[toc] | [prev] | [next] | [standalone]

#14730

In comp.lang.javascript message <ad593911-0b87-4e09-8349-e443390e7d88@go
oglegroups.com>, Mon, 25 Jun 2012 20:19:34, "Michael Haufe (TNO)"
<tno@thenewobjective.com> posted:

>Stack overflow probability? I believe the worst offender would
>be Safari 3.2 which has a 500 level limit. So what is the
>probability that a developer is performing a left pad of 500
>characters for a legacy client? I wouldn't pretend to know
>without more information.

It is easy enough to determine the number of zeroes needed.

A long string of N zeroes can be generated recursively on of the order
of log2(N) operations, using a similar amount of calling stack.
Therefore, one could in Safari 3.2 get a string of about 2^500
characters without exceeding the stack limit.  I think the longest
permissible string, unless extended by ECMA 5, is about 2^32 characters.

Functions BigCat (recursive) and Wombat (iterative) are demonstrated in
 <http://www.merlyn.demon.co.uk/js-misc0.htm#MLS>.  They generate
hundred-million-character strings in about a millisecond on this PC in
FF 13.0.1, and fail (allocation size overflow) at thousand-million.

-- 
 (c) John Stockton, nr London UK  ?@merlyn.demon.co.uk  IE8 FF8 Op11 Sf5 Cr15
   news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
   <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
   <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[toc] | [prev] | [next] | [standalone]

#14634

In comp.lang.javascript message <a4ht2oFf7iU1@mid.individual.net>, Thu,
21 Jun 2012 18:37:43, Mel Smith <med_cutout_syntel@aol.com> posted:

>    I've got a bunch of numbers (in string format), that I want to convert
>to strings of a standard length of four characters:

See  <http://www.merlyn.demon.co.uk/js-round.htm> ff.
It does not answer your present question, but it handles likely future
ones.

It is probable that adding zero characters to the front, one at a time,
while needed, to the desired length is easiest to get right and
sufficiently quick; but the latter depends on the application.

EITHER be certain (and right) that your strings will ALWAYS have 1, 2,
3, or 4 digits; or test and handle other formats appropriately.  For
example, it is probably better to break format than to break value.

Consider <http://www.merlyn.demon.co.uk/js-misc0.htm#MLS> and its
implications, if you may need great widths.

This is probably one of the shorter ways of doing what you want; it is
not the shortest
        s = String(1e4+ +s).substring(1)

You could have found an answer by reading the newsgroup FAQ, section 5.1
How do I format a Date object with javascript?, line starting yyyy .

If you actually want to extend a year value, append
<http://www.merlyn.demon.co.uk/js-dates.htm> to the first new paragraph
above.

-- 
 (c) John Stockton, nr London UK  ?@merlyn.demon.co.uk  IE8 FF8 Op11 Sf5 Cr15
   news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
   <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
   <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web