Function definition: Difference between revisions

From Rosetta Code
Content added Content deleted
(add Pascal)
Line 40: Line 40:
function multiply(a,b: real): real;
function multiply(a,b: real): real;
begin
begin
multiply = a*b;
multiply := a*b;
end;
end;



Revision as of 16:30, 21 September 2007

Task
Function definition
You are encouraged to solve this task according to the task description, using any language you may know.

A function is a body of code that returns a value. The value returned may depend on arguments provided to the function.

Write a definition of a function called "multiply" that takes two arguments and returns their product.

Ada

function multiply(a : float; b : float) return float is
begin
   return a * b;
end multiply;

C

double multiply( double a, double b )
{
  return a * b;
}

Forth

: fmultiply ( F: a b -- F: c )  F* ;
: multiply ( a b -- c )  * ;

Java

There are no global functions in Java. The equivalent is to define static methods in a class (here invoked as "Math.multiply(a,b)"). Overloading allows us to define the method for multiple types.

public class Math
{
    public static    int multiply(   int a,    int b) { return a*b; }
    public static double multiply(double a, double b) { return a*b; }
}

JavaScript

function multiply(a,b) { return a*b }

MAXScript

fn multiply a b =
(
    a * b
)

Pascal

function multiply(a,b: real): real;
begin
 multiply := a*b;
end;

Perl

sub multiply( $$ )
{
  $a = shift;
  $b = shift;
  return $a * $b;
}

PHP

function multiply( $a, $b )
{
   return $a * $b;
}

Python

Named function:

def multiply(a, b):
    return a * b

Unnamed function:

multiply = lambda a, b: a * b

A callable - may be useful to allow both simple functions and complex classes to use the same interface:

>>> class Multiply:
...     def __call__(self, a, b):
...             return a * b
... 
>>> multiply = Multiply()
>>> multiply(3, 4)
12

Tcl

Strictly as described in the task:

proc multiply { arg1 arg2 } {
   return [expr $arg1 * $arg2]
}

But I'm not sure anybody would write it that way. If nothing else, there's no reason to prefer scalar arguments. And it is unclear why one would impose a limit on the number of arguments. I would write it like this:

proc multiply { args } {
   return [expr [join [join [join $args]] *]]
}

This will accept one or more arguments which can be scalars or lists (or even nested lists) and returns the product of all of them. E.g.

% multiply "1 2" {3 4} [list 5 6] {{7 8} 9}
 
=> 362880

Toka

[ ( ab-c ) * ] is multiply