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

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

Why does it slow down for bases above 10?

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

Contents

  Why does it slow down for bases above 10? jonas.thornvall@gmail.com - 2015-05-15 11:57 -0700
    Re: Why does it slow down for bases above 10? jonas.thornvall@gmail.com - 2015-05-15 12:25 -0700
      Re: Why does it slow down for bases above 10? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-15 21:41 +0100
        Re: Why does it slow down for bases above 10? jonas.thornvall@gmail.com - 2015-05-15 14:20 -0700
        Re: Why does it slow down for bases above 10? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-15 23:21 +0200
          Re: Why does it slow down for bases above 10? jonas.thornvall@gmail.com - 2015-05-15 14:37 -0700
            Re: Why does it slow down for bases above 10? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-15 23:34 +0100
              Re: Why does it slow down for bases above 10? "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-05-16 01:27 +0200
              Re: Why does it slow down for bases above 10? jonas.thornvall@gmail.com - 2015-05-16 01:53 -0700
                Re: Why does it slow down for bases above 10? jonas.thornvall@gmail.com - 2015-05-16 02:18 -0700
                Re: Why does it slow down for bases above 10? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-16 11:05 +0100
                  Re: Why does it slow down for bases above 10? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-16 17:58 +0200

#27644 — Why does it slow down for bases above 10?

http://jt.node365.se/baseconversion.html

[toc] | [next] | [standalone]

#27645

Den fredag 15 maj 2015 kl. 20:58:10 UTC+2 skrev jonas.t...@gmail.com:
> http://jt.node365.se/baseconversion.html

If someone can point out the bug for base above 10 in my generic basechanger it would be great.

Because then i can go on show how todo very fast arithmetic using big bases.
And how to speed up baseconversion using search algorithms.

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

#27646

jonas.thornvall@gmail.com writes:

> Den fredag 15 maj 2015 kl. 20:58:10 UTC+2 skrev jonas.t...@gmail.com:
>> http://jt.node365.se/baseconversion.html
>
> If someone can point out the bug for base above 10 in my generic
> basechanger it would be great.

That's unlikely.  The code is some of the least inviting I've ever seen.
Global variables all over the place.  Functions that should return
values depositing results into globals instead.  Names that carry little
or no meaning ("loop", "looptwo", "arrCompareTwo").  It's almost
impossible to follow.

-- 
Ben.

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

#27647

Den fredag 15 maj 2015 kl. 22:41:30 UTC+2 skrev Ben Bacarisse:
> jonas.thornvall@gmail.com writes:
> 
> > Den fredag 15 maj 2015 kl. 20:58:10 UTC+2 skrev jonas.t...@gmail.com:
> >> http://jt.node365.se/baseconversion.html
> >
> > If someone can point out the bug for base above 10 in my generic
> > basechanger it would be great.
> 
> That's unlikely.  The code is some of the least inviting I've ever seen.
> Global variables all over the place.  Functions that should return
> values depositing results into globals instead.  Names that carry little
> or no meaning ("loop", "looptwo", "arrCompareTwo").  It's almost
> impossible to follow.
> 
> -- 
> Ben.

You said almost ;)

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

#27648

Ben Bacarisse wrote:

> jonas.thornvall@gmail.com writes:
>> Den fredag 15 maj 2015 kl. 20:58:10 UTC+2 skrev jonas.t...@gmail.com:
>>> http://jt.node365.se/baseconversion.html
>>
>> If someone can point out the bug for base above 10 in my generic
>> basechanger it would be great.
> 
> That's unlikely.  The code is some of the least inviting I've ever seen.
> Global variables all over the place.  Functions that should return
> values depositing results into globals instead.  Names that carry little
> or no meaning ("loop", "looptwo", "arrCompareTwo").  It's almost
> impossible to follow.

Add to that

<http://validator.w3.org/check?uri=jt.node365.se%2Fbaseconversion.html&ss=1&verbose=1>

All that is to be expected when a wannabe does “javascript”.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#27649

Den fredag 15 maj 2015 kl. 23:24:15 UTC+2 skrev Thomas 'PointedEars' Lahn:
> Ben Bacarisse wrote:
> 
> > jonas.thornvall@gmail.com writes:
> >> Den fredag 15 maj 2015 kl. 20:58:10 UTC+2 skrev jonas.t...@gmail.com:
> >>> http://jt.node365.se/baseconversion.html
> >>
> >> If someone can point out the bug for base above 10 in my generic
> >> basechanger it would be great.
> > 
> > That's unlikely.  The code is some of the least inviting I've ever seen.
> > Global variables all over the place.  Functions that should return
> > values depositing results into globals instead.  Names that carry little
> > or no meaning ("loop", "looptwo", "arrCompareTwo").  It's almost
> > impossible to follow.
> 
> Add to that
> 
> <http://validator.w3.org/check?uri=jt.node365.se%2Fbaseconversion.html&ss=1&verbose=1>
> 
> All that is to be expected when a wannabe does "javascript".
> 
> -- 
> PointedEars
> FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
> Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
> Please do not cc me. / Bitte keine Kopien per E-Mail.

Well i am more of a do just do it kind of programmer, if you want a fully fledged optimized generic basechanger that even do bignumbs. That would be a quite challenging task. Especially if you want to use Javascript to it's full potential.

I basicly write basic compatible code but use some of the nice array functions from Ecmascript.

I think the bignumb base conversion work quite good, well at least for bases under 10.

And it is a generic basechanger working on bignumbs afterall so it is not preciely easy logic.

I was concentrated on get it to work, and i am partially there. Optimization would rather be to implement the search for digitplace rather than, make the code wonderful.

Fixing details can always be done when something working, or partially working.

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

#27651

jonas.thornvall@gmail.com writes:

> Den fredag 15 maj 2015 kl. 23:24:15 UTC+2 skrev Thomas 'PointedEars' Lahn:
>> Ben Bacarisse wrote:
>> 
>> > jonas.thornvall@gmail.com writes:
>> >> Den fredag 15 maj 2015 kl. 20:58:10 UTC+2 skrev jonas.t...@gmail.com:
>> >>> http://jt.node365.se/baseconversion.html
>> >>
>> >> If someone can point out the bug for base above 10 in my generic
>> >> basechanger it would be great.
>> > 
>> > That's unlikely.  The code is some of the least inviting I've ever seen.
>> > Global variables all over the place.  Functions that should return
>> > values depositing results into globals instead.  Names that carry little
>> > or no meaning ("loop", "looptwo", "arrCompareTwo").  It's almost
>> > impossible to follow.
>> 
>> Add to that
>> 
>> <http://validator.w3.org/check?uri=jt.node365.se%2Fbaseconversion.html&ss=1&verbose=1>
>> 
>> All that is to be expected when a wannabe does "javascript".
>> 
>> -- 
>> PointedEars
>> FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
>> Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
>> Please do not cc me. / Bitte keine Kopien per E-Mail.
>
> Well i am more of a do just do it kind of programmer, if you want a
> fully fledged optimized generic basechanger that even do
> bignumbs. That would be a quite challenging task. Especially if you
> want to use Javascript to it's full potential.

No, that's not the aim.  Your aim is simply to get the code to work but
you've make it it too complicated for you to understand and too
complicated for anyone else to try to understand.  I suppose you might e
able to work out what's wrong, but it seems unlikely.  And if you do,
you'll hit another bug, and another and another... because the structure
of the code makes more bugs inevitable.

<snip>
> And it is a generic basechanger working on bignumbs afterall so it is
> not preciely easy logic.

The logic is easy if you decompose the problem into the right
components, but you've make all the parts interlinked through globals.

> I was concentrated on get it to work, and i am partially
> there. Optimization would rather be to implement the search for
> digitplace rather than, make the code wonderful.
>
> Fixing details can always be done when something working, or partially
> working.

Generations of programmers have found that this approach does not work.
You have to get the right structure to stat with or the program just
gets more and more impenetrable as it develops.

-- 
Ben.

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

#27653

Ben Bacarisse wrote:

> jonas.thornvall@gmail.com writes:
> 
>> I was concentrated on get it to work, and i am partially
>> there. Optimization would rather be to implement the search for
>> digitplace rather than, make the code wonderful.
>>
>> Fixing details can always be done when something working, or partially
>> working.
> 
> Generations of programmers have found that this approach does not work.
> You have to get the right structure to stat with or the program just
> gets more and more impenetrable as it develops.

I may add that this particular problem would be easily amenable to unit
tests, if it were solved appropriately, what would help to avoid
regression bugs during further development.

-- 
Christoph M. Becker

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

#27659

Den lördag 16 maj 2015 kl. 00:34:10 UTC+2 skrev Ben Bacarisse:
> jonas.thornvall@gmail.com writes:
> 
> > Den fredag 15 maj 2015 kl. 23:24:15 UTC+2 skrev Thomas 'PointedEars' Lahn:
> >> Ben Bacarisse wrote:
> >> 
> >> > jonas.thornvall@gmail.com writes:
> >> >> Den fredag 15 maj 2015 kl. 20:58:10 UTC+2 skrev jonas.t...@gmail.com:
> >> >>> http://jt.node365.se/baseconversion.html
> >> >>
> >> >> If someone can point out the bug for base above 10 in my generic
> >> >> basechanger it would be great.
> >> > 
> >> > That's unlikely.  The code is some of the least inviting I've ever seen.
> >> > Global variables all over the place.  Functions that should return
> >> > values depositing results into globals instead.  Names that carry little
> >> > or no meaning ("loop", "looptwo", "arrCompareTwo").  It's almost
> >> > impossible to follow.
> >> 
> >> Add to that
> >> 
> >> <http://validator.w3.org/check?uri=jt.node365.se%2Fbaseconversion.html&ss=1&verbose=1>
> >> 
> >> All that is to be expected when a wannabe does "javascript".
> >> 
> >> -- 
> >> PointedEars
> >> FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
> >> Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
> >> Please do not cc me. / Bitte keine Kopien per E-Mail.
> >
> > Well i am more of a do just do it kind of programmer, if you want a
> > fully fledged optimized generic basechanger that even do
> > bignumbs. That would be a quite challenging task. Especially if you
> > want to use Javascript to it's full potential.
> 
> No, that's not the aim.  Your aim is simply to get the code to work but
> you've make it it too complicated for you to understand and too
> complicated for anyone else to try to understand.  I suppose you might e
> able to work out what's wrong, but it seems unlikely.  And if you do,
> you'll hit another bug, and another and another... because the structure
> of the code makes more bugs inevitable.
> 
> <snip>
> > And it is a generic basechanger working on bignumbs afterall so it is
> > not preciely easy logic.
> 
> The logic is easy if you decompose the problem into the right
> components, but you've make all the parts interlinked through globals.
> 
> > I was concentrated on get it to work, and i am partially
> > there. Optimization would rather be to implement the search for
> > digitplace rather than, make the code wonderful.
> >
> > Fixing details can always be done when something working, or partially
> > working.
> 
> Generations of programmers have found that this approach does not work.
> You have to get the right structure to stat with or the program just
> gets more and more impenetrable as it develops.
> 
> -- 
> Ben.

Well it is a hobby project afterall and i think the development using a RAD like approach. The global aim for the project is to show different ways of doing highlevel arithmetic in bignumbs, and show how the format/interpretation rules of digitplaces and symbols *at highlevel* do affect the arithmetic performed at binary level, and how the computational complexity changes with the tools used.
 

The specific need of algorithms and functions of this project is not welldefined, so i can not make a flowchart, or an object tree model.

The functions and algorithms are developed as the need for them occur that does not mean i do not want general working code, quite the opposite there is a need for it since many functions work upon the same operand arrays.

And that is why they are global, it is not like the program is a big main with endless nested loops. It is quite welldefined functional behaviour, but i agree my comments are absent, and the variable and function naming sometimes misleading.

That is a RAD problem the full plan is not thought thru.

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

#27662

Den lördag 16 maj 2015 kl. 10:53:22 UTC+2 skrev jonas.t...@gmail.com:
> Den lördag 16 maj 2015 kl. 00:34:10 UTC+2 skrev Ben Bacarisse:
> > jonas.thornvall@gmail.com writes:
> > 
> > > Den fredag 15 maj 2015 kl. 23:24:15 UTC+2 skrev Thomas 'PointedEars' Lahn:
> > >> Ben Bacarisse wrote:
> > >> 
> > >> > jonas.thornvall@gmail.com writes:
> > >> >> Den fredag 15 maj 2015 kl. 20:58:10 UTC+2 skrev jonas.t...@gmail.com:
> > >> >>> http://jt.node365.se/baseconversion.html
> > >> >>
> > >> >> If someone can point out the bug for base above 10 in my generic
> > >> >> basechanger it would be great.
> > >> > 
> > >> > That's unlikely.  The code is some of the least inviting I've ever seen.
> > >> > Global variables all over the place.  Functions that should return
> > >> > values depositing results into globals instead.  Names that carry little
> > >> > or no meaning ("loop", "looptwo", "arrCompareTwo").  It's almost
> > >> > impossible to follow.
> > >> 
> > >> Add to that
> > >> 
> > >> <http://validator.w3.org/check?uri=jt.node365.se%2Fbaseconversion.html&ss=1&verbose=1>
> > >> 
> > >> All that is to be expected when a wannabe does "javascript".
> > >> 
> > >> -- 
> > >> PointedEars
> > >> FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
> > >> Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
> > >> Please do not cc me. / Bitte keine Kopien per E-Mail.
> > >
> > > Well i am more of a do just do it kind of programmer, if you want a
> > > fully fledged optimized generic basechanger that even do
> > > bignumbs. That would be a quite challenging task. Especially if you
> > > want to use Javascript to it's full potential.
> > 
> > No, that's not the aim.  Your aim is simply to get the code to work but
> > you've make it it too complicated for you to understand and too
> > complicated for anyone else to try to understand.  I suppose you might e
> > able to work out what's wrong, but it seems unlikely.  And if you do,
> > you'll hit another bug, and another and another... because the structure
> > of the code makes more bugs inevitable.
> > 
> > <snip>
> > > And it is a generic basechanger working on bignumbs afterall so it is
> > > not preciely easy logic.
> > 
> > The logic is easy if you decompose the problem into the right
> > components, but you've make all the parts interlinked through globals.
> > 
> > > I was concentrated on get it to work, and i am partially
> > > there. Optimization would rather be to implement the search for
> > > digitplace rather than, make the code wonderful.
> > >
> > > Fixing details can always be done when something working, or partially
> > > working.
> > 
> > Generations of programmers have found that this approach does not work.
> > You have to get the right structure to stat with or the program just
> > gets more and more impenetrable as it develops.
> > 
> > -- 
> > Ben.
> 
> Well it is a hobby project afterall and i think the development using a RAD like approach. The global aim for the project is to show different ways of doing highlevel arithmetic in bignumbs, and show how the format/interpretation rules of digitplaces and symbols *at highlevel* do affect the arithmetic performed at binary level, and how the computational complexity changes with the tools used.
>  
> 
> The specific need of algorithms and functions of this project is not welldefined, so i can not make a flowchart, or an object tree model.
> 
> The functions and algorithms are developed as the need for them occur that does not mean i do not want general working code, quite the opposite there is a need for it since many functions work upon the same operand arrays.
> 
> And that is why they are global, it is not like the program is a big main with endless nested loops. It is quite welldefined functional behaviour, but i agree my comments are absent, and the variable and function naming sometimes misleading.
> 
> That is a RAD problem the full plan is not thought thru.

I think there is a lack in javascript though, it is not quite clear when one actually work upon the array itself or if one work upon a local instance of the array.

Or maybe i am just confused about it.

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

#27667

jonas.thornvall@gmail.com writes:
<snip>
> Well it is a hobby project afterall and i think the development using
> a RAD like approach. The global aim for the project is to show
> different ways of doing highlevel arithmetic in bignumbs, and show how
> the format/interpretation rules of digitplaces and symbols *at
> highlevel* do affect the arithmetic performed at binary level, and how
> the computational complexity changes with the tools used.

I think you are misusing tterms here.  Analysing computational
complexity needs no code at all.  I think you want code to demonstrate
the practical costs of what you imagine doing.

> The specific need of algorithms and functions of this project is not
> welldefined, so i can not make a flowchart, or an object tree model.

That does not inevitably lead to bad code.  In fact RAD needs very good
code because the idea is to change it frequently as the development
progresses (refactor is the jargon term).  At each stage you do have
well-defined goals: read in a number, print a number, convert from base
A to base B, and so on.  But as the goals get more complex, the design
and code keep getting re-written to accommodate them.  You don't just
keep adding more and more globals.

And there is nothing "rapid" to choosing bad names.  Calling a function
"isLessThan" is not slower than calling it "compareTwo".

You will get stuck at some point.  You will end up with code so tangled
that you can no longer change it without catastrophic effects on its
behaviour.  I think you are already close to that point.

You should spend at least half of the project time learning to program,
or you will simply not be able to finish it.

> The functions and algorithms are developed as the need for them occur
> that does not mean i do not want general working code, quite the
> opposite there is a need for it since many functions work upon the
> same operand arrays.

This is why you must avoid globals.  They will mess up the key
separation you need to have bignums with bignum bases.  If do nothing
else, do this.  Remove every global variable that you can so that
all your functions compute results only from their arguments.

> And that is why they are global, it is not like the program is a big
> main with endless nested loops. It is quite welldefined functional
> behaviour, but i agree my comments are absent, and the variable and
> function naming sometimes misleading.

Every programmer will tell you the opposite.  This is not a conspiracy
of dunces.  It is, very often, the result of bitter experience.  I
started by career helping professional scientists who were, in those
days, forced to be amateur programmers.  In every case, the programs
were a tangle of subroutines intertwined by information flowing though
global variables.  In some cases I could do nothing but say "start
again".

> That is a RAD problem the full plan is not thought thru.

RAD does not imply bad programming.  It's not an excuse.  In fact it
makes good structure essential.

-- 
Ben.

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

#27691

Ben Bacarisse wrote:

> jonas.thornvall@gmail.com writes:
>> The functions and algorithms are developed as the need for them occur
>> that does not mean i do not want general working code, quite the
>> opposite there is a need for it since many functions work upon the
>> same operand arrays.
> 
> This is why you must avoid globals.  They will mess up the key
> separation you need to have bignums with bignum bases.  If do nothing
> else, do this.  Remove every global variable that you can so that
> all your functions compute results only from their arguments.

He does not even have global variables.  He has deletable properties of the 
ECMAScript global object at best, assuming that each of the assignments is 
successful as the scope chain is considered.  If an object in the scope 
chain has a property with the same name and that cannot be written to, the 
result of the assignment can be throwing an exception or causing an 
unrecoverable runtime error.  (This is different from e.g. Python, where 
symbols are local unless assigned to in the global execution context or 
declared global in a function context.)

For the amateur programmer and the more experienced programmer not 
accustomed to using an ECMAScript implementation, the easiest way to see 
where they went wrong is to test their code in a modern browser that uses
an implementation of ES 5+, and enable strict mode by prepending a line 
containing onlya

"use strict";

to their code.

In this case, the first assignment to an undeclared symbol will throw a 
ReferenceError exception.  One can then determine if the symbol actually 
needs to be globally available.  If not, one should declare it a local 
variable by using the “var” statement in function context; otherwise, “var” 
in global context to declare it a global variable.  One should then 
endeavour to eliminate as many global variables as possible through 
refactoring.

Finally, the script console and code linters such as JSHint can show further 
common mistakes, however the warnings generated by those tools should be 
considered carefully as some of them are bogus or the result of a too strict 
configuration.

This approach can be more efficient than a rewrite.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

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

csiph-web