Once I
put 17 into tRepeats
so I do 102 cycles, I get very similar:
For 102 cycles
K's solution = 1657ms
Paul's solution = 1453ms
Geoff's solution = 1536ms
For 102 cycles
K's solution = 1638ms
Paul's solution = 1455ms
Geoff's solution = 1533ms
For 102 cycles
K's solution =
On Sun, Feb 19, 2012 at 5:32 PM, Kay C Lan wrote:
>
>put "For " & tRepeats & " cycles" & cr into R
>
> Oopps. That should read "For " & (6 * tRepeats) & " cycles" & cr into R
Because of the nested repeat it's really doing 600 cycles.
___
use-li
On Sun, Feb 19, 2012 at 4:48 PM, Geoff Canyon Rev wrote:
> "repeat for each line" is incredibly fast, so I'm not surprised that it
> beats an array. Interestingly, I was able to speed up all three solutions
> by doing this:
>
> get aTime[i]["Increment"]
>
> and then using "it" in the math mak
On Sun, Feb 19, 2012 at 12:58 AM, Kay C Lan wrote:
> I've tweaked your solution only slightly as you solution only worked for
> quarter hour increment, whilst both mine and Paul's would work for any
> required increment . I simply replace your fixed 4 with the 3600/increment
> that both Paul and I
On Sun, Feb 19, 2012 at 12:22 PM, Geoff Canyon Rev wrote:
> (and to return hours, so it matches the output of the other
> two).
>
OK, now I see where I was getting confused. I was focused on decimal hours
as per the OP, but you were outputting seconds.
I've tweaked your solution only slightly a
On 2/18/12 10:32 PM, Geoff Canyon Rev wrote:
On Sat, Feb 18, 2012 at 9:57 PM, J. Landman Gay
wrote:
function whichOne var,fld1,fld2
-- from a handler by Tony Root
-- Handles a case where you need to return one value if your key is empty,
another if not.
return (item offset(char 1 of (var =
On Sat, Feb 18, 2012 at 9:57 PM, J. Landman Gay
wrote:
> function whichOne var,fld1,fld2
> -- from a handler by Tony Root
> -- Handles a case where you need to return one value if your key is empty,
> another if not.
>
> return (item offset(char 1 of (var = empty),"tf") of quote & fld1 &","&
>
On Fri, Feb 17, 2012 at 7:55 PM, Kay C Lan wrote:
> Guys I thought I'd speed test these.
Given that we're dealing in seconds (and therefore integers), the very
clever itemoffset idea Peter came up with is unnecessary. Here's a
comparison of the three options, with mine tweaked to be similar to
On 2/18/12 7:41 PM, Peter M. Brigham, MD wrote:
I picked this trick up from someone along the way, on this list I
believe, I've lost track of where it came from, so credit goes to
someone else.
It may be from something I posted to the HyperCard list eons ago. I got
it from Paul Foraker, who wo
That's great. I understand. Sometimes we get a bit too cryptic for our own
good. (smile)
Joe Wilkins
Architect
On Feb 18, 2012, at 7:45 PM, Geoff Canyon Rev wrote:
> This is the entire function definition, with the comment in place:
>
> function roundUp x,i -- rounds x up to the next i
> retu
This is the entire function definition, with the comment in place:
function roundUp x,i -- rounds x up to the next i
return x div i * i + item itemoffset((x mod i > 0),"true,false") of (i,0)
end roundUp
I only included the first line in my original question because it's the
only line with a com
Kind of true Geoff, but the call would have arguments in place of parameters,
whereas
function roundUp x,i isn't the function's definition either. Not intending to
nit-pick.
Joe Wilkins
Architect
On Feb 18, 2012, at 7:01 PM, Geoff Canyon Rev wrote:
> ? That is the definition (and not a call
No Al,
In the early days, even with HC, when most of us were using Assembler, Pascal
and Basic, it was not in the lease uncommon to comment every line of code so we
knew what we were doing; particularly with Assembly language. Of course using C
it was an absolute must; and, if I were working wi
Hi Joe,
Joe Lewis Wilkins wrote
>
> I'm sure that one of the problems that faces most new LC coders
> is that they do too much before they try it out. By the time I have
> something "done" I've already debugged it dozens of times.
> It just works. Of course I don't stretch LC to its limits very
? That is the definition (and not a call).
On Sat, Feb 18, 2012 at 2:24 PM, Joe Lewis Wilkins wrote:
> Certainly better than nothing; but, if you put it in the function
> definition instead of the calls, you only have to do it one time.
>
> Joe Wilkins
>
> On Feb 18, 2012, at 12:04 PM, gcanyon+r
You're forgiven, Peter.
Joe Wilkins
Architect
On Feb 18, 2012, at 5:41 PM, Peter M. Brigham, MD wrote:
> I picked this trick up from someone along the way, on this list I believe,
> I've lost track of where it came from, so credit goes to someone else. You're
> right, Joe, commenting something
I picked this trick up from someone along the way, on this list I believe, I've
lost track of where it came from, so credit goes to someone else. You're right,
Joe, commenting something as opaque as this (at least at first glance) is
advisable, especially when you're sharing code. I can only ple
Alex,
I'm sure that one of the problems that faces most new LC coders is that they do
too much before they try it out. By the time I have something "done" I've
already debugged it dozens of times. It just works. Of course I don't stretch
LC to its limits very often. When I do something, I've do
Hi Joe,
Joe Lewis Wilkins wrote
>
> True Ken, but w/o comment it is much more difficult to know what is going
> on.
> If you're going to use one liners like this, you'd better add some
> commentary.
> One of the weaknesses I see in LC coding is the shortage of comments.
> I realize that is a str
Certainly better than nothing; but, if you put it in the function definition
instead of the calls, you only have to do it one time.
Joe Wilkins
On Feb 18, 2012, at 12:04 PM, gcanyon+rev wrote:
> I'm curious what you think of this, which is what I try to do regularly when
> I create one-liners
I'm curious what you think of this, which is what I try to do regularly when I
create one-liners (which I favor).
function roundUp x,i -- rounds x up to the next i
On Feb 18, 2012, at 11:23 AM, Joe Lewis Wilkins wrote:
> If you're going to use one liners like this, you'd better add some comme
True Ken, but w/o comment it is much more difficult to know what is going on.
If you're going to use one liners like this, you'd better add some commentary.
One of the weaknesses I see in LC coding is the shortage of comments. I realize
that is a strong-point of LC; it is "almost" self-commentin
> function roundUp x
> return trunc(x) + char itemoffset((x mod 1 > 0),"true,false") of "10"
> end roundUp
VERY clever, Peter!
That's a great one-line variant to:
function roundUp x
put trunc(x) into tRetVal
if x mod 1 > 0 then add 1 to tRetVal
return tRetVal
end roundUp
:D
Ken Ray
Son
Well, there's something wrong with the K solution and the Paul solution.
Stepping through the script with the debugger, for the first line of tStore,
the difference between tEndTime and tStartTime = 7974 (I inserted a temp
variable tTemp = tEndTime - tStartTime so I could see what was going on).
This is beginning to look Disturbingly like regex!
Sent from my iPad
On Feb 17, 2012, at 7:13 PM, "Peter M. Brigham, MD" wrote:
> On Feb 17, 2012, at 6:39 PM, Geoff Canyon Rev wrote:
>
>> My original function took the number to be rounded and the increment to
>> round up to, so I think your v
On Feb 17, 2012, at 6:39 PM, Geoff Canyon Rev wrote:
> My original function took the number to be rounded and the increment to
> round up to, so I think your version would become:
>
> function roundUp x,i -- rounds x up to the next i
> return x div i * i + item itemoffset((x mod i > 0),"true,fal
Guys I thought I'd speed test these.
Unfortunately I don't have the time to figure out exactly how Geoff's
amended version of Peter's solution actually works in this case; rounding
1.1 to 1.25, 3.3 to 3.5. I can get it to work with whole numbers, but not
0.25 increments as per the OP.
The current
OK now you are just showing off! :-)
Bob
On Feb 17, 2012, at 3:39 PM, Geoff Canyon Rev wrote:
> My original function took the number to be rounded and the increment to
> round up to, so I think your version would become:
>
> function roundUp x,i -- rounds x up to the next i
> return x div i *
My original function took the number to be rounded and the increment to
round up to, so I think your version would become:
function roundUp x,i -- rounds x up to the next i
return x div i * i + item itemoffset((x mod i > 0),"true,false") of (i,0)
end roundUp
On Fri, Feb 17, 2012 at 1:49 PM, Pet
Thanks for that Paul!
Bob
On Feb 17, 2012, at 2:03 PM, Paul Dupuis wrote:
> Well Bob, here is one more:
>
> -- countTheHour with NO IF statements, proper rounding, and a single
> calculation line
> -- pIncrement is in seconds, so 900 equals 15 minutes increments. The
> default (by the max func
Well Bob, here is one more:
-- countTheHour with NO IF statements, proper rounding, and a single
calculation line
-- pIncrement is in seconds, so 900 equals 15 minutes increments. The
default (by the max function) is 1 minute (60 seconds)
-- 1 second in 1 hour is 1/3600 or 0.000278, so the roundUp
Thanks all. Some ingenious ways of going about it. Never ceases to amaze me
when I see all the ways of doing something when I thought there was only 1. :-)
Bob
On Feb 17, 2012, at 11:49 AM, Peter M. Brigham, MD wrote:
> On Feb 17, 2012, at 12:20 PM, Geoff Canyon Rev wrote:
>
>> function round
On Feb 17, 2012, at 12:20 PM, Geoff Canyon Rev wrote:
> function roundUp x,i -- rounds x up to the next i
> return ((x - .1) div i + 1) * i
> end roundUp
Works except for values like 4.1.
Try this instead. It's a sort of a trick to avoid using a conditional
construction, though th
Obviously you could do this inline, but then it wouldn't be reusable. I'd
go with a function:
function roundUp x,i -- rounds x up to the next i
return ((x - .1) div i + 1) * i
end roundUp
function test T1,T2
-- returns the difference between two times in seconds
-- rounded up to the
On Tue, Feb 14, 2012 at 6:09 AM, Bob Sneidar wrote:
> Hey there it is! I was looking for a strictly mathematical method but that
> will do nicely.
>
> Not sure how Paul's response could be the answer as it seems to miss an
important step.
"--take the difference in pIncrement units, rounded up…"
Hey there it is! I was looking for a strictly mathematical method but that will
do nicely.
Bob
On Feb 13, 2012, at 12:48 PM, Paul Dupuis wrote:
> FUNCTION countTheHours2 pStartTime, pEndTime, pIncrement
>IF pIncrement is empty THEN put 900 into pIncrement -- pIncrement is
> in seconds. So
FUNCTION countTheHours2 pStartTime, pEndTime, pIncrement
IF pIncrement is empty THEN put 900 into pIncrement -- pIncrement is
in seconds. So 900 is 15 minutes. Do not use zero. 1 is minimum.
TRY
convert pStartTime to seconds
convert pEndTime to seconds
put (round
37 matches
Mail list logo
