Displaying 7 results from an estimated 7 matches for "behavaior".
Did you mean:
beavior
2019 Oct 05
5
should base R have a piping operator ?
Yes but this exageration precisely misses the point.
Concerning your examples:
* I love fread but I think it makes a lot of subjective choices that are
best associated with a package. I think it
changed a lot with time and can still change, and we have great developers
willing to maintain it and be reactive
regarding feature requests or bug reports
*.group_by() adds a class that works only (or
2019 Oct 06
1
should base R have a piping operator ?
...o
>
> local({
> . = group_by(iris, Species)
>
> ._tmp2 = summarize(., mean_sl = mean(Sepal.Length))
>
> filter(., mean_sl > 5)
> })
>
>
>
>
> Then debuggiing (once you knew that) would be much easier but behavaior
> would be the same as it is now. There could even be some sort of
> step-through-pipe debugger at that point added as well for additional
> convenience.
>
> There is some minor precedent for that type of transformative parsing:
>
>> expr = parse(text = "5 -> x&quo...
2019 Oct 07
4
should base R have a piping operator ?
...ple, into
>
> local({
> . = group_by(iris, Species)
>
> ._tmp2 = summarize(., mean_sl = mean(Sepal.Length))
>
> filter(., mean_sl > 5)
> })
>
>
>
>
> Then debuggiing (once you knew that) would be much easier but behavaior
> would be the same as it is now. There could even be some sort of
> step-through-pipe debugger at that point added as well for additional
> convenience.
>
> There is some minor precedent for that type of transformative parsing:
>
>> expr = parse(text = "5 -> x&quo...
2019 Oct 05
0
should base R have a piping operator ?
...)) %>%
filter(mean_sl > 5)
were *parsed* as, for example, into
local({
. = group_by(iris, Species)
._tmp2 = summarize(., mean_sl = mean(Sepal.Length))
filter(., mean_sl > 5)
})
Then debuggiing (once you knew that) would be much easier but behavaior
would be the same as it is now. There could even be some sort of
step-through-pipe debugger at that point added as well for additional
convenience.
There is some minor precedent for that type of transformative parsing:
> expr = parse(text = "5 -> x")
> expr
expression(5 ->...
2019 Oct 07
0
should base R have a piping operator ?
.... = group_by(iris, Species)
>>
>> ._tmp2 = summarize(., mean_sl = mean(Sepal.Length))
>>
>> filter(., mean_sl > 5)
>> })
>>
>>
>>
>>
>> Then debuggiing (once you knew that) would be much easier but behavaior
>> would be the same as it is now. There could even be some sort of
>> step-through-pipe debugger at that point added as well for additional
>> convenience.
>>
>> There is some minor precedent for that type of transformative parsing:
>>
>>> expr = parse(...
2019 Oct 06
1
should base R have a piping operator ?
...xample, into
>
> local({
> . = group_by(iris, Species)
>
> ._tmp2 = summarize(., mean_sl = mean(Sepal.Length))
>
> filter(., mean_sl > 5)
> })
>
>
>
>
> Then debuggiing (once you knew that) would be much easier but behavaior
> would be the same as it is now. There could even be some sort of
> step-through-pipe debugger at that point added as well for additional
> convenience.
>
> There is some minor precedent for that type of transformative parsing:
>
> > expr = parse(text = "5 -> x"...
2019 Oct 07
0
[External] Re: should base R have a piping operator ?
.... = group_by(iris, Species)
>>
>> ._tmp2 = summarize(., mean_sl = mean(Sepal.Length))
>>
>> filter(., mean_sl > 5)
>> })
>>
>>
>>
>>
>> Then debuggiing (once you knew that) would be much easier but behavaior
>> would be the same as it is now. There could even be some sort of
>> step-through-pipe debugger at that point added as well for additional
>> convenience.
>>
>> There is some minor precedent for that type of transformative parsing:
>>
>>> expr = parse(...