Re: Gauging Interest:RFC to add map() function

From: Date: Thu, 27 Jun 2013 10:24:16 +0000
Subject: Re: Gauging Interest:RFC to add map() function
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Thu, Jun 27, 2013 at 5:43 PM, Sebastian Krebs <[email protected]>wrote:

>
>
>
> 2013/6/27 Tjerk Anne Meesters <[email protected]>
>
>> On Thu, Jun 27, 2013 at 4:27 PM, Florin Patan <[email protected]>
>> wrote:
>>
>> > On Thu, Jun 27, 2013 at 10:17 AM, Tjerk Anne Meesters <[email protected]
>> >
>> > wrote:
>> > > On Wed, Jun 26, 2013 at 11:20 PM, Jeremy Curcio <[email protected]>
>> > 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/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
>> > >> [email protected]
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > --
>> > > 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
>>
>
>
>
> --
> github.com/KingCrunch
>



-- 
--
Tjerk


Thread (15 messages)

« previous php.internals (#67933) next »