On Monday, August 31, 2015 at 11:50:31 AM UTC-4, Tim Holy wrote:
>
> It makes sense when you can't predict in advance what metadata people will
> want to store. I wrestled a lot at the beginning with trying to come up
> with
> "universal names," but somehow it seemed that a field named "patient_ID"
> is
> unlikely to be of interest to astronomers :-). (Or me, for that matter.)
>
It's interesting how the lack of inheritance drives other solutions! I
didn't realize that .property was for storing generic user data. My first
reaction would be to create a Patient type, which includes an Image object.
The thing about image processing is that it rarely suffers from a
> bottleneck in
> handling the metadata; all you really need is fast access to the pixels.
> So
> this is a fairly specific solution for Images. Like you, I use types with
> fields
> in most other cases.
>
For memoization, what you suggested is a good strategy. If a call is costly
enough to deserve caching its output, then a dictionary look-up is unlikely
to be a bottle-neck
Cédric
>
> --Tim
>
> On Monday, August 31, 2015 08:44:45 AM Cedric St-Jean wrote:
> > Hi Tim, thanks for the answer. I wasn't talking about Image
> specifically,
> > but that's an interesting way to flexibly store all the memos. Is that
> your
> > general go-to solution, have a properties dictionary inside each object?
> It
> > feels more like a Python solution than Julia, but it makes a lot of
> sense
> > for medium-to-large objects.
> >
> > On Monday, August 31, 2015 at 4:34:38 AM UTC-4, Tim Holy wrote:
> > > Re Image (assuming you mean the Image from Images.jl), you can just
> add a
> > > "hash" property---no recreation/redesign needed. Wouldn't necessarily
> have
> > > to
> > > be a nullable, either. For efficiency, Images implements a `@get`
> macro,
> > > so
> > >
> > > @get img "hash" hashfunc(img)
> > >
> > > would:
> > > - extract the stored "hash" property, if it already exists, without
> > > computing
> > > hashfunc(img)
> > > - compute and create the "hash" property, if it doesn't exist
> > >
> > > --Tim
> > >
> > > On Sunday, August 30, 2015 10:04:26 PM Cedric St-Jean wrote:
> > > > I tend to use memoization heavily in my mostly-functional code.
> > >
> > > Memoize.jl
> > >
> > > > is neat, but it doesn't use a WeakKeyDict.
> > > >
> > > > 1. Is there any specific reason for that? Won't that code just hog
> the
> > > > objects forever?
> > > >
> > > > 2. In SBCL, weak dictionaries and weak references had terrible O(N²)
> > > > performance (I could never understand why), is that also the case
> for
> > >
> > > Julia?
> > >
> > > > 3. In many cases, it makes more sense to store the memoized value
> inside
> > > > the object's field (for instance, storing the hash for an image).
> That
> > >
> > > will
> > >
> > > > be a good place to use Nullable, right?
> > > >
> > > > # Obviously I don't mean to recreate Image specifically
> > > > type Image
> > > >
> > > > ...
> > > > hash_value::Nullable{int}
> > > >
> > > > end
> > > >
> > > > function hash(img::Image)
> > > >
> > > > if isnull(img.hash_value)
> > > >
> > > > return img.hash_value = ...
> > > >
> > > > else
> > > >
> > > > return get(img.hash_value)
> > > >
> > > > end
> > > >
> > > > end
> > > >
> > > > 4. I still don't have the hang of Julia macros. In Common Lisp, I
> could
> > > > easily write my own
> > > > (defstruct* Image
> > > >
> > > > ... normal fields
> > > > (cache hash))
> > > >
> > > > and have the above code automatically generated. What's the best
> syntax
> > >
> > > to
> > >
> > > > use with Julia? Something like
> > > > @type_cached Image begin
> > > >
> > > > ...
> > > > cache(hash)
> > > >
> > > > end
> > > >
> > > > function hash_impl(img::Imaeg)
> > > >
> > > > ...
> > > >
> > > > end
> > > > ? I don't like much how the `begin` makes it stick out, whereas
> Common
> > > > Lisp's version is much more seamless. Isn't there a way to tell the
> > >
> > > parser
> > >
> > > > "keep reading this macro until `end`" without having a begin
> statement?
> > > >
> > > > Is there a better, more native solution to this problem?
> > > >
> > > > Cédric
>
>
