Out-of-bounds value policy question

classic Classic list List threaded Threaded
4 messages Options
Martin Guy Martin Guy
Reply | Threaded
Open this post in threaded view
|

Out-of-bounds value policy question

Hi!
  What's the eLua policy for handling things like when they set
frequencies of 0,
negative duty cycles, pwm frequencies of zero and so on?
   I see that duty>100 is currently set to 100, whereas bogus values
just do random things on different platforms
For example, on AVR32, setting an I2C frequency of zero currently
gives a bit-size of 71.5 seconds, which just happens to be when its
32-bit timer wraps round at 60MHz.

Should we quietly set, say, zero or negative frequencies to the lowest
possible frequency (1Hz) so that thing "just work", or should we give
a run-time error?

     M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
jbsnyder jbsnyder
Reply | Threaded
Open this post in threaded view
|

Re: Out-of-bounds value policy question



--
James Snyder
Biomedical Engineering
Northwestern University
http://fanplastic.org/key.txt
ph: (847) 448-0386

On Oct 7, 2011, at 20:47, Martin Guy <[hidden email]> wrote:

> Hi!
>  What's the eLua policy for handling things like when they set
> frequencies of 0,
> negative duty cycles, pwm frequencies of zero and so on?
>   I see that duty>100 is currently set to 100, whereas bogus values
> just do random things on different platforms
> For example, on AVR32, setting an I2C frequency of zero currently
> gives a bit-size of 71.5 seconds, which just happens to be when its
> 32-bit timer wraps round at 60MHz.
>
> Should we quietly set, say, zero or negative frequencies to the lowest
> possible frequency (1Hz) so that thing "just work", or should we give
> a run-time error?

Hmm..  My initial thought might be to automatically clip things at the maximum and minimum, but another part of me hates silently correcting errors...

Bogdan might disagree, but I think we should throw an error if the input is outside of specified bounds (i.e. for pwm). If bounds are unspecified and might be hardware limited I have less of a problem with automatic correction, although a warning wouldn't be unwarranted.

I'm not sure what side of the fence you fall on, but I'd be happy with quickly establishing a policy on this front without going into an extended thread even if If the conclusion differs from the preference I suggested :)

>
>     M
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: Out-of-bounds value policy question

In reply to this post by Martin Guy


On Sat, Oct 8, 2011 at 4:47 AM, Martin Guy <[hidden email]> wrote:
Hi!
 What's the eLua policy for handling things like when they set
frequencies of 0,
negative duty cycles, pwm frequencies of zero and so on?
  I see that duty>100 is currently set to 100, whereas bogus values
just do random things on different platforms
For example, on AVR32, setting an I2C frequency of zero currently
gives a bit-size of 71.5 seconds, which just happens to be when its
32-bit timer wraps round at 60MHz.

Should we quietly set, say, zero or negative frequencies to the lowest
possible frequency (1Hz) so that thing "just work", or should we give
a run-time error?

I vote on throwing an error. I preffer verbose (throw error) over non-verbose (quitely set a default value).

Best,
Bogdan


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Martin Guy Martin Guy
Reply | Threaded
Open this post in threaded view
|

Re: Out-of-bounds value policy question

On 8 October 2011 11:44, Bogdan Marinescu <[hidden email]> wrote:
> I vote on throwing an error. I preffer verbose (throw error) over
> non-verbose (quitely set a default value).

OK. One side is for badly-written programs not to die unexpectedly
when deployed in the field. The other is to encourage people to get
them right in the first place, and I'm happy to go with the second of
these two.

    M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev