search

taborlab / Iris

The Light Program Interface
BSD 3-Clause "New" or "Revised" License
12 stars 2 forks source link

Arb inputs force timepoints to be whole numbers of minutes #206

Closed SynbioLucas closed 9 years ago

SynbioLucas commented 9 years ago

Trying to enter a light intensity change at 0.5min is valid, but the HandsOnTable rounds all inputs. In reality, any time that corresponds to a whole time step is valid; if a time is entered between time steps, the closest valid time should automatically be entered.

The correct computation for a given time should be:

Math.round(time*60*1000/timeStep)*timeStep/1000.0/60.0

This will give the correct value, which is the closest time that is a valid time step (generally increments of 1000ms, but sometimes 1e4ms).

BrianLandry commented 9 years ago

Is it acceptable to simply allow any decimal value? It is already implied that rounding occurs for timesteps with regard to the sine function, so doing that for the arb function doesn't seem crazy.

BrianLandry commented 9 years ago

So it appears the values are stored correctly, ie, when you go back and edit the decimal is there. They are simply rounded for viewing without decimals. I can fix this by dictating a set number of decimal places to display. I am thinking 3 decimal places would be appropriate, do other people agree?

SynbioLucas commented 9 years ago

Does it pad with trailing 0s? If so, then I'd go with 2 places, especially since you say the full information is still retained, it's only changed for viewing. If trailing 0s aren't added, then allow enough decimal places to specify something to the minimum time step allowed: 1ms = 5 decimal places.

To answer your question, though it may not matter, I don't think it's ok to force arb time points to be whole numbers of minutes. That's a relatively huge and totally unnecessary loss of resolution.

On Tue, Oct 6, 2015 at 1:52 PM Brian notifications@github.com wrote:

So it appears the values are stored correctly, ie, when you go back and edit the decimal is there. They are simply rounded for viewing without decimals. I can fix this by dictating a set number of decimal places to display. I am thinking 3 decimal places would be appropriate, do other people agree?

— Reply to this email directly or view it on GitHub https://github.com/rice-bioe/LPI/issues/206#issuecomment-145963688.