There is in the PharoGoodies site, b

Sudhakar krishnamachari

Extn 91-40403012
Cell 9902104814



On Jul 7, 2012, at 12:39 AM, "[email protected]" <[email protected]> wrote:

> I like the way you show the code. Is there a configuration for trying that 
> out ?
> 
> Phil
> 
> 2012/7/6 S Krish <[email protected]>
> This is a little old, I have not been able to devote the time reqd to really 
> bring this to usable state. But I am pushing now through weekends to get it 
> out..
> 
> The MorphicView:
> 
> https://plus.google.com/photos/101656219013170129431/albums/5721907895325589393?banner=pwa
> 
> * Trying to upgrade the wizard UI Generator, make it capable of remoting , 
> work with DB based modelling and has a lot of other stuff of usual enterprise 
> apps: localization, singleton/ factory creator, configuration file , logger 
> integrated...
> 
> Will need a more active few weeks to run these through to usable state.. 
> 
> The PharoTabletIDE:
> 
> https://plus.google.com/photos/101656219013170129431/albums/5717749739476813505?banner=pwa
> 
> More like a Ubuntu Unity attempt on Pharo..but that is runnable on a tiny 
> core linux with 128 MB RAM.
> 
> Again as above need to devote few actively concentrated weeks on this.. which 
> has been tough to spare last few months..
> 
> 
> On Fri, Jul 6, 2012 at 5:53 PM, [email protected] <[email protected]> wrote:
> What's that PharoTabletIDE thing?
> 
> I am doing some work with Pharo on iOS. Is it the platform you use?
> 
> Phil
> 
> 
> 2012/7/6 S Krish <[email protected]>
> You should read as much as you can about Kapital of JPMC. It does more or 
> less what you describe for esoteric Prime Interest Derivatives and very 
> scalably .. 
> 
> I doubt if there is much in the public domain, but the fact that Kapital is 
> the golden standard in this product line talks highly of why Smalltalk is THE 
> platform for this kind of product. 
> 
> It would be nice to have a Pharo based derivative product that can easily 
> beat Ruby/ Java / .Net at this dynamic visualization using standard browsers, 
> where Nautilus too can serve your purpose.. or a home grown tree based 
> browser.../ Grids..
> 
> Once I have completed my run at a PharoTabletIDE/ PharoMorphicView framework, 
> I would love to collaborate on your endeavour to see if it can be modelled on 
> it and exposed..
> 
> 
> 
> On Fri, Jul 6, 2012 at 4:08 PM, Patrik Sundberg <[email protected]> 
> wrote:
> Hi,
> 
> First of all, sorry for the long email as my first email to the list.
> Hopefully some people will find it an interesting discussion :)
> 
> I'm a long time programmer that has been studying smalltalk and pharo over
> the last year. It's a beautiful language I'm liking the image style of
> development a whole lot. I've been looking for a good test case to try out
> in pharo and I've got something in mind. I've used ruby since around 2000
> and given how much it has been inspired by smalltalk it's not a big leap.
> 
> My real job is being a commodities trader but I build my own tools and
> something I'm always working on is improved risk and pricing tools. Lots of
> that comes down to 2 things:
> 1. evaluating a "function" (in a general sense) with inputs that are picked
> depending on time. e.g. I want to price a security and I want to pick up
> prices for time X as inputs to the pricing model.
> 2. calculating a derivative of the "function" above with respect to inputs
> 
> What I tend to do in order to keep things consistent by design, plus add
> natural caching, is create a calculation graph. I define all the
> dependencies and create an in-memory graph where each node is unique using
> an identity map. I then perform a calculation where the calculations trickle
> down the graph starting from the node I'm interested in down all it's
> dependencies. To calculate the derivative I then find the node representing
> the input I want the derivative with respect to and use finite differences,
> e.g. move it's value, and recalculate the top level node. On the second
> valuation of the graph only the parts that are affected by me changing that
> 1 value will need to be evaluated, the rest is cached an unaffected. It
> makes it very easy to ask questions like "How much will I be affected by X
> changing by Y?" since I can take the top level node of the graph, search for
> X, and if found change it by Y and recalculate.
> 
> How the graph is constructed in memory depends on time (and a few other
> things). I always store all previous states of the world so that I can
> recreate any calculation I did in the past. Very useful for diagnosing
> problem. Hence if I for example change what model I use to model something,
> that change is recorded in a way such that if I set my "time" to before the
> change happened the graph will get created as it would have with the old
> model, and for a time after the change it'll create a different graph
> reflecting the new model. Hence the graph can only be known at runtime when
> the "time" etc is known.
> 
> I currently have a ruby mockup of this. It's a DSL that looks like this:
> 
> ----------- EXAMPLE
> 
> class ExampleObject
>   include GraphEntity # includes a module with functionality for objects
> participating in the graph, including #property and #calc used below
> 
>   property :foo do
>     123 # this is the default value for this property which will be used
> before a value has been set and saved
>   end
> 
>   calc :bar do |arg|
>     foo.value + arg     # take the value of the arg property and add the
> argument given to the calculation node
>   end
> end
> 
> o = ExampleObject.new
> # this will kick of the graph being built in memory and setup the dependency
> between bar and foo nodes
> o.bar(1).value  # -> 124
> # this will be a "cache lookup" since nothing in the graph that bar depends
> on has changed (i.e. the "expensive" calculation is not performed again
> o.bar(1).value  # -> 124
> 
> o.foo.set_value(2)
> o.bar(1).value  # -> 125, realizes that foo changed and performs a recalc
> --------------------------------------------------------
> 
> To accomplish this I use dynamic code generation like the below for
> #property and similar for other types of nodes:
> 
>         # NOTE: it's a class level method, hence how I can call it when
> defining the class in the example
> 
>         def property(name, time = CdrEnv.instance.time, &block)
>           clear_property(name)
>           getter_method_body = <<-EOF
>             def #{name}
>               init_block = self.class.property_init_block_for(:#{name})
>               time_for_property =
> self.class.property_time_dependency_for(:#{name})
>               if init_block.nil?
>                 CdrEnv.instance.get_property_node(self, :#{name},
> time_for_property)
>               else
>                 CdrEnv.instance.get_property_node(self, :#{name},
> time_for_property, &init_block)
>               end
>             end
>           EOF
>           setter_method_body = <<-EOF
>             def #{name.to_s}=(value)
>               #{name.to_s}.mutate(value)
>             end
>           EOF
>           class_eval getter_method_body
>           class_eval setter_method_body
>           register_property_node(name, time, &block)
>         end
> 
> Don't worry about the details or all the unfamiliar ruby, the main point is
> that it creates an instance method that uses the singleton CdrEnv.instance
> to either get or create the node representing the property from the graph
> identity cache depending on if it exists or not.
> 
> From a tooling point of view I think I'd love to work with this kind of
> thing in pharo. Building my own browsers for inspecting and debugging my
> dynamic graph should be very good fit. However, I'd appreciate some pointers
> to idiomatic smalltalk to attack this kind of problem in terms of
> implementing the graph itself - I obviously want the user (even if it's me)
> to just have to focus on the domain model and hide as much as possible of
> the graph bits under the covers the same way I've done with the code
> generation stuff in my ruby example.
> 
> Any input into this would be much appreciated,
> Patrik
> 
> P.S.
> Btw, the persistence backend for this is the neo4j graph database, but it's
> fronted by a service slotting into my own service framework built using
> ZeroMQ and services exchanging messages in protobuf format. One can use it
> from any language as long as one can send protobuf messages over zeromq. I
> see there's a zeromq ffi library available on SS that I'll check out, but
> I'm not finding a protobuf implementation. It'd be easy enough for me to
> port a ruby protobuf implementation but I may as well ask if someone has
> already done any work on protobuf for smalltalk?
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Dynamic-graph-exploration-seeking-input-on-idiomatic-smalltalk-LONG-tp4638702.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 
> 
> 
> 
> 
> -- 
> Philippe Back
> Dramatic Performance Improvements
> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: [email protected] | 
> Web: http://philippeback.eu | Blog: http://philippeback.be
> 
> High Octane SPRL
> rue cour Boisacq 101
> 1301 Bierges
> Belgium
> 
> 
> 
> 
> -- 
> Philippe Back
> Dramatic Performance Improvements
> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: [email protected] | 
> Web: http://philippeback.eu | Blog: http://philippeback.be
> 
> High Octane SPRL
> rue cour Boisacq 101
> 1301 Bierges
> Belgium

Reply via email to