I don't think that dataflow works quite right in my case because, if I
understood Mr. Straszheim's posts correctly then dataflows can't have
cycles and I have cycles all over the place. Unfortunately this isn't
visible in the example I gave because I used Sell which doesn't have
cycles. Rent on the
but complexity of such expressions quickly grows as dependencies
between variables become more complex. Is there any
technique/framework for handling such calculations automatically? I
have a vague impression that this is what logic programming languages
are about. How would one implement such cal
Hi,
On Mar 1, 2010, at 5:19 AM, Andrzej wrote:
What to do if we don't know which of the equation variables are
unknowns? Let's say that the user may choose whether to input "Rent"
and "Sell", or "Rent" and "opportunityCost". I can imagine writing
some code like this:
(defn opportunity-cost [o
I'd like to note that if you do this, you might just as well use the -
function directly.
Of course; this was merely for the sake of illustration.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegro
On Thu, Feb 18, 2010 at 3:36 PM, Richard Newman wrote:
> You express the equations as functions. Turning your equation notation into
> function notation -- I'll use Haskell's as an example:
>
> OpportunityCost = Rent - Sell
>
> becomes
>
> opportunityCost r s = r - s
>
> or in Clojur
On Mar 1, 9:55 am, Richard Newman wrote:
> (defn house-sale-profit
> [house-sales-price house-sale-expenses]
> (- house-sales-price house-sale-expenses))
I'd like to note that if you do this, you might just as well use the -
function directly. It's not as flexible if the profit ca
2010/2/20 Yaron
>
> > Looks pretty good to me. I like your use of preconditions and the
> > number of tests. I think your indentation is a little deep (I go for
> > two spaces, myself), and I never use :Capital keywords, but otherwise
> > great.
> >
> The indentation was just what the Clojure plu
So I rewrote the whole kit and kaboodle. My understanding of your mail
led me to take the approach of defining functions who take as
arguments the invariant values and who output functions that take
variant values. For example:
I'm not sure how much functional programming experience you have, bu
Richard, I spent quite a bit of time thinking about what you said.
So I rewrote the whole kit and kaboodle. My understanding of your mail
led me to take the approach of defining functions who take as
arguments the invariant values and who output functions that take
variant values. For example:
(d
I have to think that's preferable to submitting 30+ arguments to rent
and sell.
Or were you suggesting a different approach?
The different approach only works with a different approach :)
The way you've structured run-calculator, using the map is best,
because 30 arguments is crazy.
Your n
> Looks pretty good to me. I like your use of preconditions and the
> number of tests. I think your indentation is a little deep (I go for
> two spaces, myself), and I never use :Capital keywords, but otherwise
> great.
>
The indentation was just what the Clojure plugin for Eclipse was set
t
Right, nesting everything inside a single function makes it impossible to
unit test the inner functions--they don't even have names in the global
scope! In retrospect, I think the solution I posted is more cute than it is
practical. Passing around a map of intermediate values seems to be the
winn
With this approach how would I test the individual functions defined
inside of the let? Wouldn't they be invisible to me and the test
framework which would only see "sell-or-rent"?
On Feb 18, 4:27 pm, John Williams wrote:
> I'm no Clojure guru myself, but one approach you may want to consider is
Richard Newman has with utmost patience (THANK YOU!), I believe,
been trying to gently beat into my head from the start.
No problem. Happy to help.
Richard, your mails were extremely clear (and at this point I've read
them all at least 2 or 3 times) but my head was so far away from the
pr
I spent a bunch of time reading and re-reading your mails.
Michal Marczyk's mail (which I read every line of, thank you for
taking the time to write it) was the one that made me get what
Richard Newman has with utmost patience (THANK YOU!), I believe,
been trying to gently beat into my head fr
Way back when I was a wee lad I had been taught that a thunk is any
function that takes no arguments. My definition for my derived values
never took any arguments because they exclusively relied on global
variables.
For example:
(defn months_actively_renting
"The number of months during t
I'm no Clojure guru myself, but one approach you may want to consider is
nest all your auxiliary functions inside the main function, and use ordinary
let-bindings the same way you've been trying to use global bindings:
(defn sell-or-rent [{:keys [supplied-1 supplied-2]}]
(let [derived-1 (+ 1 sup
I don't expect anyone to actually read, rather I was hoping some folks
who know Clojure might just glance at it to get the rhythm of the
math. It's the pattern, not the detail that matters. How should what
is essentially a monster algebra equation be codified in Clojure?
I looked at your PDF.
Y
Absolutely. I typed up an example in Scala.
class RentOrSell(val Months_To_Find_Tenant: Int, val Months_In_Lease:
Int, val Lease_Cycles: Int, val Months_To_Sell: Int) {
val months_in_business: Int = ((Months_To_Find_Tenant +
Months_In_Lease) * Lease_Cycles) + Months_To_Sell
}
When I create a cl
I'm just trying to figure out what the right pattern is
because the fact that I'm forced to make the derived values into
thunks feels really wrong but I honestly don't know what's right in
the context of Clojure.
I don't think you're using the term "thunk" correctly.
A thunk is (usually) a no-a
That's actually quite a nifty use of the fact that code/data is the
same in Clojure. But how do I test things out? In other words, how do
I make sure that the expression defining a# is correct? Especially
when any test has to itself be in the context of all the variables?
But more to the point I t
The reason for typing so much is maintainability. I'll have to come
back to this code again and again over a period of years and there's
no chance in heck I'll remember anything I did before. So I've learned
that using clearer variable names, even with a little extra typing, is
a price worth paying
I think I see what you're saying. But honestly my goal isn't to
replicate the OO experience. My goal is to replicate how easy OO made
this specific scenario. In other words I want to use Clojure properly
and trying to paste an OO framework on Clojure has got to be a major
anti-pattern. I'm just try
I must say that I find Richard's suggestions to be very reasonable,
but I'd like to add my own take... This is meant as a step-by-step
account of my thinking process, so it starts out with a statement of
the basics. Skim & skip if you prefer.
The problem to be solved is basically a huge calculatio
Hello,
2010/2/17 Yaron :
> I actually started off doing exactly what you suggested. The original
> version of my program used a map for the arguments and then used
> explicit arguments when the number of arguments fell to a reasonable
> level.
>
> For example, I started off with:
>
> (defn months_
(defn months_in_business
"The total number of months we will be in the business of renting out
our home"
[:keys [Months_To_Find_Tenant Months_In_Lease Lease_Cycles
Months_To_Sell]]
(-> (+ Months_To_Find_Tenant Months_In_Lease) (* Lease_Cycles) (+
Months_To_Sell)))
->
I have n
You can combine let and binding like this to make this slightly more
elegant:
(let [a# 'expr involving *A* *B* and *C*''
b# 'expr involving *A* *B* and *C*''
c# 'expr involving *A* *B* and *C*'']
(binding [*A* a#
*B* b#
*C* c#]
...))
Note the x# fo
I think it will help you get used to Clojure by spending some time to
"program in the most straight-forward way possible".
Sometimes it's really helpful to just learn from a blank-slate instead
of trying to find analogies to Java.
-Patrick
--
You received this message because you are subscri
Hi Yaron,
You've slightly misunderstood my suggestion. I hope this will shed
some reasoning on it:
In OO, what you are effectively doing is this:
The Object represents the "environment" under which you do your
calculations.
The "environment" object is created by your constructor.
Once this "envi
I actually started off doing exactly what you suggested. The original
version of my program used a map for the arguments and then used
explicit arguments when the number of arguments fell to a reasonable
level.
For example, I started off with:
(defn months_in_business
"The total number of
I actually started off doing exactly what you suggested. The original
version of my program used a map for the arguments and then used
explicit arguments when the number of arguments fell to a reasonable
level.
For example, I started off with:
(defn months_in_business
"The total number of
I did but it requires two levels of macro and that made me nervous.
The problem is derived values. When defining a binding, near as I can
tell, the values in the binding cannot see other values in the
binding. In other words:
(def *A* 10)
(binding [*A* 3 B (+ foo 1)] B)
Returns 11, not 4.
So to
Hi Yaron,
Have you considered my example yet? It seems to fulfill your
requirements. One of the primary use-cases of (binding) is to avoid
bloating the parameter list of a group of functions.
If my example does not satisfy your needs, then I think we may have
all misunderstood what it is you're lo
It seems however that the consensus of the group based on what I've
said so far is to pass around state in a structmap.
Not necessarily a struct-map. Just a map.
This is nice in
that it makes each function completely self contained (e.g. no
external references). It's unfortunate in that it now
I have posted a file (http://www.goland.org/sellorrent.pdf) which
explains the math behind the calculator. The file gives all the
algebra needed to implement the calculator. At the moment I'm just
taking the boneheaded approach and implementing all the logic in
Clojure as more or less a one to one
For the method tax_deductible_expenses to run it ends up requiring 19
user defined values. That's a whole lot of arguments to pass into a
function. Obviously I could wrap them up in a StructMap but then I get
expressions like (+ 1 (args :B)) which doesn't seem much better than
(+1 (B)).
Pass
What do you think of the following style?
(defmacro in-environment [env & body]
`(binding [*months-to-find-tenant* (:months-to-find-tenant env)
*months-in-lease* (:months-in-lease env)
*lease-cycles* (:lease-cycles env)
etc...]
~...@body))
So "env" is
On Feb 16, 8:27 pm, Yaron wrote:
> Sean and Richard perhaps I can address both of your mails in a single
> go. Here is an example of one of the functions from my calculator:
>
> (defn tax_deductible_expenses
> "The total expenses incurred in business month m that are deductible
> from fe
Sean and Richard perhaps I can address both of your mails in a single
go. Here is an example of one of the functions from my calculator:
(defn tax_deductible_expenses
"The total expenses incurred in business month m that are deductible
from federal income tax"
[m]
(let
So imagine the user submits a value A. I will have a value B whose
definition will be something like (+ 1 A) (yes, more complex in
reality, but you get the idea).
In Java, everything's an object, so you go about this by defining some
class. All of its private members, its constructors, and it
Let's start with what you've got. Could you post some of your code on
github, or something similar? That would make it easier to help you
along.
Sean
On Feb 15, 12:24 pm, Yaron wrote:
> I am writing a calculator to figure out if I should sell or rent my
> home using Clojure. This is my first C
I am writing a calculator to figure out if I should sell or rent my
home using Clojure. This is my first Clojure program so I'm about as
wet behind the ears as it gets. So far everything is actually going
really well (reminds me of the fun I had with Scheme in college) but
for one thing. My calcula
42 matches
Mail list logo
