Shlomi Fish <shlo...@shlomifish.org> writes:
> Hi lee,
>
> I decided to try to give you another chance to be educated, despite Uri's
> conclusion in the other thread. Hopefully you won't let me down.
He has made a lot of conclusions and decided not to say anything
further. I know it can be difficult to convince me of something.
> On Thu, 25 May 2017 16:48:13 +0100
> lee <l...@yagibdah.de> wrote:
>
>> Shlomi Fish <shlo...@shlomifish.org> writes:
>>
>> > [...]
>> >> >> while ( my $numbline = <DATA> ) {
>> >> >> chomp $numbline;
>> >> >> my @numbline = split //, $numbline;
>> >> >
>> >> > You're processing the input number line-by-line, but it's one whole
>> >> > number and the products may span across more than one line. You need to
>> >> > slurp it and prepare an array of digits.
>> >>
>> >> Isn't it more efficient to put all the digits into a string rather than
>> >> into an array and use substr()?
>> >>
>> >
>> > I believe it should be more space efficient, but perl shouldn't have a
>> > problem managing an array of a 1,000 digits on most machines.
>>
>> Yes, I'm just wondering.
>>
>> It doesn't even depend on how many digits there are because it's
>> possible to consider only the relevant portion of the digits in each
>> step.
>>
>
> Thinking about it one may wish to use the
> https://en.wikipedia.org/wiki/Stream_(computing) pattern (if one calls it
> that) and just keep a https://en.wikipedia.org/wiki/Circular_buffer of the
> last
> 13 or so elements.
Yes, that's what I was thinking. You could have a huge amount of
digits and still only need to consider the few adjacent ones.
>> > See https://duckduckgo.com/?q=premature+optimization+evil+quote&ia=web
>> > - we should worry about optimising when we need to - not before.
>>
>> I don't agree that all optimization is evil to begin with. I can not
>> write a line of code without optimizing first because otherwise, I
>> wouldn't know what to write. Can you?
>>
>> Knowing what is more efficient helps me before the first line of a
>> program is written and with every single line of it. I couldn't do any
>> overall design without knowing.
>>
>> Even syntax highlighting, reasonable formatting and reasonable use of
>> comments is an optimization.
>>
>> The point is to do the right amount of optimization which allows you to
>> make appropriate progress towards a working version. Once you have that,
>> you can optimize more or leave it as is.
>>
>> Programming is a creative process of optimization.
>>
>
> First of all note that I strongly believe the quote referred to speed /
> runtime
> optimisation - not to https://en.wikipedia.org/wiki/Code_refactoring ,
> cleanups , bug fixes , code design and other unrelated activities.
You gave a link to a search engine listing many findings, so I didn't
see exactly to which of them you were referring and to which of them
not.
> Secondly, it talked about *premature* optimisation, where you spend a
> lot of time optimising before there is a proven and genuine need for
> it. There is such a thing as "Time to market" and also needlessly
> changing the code always risks introducing bugs, so one should try to
> avoid it.
I must have missed the specific quote you're referring to.
When you're writing some program, or even before you start writing one,
and a number of different ways to do what needs to be done come to mind,
which one do you pick? The one you think is faster, more efficient or
in some other way better than another one, or the first one that comes
to mind, regardless how bad it might be? This is assuming the solutions
are comparable, i. e. that you wouldn't pick an overly complex solution
over a simple one unless there are good reasons to do so.
I would pick the one I think is faster, more efficient or in some other
way better than another one, preferably before I start writing. While
writing, when a decision needs to be made, I also pick the solution
which I think is better, within the limits of what I've been writing so
far. Once it's working, further optimization may be needed or not.
I don't know if you would call this premature optimization and reject
it. I merely don't agree to oversimplifying advice saying you should
not optimize unless you fall on your face straight away.
There is not only "time to market" but also "market time". Having the
waiting time of 10 employees adding up to 5 minutes each month for each
of them can easily cost so much that the savings from optimizing it down
to 2 minutes pay tenfold for the cost of optimizing.
I might not need to optimize because I picked the faster solution in the
first place, at very low additional cost, if any. I needed to make a
decision about how to do things anyway.
>> Since we're looking at a mathematical excersise here, we might use it to
>> learn something about programming :)
>>
>> > Using arrays allows us to use convenient operators and functions that
>> > are less native to strings.
>>
>> Ok, let me be a smartass:
>>
>> substr() is only so native to strings as perl does not do implicit
>> typecasting.
>
> What is "typecasting" in this context?
The overall gist is that a string is converted into an integer.
Technically, you could say that a character is converted into an
integer, and more correctly, that a character used to represent an
integer is interpreted as the very integer it is used to represent.
According to [1], substr(EXPR) "Extracts a substring out of EXPR and
returns it.". Effectively, the return value of a function "native to
strings" implicitly turns out to be an integer. That kind of magic
makes it questionable how native that function is to strings.
I could say that
my $x = "5";
printf("%d\n", substr($x, 0, 1));
should produce an error message, or at least a warning, because $x is
definitely not numerical if substr() is native to strings.
Mind you that [2] says about sprintf() (which printf() refers you to):
"Returns a string formatted by the usual printf conventions of the C
library function sprintf.". Later it points out that the conversion
specified with "%d" is for the conversion of "a signed integer, in
decimal". Try this and see what it prints:
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char **argv)
{
char *x = "5";
printf("%d\n", *x);
exit(0);
}
Perl uses magic here. It does so consistently, so saying that something
is "native to strings" in perl is questionable to me.
[1]: http://perldoc.perl.org/5.8.8/functions/substr.html
[2]: http://perldoc.perl.org/5.8.8/functions/sprintf.html
>
>>
>> The operator in question is multiplication. Are there different
>> multiplication operators in perl which are more or less convenient?
>>
>
> There is https://metacpan.org/pod/List::Util#product
Ok, you could say that this a different multiplication operator :)
> and I also refer to array
> slicing (e.g @array[@indices]), map, grep, and lots of other stuff.
Is slicing more efficient? How would you use the others in this
example?
>> Did I use inconvenient operators?
>>
>> > Also note that using http://perldoc.perl.org/functions/vec.html should
>> > allow to store a digit within 4 bits in a binary buffer, which is even
>> > better than using a string.
>>
>> Hm, I don't understand this documentation. This function seems to be
>> designed to mess up things by confusing strings with bytes and could be
>> considered as a symptom of perl not having variables of fixed types.
>>
>
> vec uses a binary buffer as input, which is usable as a non-unicode string.
>
>> Maybe I'd understand from a safe and evident use case for it.
>>
>
> Let's say you want to have a https://en.wikipedia.org/wiki/Bit_array that maps
> non-negative integers to a false/true value. You can initialise it as
> all-Falses using «my $bit_vec = '';» and then set or lookup «vec($bit_vec,
> $idx, 1)». This is useful for
> https://en.wikipedia.org/wiki/Generating_primes#Prime_sieves - prime sieving.
This is a very bad use case for me because I have no idea what all the
fuss about prime numbers ppl like to make is about.
> [...]
>> >> while($start < $end) {
>> >
>> > This should be a «for my $idx ($start .. $end-1)» loop.
>>
>> Why?
>>
>> I would think using '$end - 1' is particularly bad because it needs to
>> be computed for each run of the loop unless the optimizer does a good
>> job, which I don't know.
>
> The contents of the parentheses in such a foreach loop are evaluated only once
> - at loop initialisation. So it's safe to rely on that.
What if $end changes during the loop?
>> Since I don't know and since I know that it
>> can't be optimized out in all cases, I always prefer to use loop
>> boundaries that do not need to be recalculated for each loop. --- This
>> is not specific to perl, and while the perl optimizer may do a good job,
>> optimizers for other languages might not, so generally don't use loop
>> boundaries that may be calculated for each loop unless it can't be
>> avoided.
>
> Perl is not other languages. You should write idiomatic Perl code (or
> idiomatic
> code in other languages).
Because it's more difficult?
>> I am --- perhaps overly --- fond of using while() for loops rather than
>> for(). I'm finding while() loops easier to read because they are more
>> explicit and easier to use than for() because the notation of for()
>> loops in different languages varies while the notation of while() loops
>> does not. You also can easily turn them around by using 'do { ... }
>> while();' when needed, which you can't do with for() loops.
>>
>
> do { ... } while has bad behaviour in Perl. A better idea is to either use a
> closure and execute it once before the while() loop or use a $run_once
> variable.
What kind of bad behaviour does it have?
>> So what advantage would a for() loop have, in general and particularly
>> in this case? I would not use '$end - 1', so the for() would require
>> another variable or some other kind of further ado.
>>
>> The adornments of for() loops make them intricate; while() loops are
>> unadorned, hence remain plain and simple, and it is good to write stuff
>> explicitly as long as it serves to make clear what you mean. A for()
>> loop doesn't help me making clear what I mean because it is intricate by
>> its nature.
>>
>
> for and foreach loops work well and are easy to understand.
While() loops work well and are easy to understand.
> [...]
>> > No need for the exit statement here.
>>
>> Write stuff explicitly and tidy. The program ends here, even defining a
>> return code. You can easily see that right away.
>>
>> Otherwise, I would need to enable the scroll bars and look at them, or
>> move point to the end of the buffer, or do something else to be sure.
>>
>> It's not needed but clear. I do like adornments when they're helpful.
>>
>
> well, it is redundant.
Redundancy is sometimes a good thing.
>> >>
>> >> Is this supposed to be a programming exercise? It's a purely
>> >> mathematical one to me.
>> >>
>> >
>> > See https://en.wikipedia.org/wiki/Project_Euler for the Project Euler
>> > mission and motivation.
>>
>> Why is it that everyone interested in programming is assumed to be
>> interested in mathematics?
>>
>
> P.E. is intended for such people, but it does not force itself upon
> you.
It is a general assumption, encountered often times.
> The
> original poster asked about a problem they ran into with it, and I replied.
> There are other sites with programming challenges:
>
> *
> https://github.com/vhf/free-programming-books/blob/master/problem-sets-competitive-programming.md
It's interesting what ideas ppl come up with. I never knew there were
so many sites like the ones the book links to.
> *
> https://github.com/shlomif/Freenode-programming-channel-FAQ/blob/master/FAQ.mdwn#i-feel-like-programming-something-but-i-dont-know-what-can-you-suggest-some-good-ideas-for-programs
That's an interesting read :)
>
>> I can't do mathematics at all because I understand things by removing
>> abstractions. Remove all abstractions from mathematics and nothing
>> remains. I can only use it, to some limited extend, like a computer
>> executes a program. That isn't very interesting, and I have computers
>> to do that for me so I don't need to.
>
> First of all I should note that many of the "abstractions" of maths manifest
> itself in nature in all kinds of places and are useful in many
> sciences.
Mathematics itself is an abstraction, or is there anything else to it?
For a very long time, I kept wondering if there is anything there to
understand about it and never found an answer until I eventually
realised that it is nothing but an abstraction, which kinda answers that
question and also let it become clear to me why I can't do math: There
is just nothing there do to anything with.
It would probably be very enlightened if you could prove me wrong. I'm
not saying that mathematics isn't useful.
> For example the https://en.wikipedia.org/wiki/Binary_search_algorithm
> run time is logarithmic.
I can understand that it means that you can increase the number of
elements to search from more than it takes longer to find what you're
looking for.
But what does that mean? How is this an example? What does it have to
do with mathematics?
It's simply a given that this is so. If mathematics didn't exist, it
would still be the same. Does mathematics explain why this is so and
how it came to be?
> Moreover, many abstractions are independent of maths.
Like the run time of binary searches?
> You don't need to know how a tool works (including a computer) to use
> it, so this tool is an abstraction.
Understanding something and knowing how it works are two different
things. You may know how a computer works, or how a hammer works, and
that doesn't mean you could invent either, or modify them so they make a
better tool for you. To do that, you need to understand, and usually
your understanding needs to go far beyond the tool as is, before you can
make an invention or a modification.
I can use math like a Chimpanse can use a hammer. The Chimpanse
understands how the hammer works probably as much as I understand how
mathematics works. We use them as they are. One of the differences is
that I can invent a binary search algorithm (it is evident that
searching in the right direction can be faster than searching in
another), without understanding mathematics, and the Chimpanse can
probably not, with or without understanding mathematics.
Just beat the nut hard enough and it will crack eventually. That's also
evident. If it doesn't crack, I'll invent a better hammer or something
else. Even the Chimpanse might do that.
The tool is not an abstraction. It's tangible and solid, you can wield
it, and you can see how it works or doesn't work, and when you
understand it, you can make it better, or another one.
Mathematics is an abstraction, isn't it? It has been defined from
scratch, and it is nothing but defined. You can not define a hammer,
and you can not define a nut for they are objects that exist. You only
can abstract from the hammer and the nut, invent words referring to your
--- and *only* your --- abstraction of them, so you can classify objects
into hammers and nuts.
What happens when mathematics adds a hammer and a nut? IIUC, you would
have to say it's not possible (because it doesn't fit into the
definitions math is built from), and that is a very poor way mathematics
has for dealing with hammers and nuts. I'm still finding that
unacceptable. And I can add them to my backpack easily, or invent a
nuthammer.
> There are many abstractions in English as well.
Languages like English are constantly being invented when ever they are
being used. Does this also go for mathematics?
--
"Didn't work" is an error.
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
