# Gauging Interest:RFC to add map() function

- Thread: https://externals.io/message/67884
- Original archive: https://news-web.php.net/php.internals/67884
- Started by Jeremy Curcio on 2013-06-26T15:20:01+00:00
- Messages: 10
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #67884 — Jeremy Curcio — 2013-06-26T15:20:01+00:00

URL: https://externals.io/message/67884#67884

Hello,

I would like to submit an RFC to add a new function to the PHP language. The function would be called "map()". The purpose of this function would be to take an existing value within a range and make it to a corresponding location within a new range.

The map() method would have 5 required parameters, $originalLow, $originalHigh, $newLow, $newHigh, and $value.

map() would be implement the following:

function map($originalLow, $originalHigh, $newLow, $newHigh, $value) {
	return $newLow + ($value - $originalLow) * ($newHigh - $newLow) / ($originalHigh- $originalLow);
}

Example:
Let's say we are teachers and are grading final exams. We have a policy that the best score is 100, and the worst score is a 70. Students scored between 55 and 92. We want to easily re-score the exams to be within the new score range, so we would use the new map() function. Let's begin with mapping the lowest score:
    
	$newScore = map(55, 92, 70, 100, 55); //$newScore = 70
    
If we have all of our scores in an array:

	$scores = array(71, 65, 55, 85, 88, 86, 92, 77, 73);

We could use a foreach loop to remap each value:

	$newScores = array();
	foreach($score as $scores) {
		$newScores[] = map(55, 92, 70, 100, $score);
	}
	var_dump($newScores);
	/*
	array(9) {
	  [0]=>
	  float(82.972972972973)
	  [1]=>
	  float(78.108108108108)
	  [2]=>
	  int(70)
	  [3]=>
	  float(94.324324324324)
	  [4]=>
	  float(96.756756756757)
	  [5]=>
	  float(95.135135135135)
	  [6]=>
	  int(100)
	  [7]=>
	  float(87.837837837838)
	  [8]=>
	  float(84.594594594595)
	  }
	*/

Just like that, we have the new exam grades that fit our policy, within the proper scale, without having to do any of the messy math ourselves.

While I do recognize that this is somewhat trivial to anyone who knows the proper formula, I feel as though it would serve the PHP community well. Much the same as the `pow()` or `pi()` functions do. I appreciate your thoughts on this matter and whether or not this is worth pursuing as an RFC.

Thank you,
Jeremy Curcio
j.curcio@me.com

---

## #67886 — Mike Willbanks — 2013-06-26T15:48:59+00:00

URL: https://externals.io/message/67884#67886 · In reply to: #67884

Hello Jeremy,




> Hello,
>
> I would like to submit an RFC to add a new function to the PHP language.
> The function would be called "map()". The purpose of this function would be
> to take an existing value within a range and make it to a corresponding
> location within a new range.
>

A map() function is normally part of functional programming and as such
would cause confusion and likely would not mean what most programmers would
assume.  See python and JS docs:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map
http://docs.python.org/2/howto/functional.html

Yes; we do have array_map; but I still do not assume that this would be
a mathematical function.


>
> The map() method would have 5 required parameters, $originalLow,
> $originalHigh, $newLow, $newHigh, and $value.
>
> map() would be implement the following:
>
> function map($originalLow, $originalHigh, $newLow, $newHigh, $value) {
> return $newLow + ($value - $originalLow) * ($newHigh - $newLow) /
> ($originalHigh- $originalLow);
> }
>

I am curious with something that is so easy; why would you want it in core?


>
> Example:
> Let's say we are teachers and are grading final exams. We have a policy
> that the best score is 100, and the worst score is a 70. Students scored
> between 55 and 92. We want to easily re-score the exams to be within the
> new score range, so we would use the new map() function. Let's begin with
> mapping the lowest score:
>
> $newScore = map(55, 92, 70, 100, 55); //$newScore = 70
>
> If we have all of our scores in an array:
>
> $scores = array(71, 65, 55, 85, 88, 86, 92, 77, 73);
>
> We could use a foreach loop to remap each value:
>
> $newScores = array();
> foreach($score as $scores) {
>  $newScores[] = map(55, 92, 70, 100, $score);
> }
> var_dump($newScores);
> /*
> array(9) {
>   [0]=>
>   float(82.972972972973)
>   [1]=>
>   float(78.108108108108)
>   [2]=>
>   int(70)
>   [3]=>
>   float(94.324324324324)
>   [4]=>
>   float(96.756756756757)
>   [5]=>
>   float(95.135135135135)
>   [6]=>
>   int(100)
>   [7]=>
>   float(87.837837837838)
>   [8]=>
>   float(84.594594594595)
>   }
> */
>
> Just like that, we have the new exam grades that fit our policy, within
> the proper scale, without having to do any of the messy math ourselves.
>
> While I do recognize that this is somewhat trivial to anyone who knows the
> proper formula, I feel as though it would serve the PHP community well.
> Much the same as the `pow()` or `pi()` functions do. I appreciate your thoughts
> on this matter and whether or not this is worth pursuing as an RFC.
>
> Thank you,
> Jeremy Curcio
> j.curcio@me.com

---

## #67895 — Levi Morrison — 2013-06-26T16:25:47+00:00

URL: https://externals.io/message/67884#67895 · In reply to: #67884

> Hello,
>
> I would like to submit an RFC to add a new function to the PHP language.
> The function would be called "map()". The purpose of this function would be
> to take an existing value within a range and make it to a corresponding
> location within a new range.
>

The functionality provided is uncommon but perhaps usefu. However, I am
*very* against the name `map` which has a very established meaning in the
programming world; others have already mentioned this but I felt I should
mention it again.

---

## #67922 — Tjerk Anne Meesters — 2013-06-27T08:17:01+00:00

URL: https://externals.io/message/67884#67922 · In reply to: #67884

> Hello,
>
> I would like to submit an RFC to add a new function to the PHP language.
> The function would be called "map()". The purpose of this function would be
> to take an existing value within a range and make it to a corresponding
> location within a new range.
>
> The map() method would have 5 required parameters, $originalLow,
> $originalHigh, $newLow, $newHigh, and $value.
>
> map() would be implement the following:
>
> function map($originalLow, $originalHigh, $newLow, $newHigh, $value) {
> return $newLow + ($value - $originalLow) * ($newHigh - $newLow) /
> ($originalHigh- $originalLow);
> }
>
>
Purely from a development perspective, having five required function
arguments is bad; it can be reduced (by treating the first four as two
ranges) to three arguments, e.g.

    map([55, 92], [70, 100], 55);

You can go one step further and call it what it is, not a mapper, but a
single dimensional range transformer and use a closure, e.g.:

    $transformer = get_1d_range_transformer([55, 92], [70, 100]);
    echo $transformer(55); // get transformed value

You might also benefit from an OOP approach. I won't paste it here, but
I've created a pastie for it: http://codepad.org/nGZv8GJa

It's debatable whether this somewhat specialized code would need to be
coded at something other than the language level; in most likelihood you
won't gain any appreciable performance increase.


> Example:
> Let's say we are teachers and are grading final exams. We have a policy
> that the best score is 100, and the worst score is a 70. Students scored
> between 55 and 92. We want to easily re-score the exams to be within the
> new score range, so we would use the new map() function. Let's begin with
> mapping the lowest score:
>
> $newScore = map(55, 92, 70, 100, 55); //$newScore = 70
>
> If we have all of our scores in an array:
>
> $scores = array(71, 65, 55, 85, 88, 86, 92, 77, 73);
>
> We could use a foreach loop to remap each value:
>
> $newScores = array();
> foreach($score as $scores) {
>  $newScores[] = map(55, 92, 70, 100, $score);
> }
> var_dump($newScores);
> /*
> array(9) {
>   [0]=>
>   float(82.972972972973)
>   [1]=>
>   float(78.108108108108)
>   [2]=>
>   int(70)
>   [3]=>
>   float(94.324324324324)
>   [4]=>
>   float(96.756756756757)
>   [5]=>
>   float(95.135135135135)
>   [6]=>
>   int(100)
>   [7]=>
>   float(87.837837837838)
>   [8]=>
>   float(84.594594594595)
>   }
> */
>
> Just like that, we have the new exam grades that fit our policy, within
> the proper scale, without having to do any of the messy math ourselves.
>
> While I do recognize that this is somewhat trivial to anyone who knows the
> proper formula, I feel as though it would serve the PHP community well.
> Much the same as the `pow()` or `pi()` functions do. I appreciate your thoughts
> on this matter and whether or not this is worth pursuing as an RFC.
>
> Thank you,
> Jeremy Curcio
> j.curcio@me.com
>



-- 
--
Tjerk

---

## #67924 — Florin Patan — 2013-06-27T08:27:21+00:00

URL: https://externals.io/message/67884#67924 · In reply to: #67922

> 
>
> > […]
> Purely from a development perspective, having five required function
> arguments is bad; it can be reduced (by treating the first four as two
> ranges) to three arguments, e.g.
>
>     map([55, 92], [70, 100], 55);
>
> You can go one step further and call it what it is, not a mapper, but a
> single dimensional range transformer and use a closure, e.g.:
>
>     $transformer = get_1d_range_transformer([55, 92], [70, 100]);
>     echo $transformer(55); // get transformed value
>
> You might also benefit from an OOP approach. I won't paste it here, but
> I've created a pastie for it: http://codepad.org/nGZv8GJa
>
> It's debatable whether this somewhat specialized code would need to be
> coded at something other than the language level; in most likelihood you
> won't gain any appreciable performance increase.
>
>
> > […]
>
>
>
> --
> --
> Tjerk


Hi,


May I kindly ask why all the PHP users would want this function in the core?
I've never needed such a function nor do I understand why we should
have it. It's good for what?
And as I understand, PHP delegates the math stuff to the underlying C
implementation so why would it be faster having it in PHP core rather
that in PHP userland?


Thanks
----
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

---

## #67929 — Tjerk Anne Meesters — 2013-06-27T09:17:24+00:00

URL: https://externals.io/message/67884#67929 · In reply to: #67924

> On Thu, Jun 27, 2013 at 10:17 AM, Tjerk Anne Meesters <datibbaw@php.net>
> wrote:
> > […]
> wrote:
> > […]
> would be
> > […]
> with
> > […]
> the
> > […]
> thoughts
> > […]
>
>
> Hi,
>
>
> May I kindly ask why all the PHP users would want this function in the
> core?
>

Are you meaning to ask why would *any* php user want this function in the
core? As with most things, the need of one may be shared among a critical
mass that could swing the balance. In practice though, the critical mass is
usually determined by the internals peeps :)


> I've never needed such a function nor do I understand why we should
> have it. It's good for what?
>

It's good to perform affine transformation in a single dimension; if you've
never done this before, you wouldn't need it.


> And as I understand, PHP delegates the math stuff to the underlying C
> implementation so why would it be faster having it in PHP core rather
> that in PHP userland?
>

Performance is not the only reason why features make it into the core; it's
providing a rich set of built-in features to make the developer's lives
easier, such as the latest password hashing API which is easy to get wrong
or generators that reduce boiler plate code. As such, an addition to the
set of numerical functions to address a particular use-case is not
unthinkable.


>
>
> Thanks
> ----
> Florin Patan
> https://github.com/dlsniper
> http://www.linkedin.com/in/florinpatan
>



-- 
--
Tjerk

---

## #67931 — Sebastian Krebs — 2013-06-27T09:43:35+00:00

URL: https://externals.io/message/67884#67931 · In reply to: #67929

2013/6/27 Tjerk Anne Meesters <datibbaw@php.net>

> On Thu, Jun 27, 2013 at 4:27 PM, Florin Patan <florinpatan@gmail.com>
> wrote:
>
> > […]
> language.
> > […]
> corresponding
> > […]
> you
> > […]
> policy
> > […]
> scored
> > […]
> the
> > […]
> within
> > […]
> ourselves.
> > […]
> well.
> > […]
>
> Are you meaning to ask why would *any* php user want this function in the
> core? As with most things, the need of one may be shared among a critical
> mass that could swing the balance. In practice though, the critical mass is
> usually determined by the internals peeps :)
>

But this method is _really_ quite special, isn't it? I cannot imagine, that
there is "critical mass", that needs this _in core_.
Just to remind: It works with pure-PHP too. Also you may provide this as
PECL-extension if performance is important.


>
>
> > […]
>
> It's good to perform affine transformation in a single dimension; if you've
> never done this before, you wouldn't need it.
>
>
> > […]
>
> Performance is not the only reason why features make it into the core; it's
> providing a rich set of built-in features to make the developer's lives
> easier, such as the latest password hashing API which is easy to get wrong
> or generators that reduce boiler plate code.


You cannot compare language features (generators) with functions. And
"security" is always a topic on its own.


> As such, an addition to the
> set of numerical functions to address a particular use-case is not
> unthinkable.
>
>
> > […]
>
>
>
> --
> --
> Tjerk
>



-- 
github.com/KingCrunch

---

## #67933 — Tjerk Anne Meesters — 2013-06-27T10:24:16+00:00

URL: https://externals.io/message/67884#67933 · In reply to: #67931

On Thu, Jun 27, 2013 at 5:43 PM, Sebastian Krebs <krebs.seb@gmail.com>wrote:

>
>
>
> 2013/6/27 Tjerk Anne Meesters <datibbaw@php.net>
>
> > […]
>
> But this method is _really_ quite special, isn't it? I cannot imagine,
> that there is "critical mass", that needs this _in core_.
>

I'm not casting any judgement on its usefulness; I'm merely arguing the
"why should this be in core? I would never use it." narrative is not
constructive.


> Just to remind: It works with pure-PHP too. Also you may provide this as
> PECL-extension if performance is important.
>

Yes, that's always an option.


>
>
> > […]
>
>
> You cannot compare language features (generators) with functions. And
> "security" is always a topic on its own.
>

I consider new functions as a feature of the language as well, so there's
no need to make comparisons.

That said, would you have guessed (without looking at the manual) that PHP
exposes a "hypot($x, $y)" where you could otherwise have written "sqrt($x *
$x, $y * $y)"?

Okay, it's a translation from <math.h> of course, but it came as a surprise
to me :)


>
>
> > […]
>
>
>
> --
> github.com/KingCrunch
>



-- 
--
Tjerk

---

## #67938 — Richard Bradley — 2013-06-27T11:13:38+00:00

URL: https://externals.io/message/67884#67938 · In reply to: #67933

> -----Original Message-----
> From: tjerk.meesters@gmail.com [mailto:tjerk.meesters@gmail.com] On Behalf Of Tjerk Anne Meesters
> Sent: 27 June 2013 11:24
> To: Sebastian Krebs
> Cc: Florin Patan; Jeremy Curcio; PHP Internals
> Subject: Re: [PHP-DEV] Gauging Interest:RFC to add map() function
>
> On Thu, Jun 27, 2013 at 5:43 PM, Sebastian Krebs <krebs.seb@gmail.com>wrote:
>
> > […]
>
> I'm not casting any judgement on its usefulness; I'm merely arguing the
> "why should this be in core? I would never use it." narrative is not constructive.

It can serve as an indication of which way the he would vote if this came to RFC.
It can give a single data point towards how many people would find this useful.
You did ask what people thought of the proposed method. I don't think you should simply reject negative answers as "not constructive".

> > […]
>
> I consider new functions as a feature of the language as well, so there's no need to make comparisons.
>
> That said, would you have guessed (without looking at the manual) that PHP exposes a
> "hypot($x, $y)" where you could otherwise have written "sqrt($x * $x, $y * $y)"?
>
> Okay, it's a translation from <math.h> of course, but it came as a surprise to me :)

There is a good reason to have "hypot" in the C layer -- it is not possible to implement it in PHP correctly (and efficiently), due to overflow concerns.

See http://en.wikipedia.org/wiki/Hypot for a summary.

The same concerns do not apply to this affine transform, which is why it should not be in core.

If there were sufficient demand for it, then it might justify a PECL extension. My impression is that there is not.

Best,



Rich



Richard Bradley
Tel : 020 7485 7500 ext 3230 | Fax : 020 7485 7575

softwire
Sunday Times Best Small Companies - UK top 20 three years running
Web : www.softwire.com | Addr : 325 Highgate Studios, 53-79 Highgate Road, London NW5 1TL
Softwire Technology Limited. Registered in England no. 3824658. Registered Office : 13 Station Road, London N3 2SB

---

## #67943 — Tjerk Anne Meesters — 2013-06-27T12:52:11+00:00

URL: https://externals.io/message/67884#67943 · In reply to: #67938

On Thu, Jun 27, 2013 at 7:13 PM, Richard Bradley <
Richard.Bradley@softwire.com> wrote:

> > […]
> Behalf Of Tjerk Anne Meesters
> > […]
> constructive.
>
> It can serve as an indication of which way the he would vote if this came
> to RFC.
> It can give a single data point towards how many people would find this
> useful.
> You did ask what people thought of the proposed method. I don't think you
> should simply reject negative answers as "not constructive".
>

To be clear, I'm not the person who proposed the patch, so I'm not the one
asking for opinions; I'm merely an engaged bystander if you will.

That said, "providing a single data point" which loosely translates to a
thumbs up or down and being non-constructive are not mutually exclusive
terms; the constructive element here refers to the value it adds to the
discussion. In other words, saying "Boo! -1" serves as a statistic, but a
good argument benefits the proposer most imo.


>
> > […]
> there's no need to make comparisons.
> > […]
> PHP exposes a
> > […]
> * $y)"?
> > […]
> surprise to me :)
>
> There is a good reason to have "hypot" in the C layer -- it is not
> possible to implement it in PHP correctly (and efficiently), due to
> overflow concerns.
>
> See http://en.wikipedia.org/wiki/Hypot for a summary.
>
>
This wasn't meant to be taken at face value; it was part of the argument
that some functions may not seem useful at first glance. I'm of course not
arguing that `hypot()` is simply added fluff, that's pretty clear from
referencing the man(ual) page, though for the fun of it you should search
for this function on stackoverflow to gauge how often it's used.

The same concerns do not apply to this affine transform, which is why it
> should not be in core.
>

Whether a C implementation is a hard requirement could be used as a
deciding factor, yes, but otherwise I wholeheartedly disagree with that
statement :) there are enough functions in the core that could be correctly
and in some cases also efficiently be implemented in userland.


>
> If there were sufficient demand for it, then it might justify a PECL
> extension. My impression is that there is not.
>

Indeed. Perhaps an extension dedicated to working with range operations in
general may be a useful addition. It would definitely be a good learning
experience, assuming said proposer would take up this job himself :)


>
> Best,
>
>
>
> Rich
>
>
>
> Richard Bradley
> Tel : 020 7485 7500 ext 3230 | Fax : 020 7485 7575
>
> softwire
> Sunday Times Best Small Companies - UK top 20 three years running
> Web : www.softwire.com | Addr : 325 Highgate Studios, 53-79 Highgate
> Road, London NW5 1TL
> Softwire Technology Limited. Registered in England no. 3824658. Registered
> Office : 13 Station Road, London N3 2SB
>
>


-- 
--
Tjerk