Passing a fun that executes in repl to another function fails?

1 view
Skip to first unread message

Bill Robertson

unread,
Feb 27, 2011, 9:36:17 PM2/27/11
to erlangcamp
I wrote a timer function which, takes a number of iterations and a
fun, after executing N times, it returns the number of microseconds.
It was doing fine until I gave it the following fun.

168> F = fun() -> gaeqn:evaluate(42,
gaeqn:tokenize(gaeqn:random_chromosome(20))) end.
#Fun<erl_eval.20.67289768>
169> F().
{1.609082951444313e-6,
[7,"+",6,"*",217909,"-",7,"+",2760820,"/",9],
621514}

You can see that the fun executes w/o error, but when passing it to
the timer, something bombs.

170> gaeqn:timer(200, F).
** exception error: bad argument in an arithmetic expression
in function gaeqn:compute/2
in call from gaeqn:evaluate/2
in call from gaeqn:timer/3

The timer code appears to work. Please see the code snippet below.

172> gaeqn:timer(200, fun() -> now() end).
307
173> N = fun() -> now() end.
#Fun<erl_eval.20.67289768>
174> gaeqn:timer(200, N).
224

Here is the timer code.

timer(N, Fun) when N > 0 ->
timer(now(), N, Fun).

timer(Start, 0, Fun) ->
Fun(),
timer:now_diff(now(), Start);
timer(Start, N, Fun) ->
Fun(),
timer(Start, N-1, Fun).

Any ideas why the two wouldn't work together?

Garrett Smith

unread,
Feb 28, 2011, 1:58:38 AM2/28/11
to erlan...@googlegroups.com, Bill Robertson
Does this fail each and every time you run it? You have a "random"
element in your example -- could that be throwing off an occasional
bad value?

I'd want to know what values were going into gaeqn:compute/2 that were
causing the error before thinking too hard about it. Can you throw in
an io:format/2 call somewhere to print your inputs?

Bill Robertson

unread,
Feb 28, 2011, 11:03:58 PM2/28/11
to erlangcamp
*sheepish admission* Yup, my problem. Division by zero in there.
Thanks for the help. What is it about learning a new language that
makes figuring out your own problems so difficult? I think you end up
so focused on figuring out about the new stuff that you end up unable
to consider basic problems.

Thanks again.

Mon, Feb 28, 2011 at 2:06 AM
>> That's a good point. I had run it a few dozen times w/o error by hand.
>> However, the timer is running it significantly many more times, so
>> probably encountering a flaw in the logic. I will hit it harder tomorrow.

Jordan Wilberding

unread,
Mar 1, 2011, 6:47:22 AM3/1/11
to erlan...@googlegroups.com, Bill Robertson
I have found that with any new language, there is always that period where you to build up your intuition to decipher what an error is being caused by.

Thanks!
JW
Reply all
Reply to author
Forward
0 new messages