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
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 thepow()
orpi()
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
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.
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 thepow()
orpi()
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
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/nGZv8GJaIt'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 thepow()
orpi()
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
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
On Thu, Jun 27, 2013 at 10:17 AM, Tjerk Anne Meesters datibbaw@php.net
wrote:On Wed, Jun 26, 2013 at 11:20 PM, Jeremy Curcio j.curcio@icloud.com
wrote: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/nGZv8GJaIt'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 thepow()
orpi()
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
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
2013/6/27 Tjerk Anne Meesters datibbaw@php.net
On Thu, Jun 27, 2013 at 4:27 PM, Florin Patan florinpatan@gmail.com
wrote:On Thu, Jun 27, 2013 at 10:17 AM, Tjerk Anne Meesters datibbaw@php.net
wrote:On Wed, Jun 26, 2013 at 11:20 PM, Jeremy Curcio j.curcio@icloud.com
wrote: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/nGZv8GJaIt'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 thepow()
orpi()
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
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 :)
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.
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.
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.Thanks
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan--
Tjerk
On Thu, Jun 27, 2013 at 5:43 PM, Sebastian Krebs krebs.seb@gmail.comwrote:
2013/6/27 Tjerk Anne Meesters datibbaw@php.net
On Thu, Jun 27, 2013 at 4:27 PM, Florin Patan florinpatan@gmail.com
wrote:On Thu, Jun 27, 2013 at 10:17 AM, Tjerk Anne Meesters <datibbaw@php.net
wrote:
On Wed, Jun 26, 2013 at 11:20 PM, Jeremy Curcio j.curcio@icloud.com
wrote: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/nGZv8GJaIt'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 thepow()
orpi()
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
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 :)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.
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.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 :)
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
--
Tjerk
-----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() functionOn Thu, Jun 27, 2013 at 5:43 PM, Sebastian Krebs krebs.seb@gmail.comwrote:
2013/6/27 Tjerk Anne Meesters datibbaw@php.net
On Thu, Jun 27, 2013 at 4:27 PM, Florin Patan florinpatan@gmail.com
wrote:On Thu, Jun 27, 2013 at 10:17 AM, Tjerk Anne Meesters
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 :)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.
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".
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.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 :)
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
On Thu, Jun 27, 2013 at 7:13 PM, Richard Bradley <
Richard.Bradley@softwire.com> wrote:
-----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() functionOn Thu, Jun 27, 2013 at 5:43 PM, Sebastian Krebs <krebs.seb@gmail.com
wrote:2013/6/27 Tjerk Anne Meesters datibbaw@php.net
On Thu, Jun 27, 2013 at 4:27 PM, Florin Patan florinpatan@gmail.com
wrote:On Thu, Jun 27, 2013 at 10:17 AM, Tjerk Anne Meesters
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 :)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.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.
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.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 :)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 7575softwire
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