[Haskell-cafe] ANN: atom-0.1.3

miaubiz miaubiz at gmail.com
Mon Jan 18 11:12:33 EST 2010



Tom Hawkins-2 wrote:
> 
> Would you explain what you are trying to do a bet more clearly?
> 

Certainly.  I am writing an autonomous rover.  To choose the direction to
drive towards, the car compares the direction it wants to go with the
direction it is actually facing.  To avoid continuously zigzagging I have
hysteresis set around the target direction.

1. I have a set of test inputs
2. I want to run my atoms
3. I want to verify that the state of my atom matches a specific state after
each iteration

t2 = defaultTest {
          testbench = steeringVsBearing
         ,declCode = header fakeHeaders
         ,cycles = (length testData)
        }

steeringVsBearing :: Atom () -- this is only a test
steeringVsBearing = do
  steering <- word8' "steering"
  targetHeadings <- array "targetHeadings"  ([target | (target, _, _) <-
testData])
  actualHeadings <- array "actualHeadings"  ([actual | (_, actual, _) <-
testData])
  expectedSteerings <- array "expectedSteerings" ([steerings |(_, _,
steerings) <- testData]) 
  targetHeading <== targets !. clock
  compass <== actuals !. clock

  navigate --this is my production atom
  assert "steeringWorks" $ (value steering) ==. (expectedSteerings !. clock)

navigate = do
  steering <- word8' "steering"
  
  period 1 $ atom "figureOutWhichWayToGo" $ do
     --calculate steering based on target heading and actual heading
     --blah blah
    steering' <- do return $ mux l1 (mux r1 75 90) 105
    steering <== steering'


Tom Hawkins-2 wrote:
> 
>> output <- word16' "output"
>> input <- word16' "input"
>>
>> input <== inputs !. clock
> 
> There are a few potential problems with this statement.  First,
> 'input' in an external variable -- which is fine, just be sure nothing
> is being assigned to it in the external c code.  Note, if 'input' is
> not referenced by external code, then 'word16 "input" 0' would be a
> better variable declaration.
> 

I used an external variable because I wanted to reference it both in
steeringVsBearing which is a test function, and the actual function
navigate.  


Tom Hawkins-2 wrote:
> 
> The second problem is a bit more serious.  By using the 'clock' as an
> array index, it will eventually go outside the bounds of the array.
> Beware: Atom provides no array checks, such as index-out-of-bounds, or
> assigning the same array location multiple times within the same
> atomic action.
> 

ok.  I am using clock as an index in the test function only. 


Tom Hawkins-2 wrote:
> 
>> doStuff
>> assert "fiveIsAdded" $ (value output) ==. (expected !. clock)
> 
> Keep in mind than multiple rules will fire in one 'clock' cycle, and
> assertions are checked between the execution of each rule.  In this
> case, the assertion will be checked before the top level rule that
> contains the assignment 'input <== inputs !. clock', and before the
> "addFive" rule.  In both cases 'clock' will have the same value, which
> will probably lead to an assertion violation.
> 

I am unable to come up with any assertions that would be valid all the time,
which would allow me to feed test data into my atoms and then verifying them
against some known inputs.

I have some other asserts that I find helpful, such as (minus the spaces):

  assert "target is closer than 1800 to actual" (target' - actual' <=. 1800)
  assert "target is closer than 1800 to actual'" (actual' - target' <=.
1800)

but checking that the steering is valid is more difficult because it depends
on the previous state of steering due to hysteresis.

I don't want to replicate the logic of hysteresis in the assertion:

assert "steeringWorks" $ mux (previousSteering `lt_` 90) mux
(currentSteering `gt_` 90) etc etc etc.


Tom Hawkins-2 wrote:
> 
>>
>> doStuff
>>  atom "addFive" $ period 1 $ do
>>    output <== (value input 5) + 5
> 
> This last statement should yield a type violation.  "(value input 5)".
> 

that was a typo on my part. 

I assume I am totally off on my testing attempt, and if you could point me
in the right direction I would greatly appreciate it.

Br, 
Miau

-- 
View this message in context: http://old.nabble.com/ANN%3A-atom-0.1.3-tp26624813p27212766.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.



More information about the Haskell-Cafe mailing list