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

Groups > comp.arch.embedded > #31311

Re: Definition of an Algorithm

Show all headers | View raw

On 02/11/2022 23:26, Rick C wrote:
> On Wednesday, November 2, 2022 at 3:29:38 PM UTC-4, Dimiter wrote:
>> On 11/2/2022 20:45, Rick C wrote:
>>> ...
>>>>>
>>>>> 2) Input - ??? I want to say input is optional. So a set of steps
>>>>> to calculate some number of digits of pi would qualify as an
>>>>> algorithm, in spite of not having inputs.
>>>> You could argue that there is always some kind of input. For example,
>>>> you could say that the digit index or the number of digits is the input
>>>> to the "calculate pi" algorithm.
>>>
>>> You can argue anything. A procedure to calculate pi without specifying how many digits would not be an algorithm because of the "finite" requirement. It doesn't need an input to set the number of digits if that is built into the procedure.
>> Of course it is input. You change the number and the output changes.
> 
> If it's part of the procedure, that's not input by definition.
> 

By /your/ definition only.

In Python (for familiarity), you could have :

	mult = lambda x, y : x * y
	mult3 = lambda x : mult(3, x)
	mult3_5 = lambda : mult3(5)

It makes no difference to the theory or the meaning of "algorithm" 
whether the input is part of the function or not.  (Of course it makes a 
major difference in practical use, but not for the theory.)

If you want to learn more, the term to google about is "currying".

> 
>>>>> 4) Finite - the steps must come to an end, i.e. at some point the
>>>>> algorithm has to produce the result, it can't be infinite.
>>>>>
>>>> Is that really true?
>>>>
>>>> If you can accept a "calculate pi" algorithm that does not have an
>>>> input, then it is not finite.
>>>
>>> Not true.
>> Of course it is true. Unless you specify the limits for an operation
>> which is infinite in nature you have the calculating algorithm
>> running infinitely.
> 
> The procedure can specify a number of digits.  Why are you arguing about this???
> 

This is a discussion, not an argument.  You brought up a rather 
theoretical topic, and people have been discussing it beyond your 
current level of familiarity.  The sensible reaction is to see what you 
can learn from this, or to accept that it is going beyond what you know 
about and you are dropping out.  This is all very theoretical, with no 
practical application (that I can imagine) for the kind of work we 
comp.arch.embedded denizens do in real life - either you find these 
things interesting and fun to thing about, or you don't.  (I hope you 
/do/ find it interesting - but I do understand that mathematics and 
computational theory is an unusual hobby, even for professional software 
and hardware developers.)

You perhaps made the first post thinking there is a nice, simple and 
clear definition of "algorithm" and you'd get a nice, simple and clear 
answer to which clause you'd forgotten from that long-ago lecture.  The 
list on Wikipedia of the dozens of mathematicians' definitions of 
"algorithm" through the years should have been a clue that things aren't 
that simple.


> 
>> No need to go about calculating Pi, divide 1 by 3 using the
>> algorithm taught at primary school using a pencil.
> 
> Why bother with that?  Just define it as 3 and be done!
> 

Define 1 / 3 to equal 3?  ": 1/3 3 ;" might be acceptable in Forth, but 
not in mathematics!

> 
>> Without giving it much thought I'd say an algorithm is an unambiguous
>> flowchart made up in order to achieve some goal. Anything more than that
>> would take some qualifier to the word "algorithm".
> 
> Must be nice to be the guy who makes the definitions.
> 

We all get to make such definitions.  The question is whether other 
people agree with them or not.  Dimiter's suggestion here covers the 
lowest common denominator that I expect most people would agree with - 
even if it is also common to include other features (such as your own 
suggestions of input, output and finiteness).

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Definition of an Algorithm Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-01 20:04 -0700
  Re: Definition of an Algorithm Paul Rubin <no.email@nospam.invalid> - 2022-11-01 22:18 -0700
    Re: Definition of an Algorithm Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-01 22:42 -0700
      Re: Definition of an Algorithm David Brown <david.brown@hesbynett.no> - 2022-11-02 09:17 +0100
        Re: Definition of an Algorithm Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 11:37 -0700
          Re: Definition of an Algorithm Paul Rubin <no.email@nospam.invalid> - 2022-11-02 15:56 -0700
          Re: Definition of an Algorithm David Brown <david.brown@hesbynett.no> - 2022-11-03 09:56 +0100
          Re: Definition of an Algorithm George Neuner <gneuner2@comcast.net> - 2022-11-03 08:41 -0400
      Re: Definition of an Algorithm Paul Rubin <no.email@nospam.invalid> - 2022-11-02 14:12 -0700
  Re: Definition of an Algorithm David Brown <david.brown@hesbynett.no> - 2022-11-02 09:49 +0100
    Re: Definition of an Algorithm Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 11:45 -0700
      Re: Definition of an Algorithm Dimiter_Popoff <dp@tgi-sci.com> - 2022-11-02 21:29 +0200
        Re: Definition of an Algorithm Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 15:26 -0700
          Re: Definition of an Algorithm David Brown <david.brown@hesbynett.no> - 2022-11-03 10:25 +0100
      Re: Definition of an Algorithm Niklas Holsti <niklas.holsti@tidorum.invalid> - 2022-11-02 21:53 +0200
        Re: Definition of an Algorithm David Brown <david.brown@hesbynett.no> - 2022-11-02 21:53 +0100
        Re: Definition of an Algorithm Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 15:30 -0700
      Re: Definition of an Algorithm David Brown <david.brown@hesbynett.no> - 2022-11-02 22:12 +0100
      Re: Definition of an Algorithm Paul Rubin <no.email@nospam.invalid> - 2022-11-02 14:45 -0700

csiph-web