On Friday, 15 January 2016 17:14:26 UTC-6, Yichao Yu wrote:
>
> FYI, don't call eval in functions
>
What's wrong with calling eval in functions when you're evaluating
expressions without side-effects?
On Mon, Jan 18, 2016 at 10:42 AM, Eric Davies wrote:
>
>
> On Friday, 15 January 2016 17:14:26 UTC-6, Yichao Yu wrote:
>>
>> FYI, don't call eval in functions
>
>
> What's wrong with calling eval in functions when you're evaluating
> expressions without side-effects?
Orders of
It's gone now
:) https://github.com/invenia/VirtualArrays.jl/pull/2#event-518201512
On Monday, 18 January 2016 09:47:15 UTC-6, Yichao Yu wrote:
>
> On Mon, Jan 18, 2016 at 10:42 AM, Eric Davies > wrote:
> >
> >
> > On Friday, 15 January 2016 17:14:26 UTC-6, Yichao Yu
Thanks for the Twine pointer, it was interesting.
I wasn't thinking so much about CPU efficiency, but more so scaling code.
There's a potential N² problem with lazy data structures, because binary
operation should ideally be defined for all combinations of them to reap
full benefits. Another
There's probably a threshold: Below, it's cheaper to copy, and above,
it's cheaper to re-use the existing arrays. LLVM goes to great length
to optimize string operations in this respect, with their own string
class ("Twine"). Obviously what works for strings can be extended to
work with any kind
That's cool, a lazy vcat!
I wrote a similar class that's a lazy `fill`, and it worked really well for
my purposes. I wonder what the endgame will be for these datastructures.
0.5 will bring us "lazy slicing". Should everything be lazy by default?
Does it scale?
On Friday, January 15, 2016 at
A way to concatenate arrays without copying values.
https://github.com/invenia/VirtualArrays.jl
On Fri, Jan 15, 2016 at 5:51 PM, Samuel Massinon
wrote:
> A way to concatenate arrays without copying values.
>
> https://github.com/invenia/VirtualArrays.jl
FYI, don't call eval in functions