Gene, did you have time to include us in the programming challenge?

hehe, they claim having discovered particles travelling faster than light, but not *as* fast! A whole year, omg ;-)

Walter, it was you who caught my last error calling the conference from five years ago HHC1997..

I don't need any more calculators, I need a good watch..

Edited: 24 Sept 2011, 4:21 p.m.

From Gene, "Sorry for being late. No WiFi or network access here."

http://xmission.com/~egan/2011_Programming_Contest.pdf

Edited: 24 Sept 2011, 5:35 p.m.

Thanks for posting this

This morning was much more hectic than I had predicted

So far no corrections have been seen to the information in the document ... So the contest is now open

Remember ... Please do not post solutions and probably don't post many questions publicly either! :-)

Sorry for the delay and thanks again Egan!

Time to add a special integral area of a circle function to the 34S ;-)

- Pauli

Nope, the contest rules specifically prohibit new code or binaries including new functions not present yesterday

:-)

I noticed that but had to say it anyway :)

I might have found another bug in the firmware too :-( Still investigating. Sigh. This task never ends.

- Pauli

Quote:

---

I might have found another bug in the firmware too :-( Still investigating. Sigh. This task never ends.

---

Nope. Not without revealing things that will help others :-)

- Pauli

Off to bed...

Hi Gene,

where to post the programs? I used your email address, hope that's ok.

Thomas

Just a remark: IMHO, 8 pixels less would give a better circle in the case shown in the picture. But it would complicate the challenge, so take it just FWIW.

For a certain feature, it could even be a square package of pixels to be as much a circle as the fit given ;-).

Yeah, I think any pixel should be lit only if the circle covers more than 50% of it, but - as mentioned above - this condition would raise the level of complexity significantly.

I know what you meant, I was just fooling around to compensate the frustration for not being at the HHC :-/.

Hello Thomas,

Here are my results, no spoiler:

     1 R/S ->           4       (   -  ,    2.2 s)

     5 R/S ->          88       (   -  ,    5.6 s)   

   540 R/S ->      9#8#6#       ( 6.8 s,  407.0 s)

  5000 R/S ->    #8#5#6#0       (60.3 s,    -    )

(timings on the 12C+ and 12C, respectively)

If they are correct, the following is a nice approximation:

n = r*(pi*r + 4)

Regards,

Gerson.

Edited: 25 Sept 2011, 3:31 p.m.

Would posting the result for 540 constitute a spoiler? The number of pixels is what it is. Whether you reach that answer in 10 seconds or in 1000 seconds is more of a spoiler ;-)

Werner

Hi Gerson,

the 32SII does R=5 in a fraction of a second. It's quite a fast baby :-). Just tried R=540 w/o precise timing, might be about 40s, same digits as you got.

Ah, why couldn't HP just produce the Pionieers and Voyagers forever... ;-(

Thomas

But Gerson, what about the center coordinates? The text of the challenge says that the radius as well as x_center and y_center must be entered. :-)))

Anyway, I do not know if your results are correct but at least I get the same on the 35s. ;-) Running times are quite exactly 10x those of the fast 12C+, resp. the 35s is 6x as fast as the original 12C.

Dieter

Quote:

---

But Gerson, what about the center coordinates?

---

That's something I haven't understood. Because of the statement "assume that all circles fit on the display panel even if in reality they would not" it appears to me the coordinates are irrelevant. If only the pixels that fit on the screen should be computed, then the coordinates would be important. I may be wrong however.

Cheers,

Gerson.

I agree with Gerson - the center coords don't matter for counting (theoretical) pixels.

Well, I understood it that way either. So any solution should start with 2x RDN or DROP. ;-)

Either we miss something here ...or we are simply too clever. :-)

Dieter

I don't believe it complicates the problem all that much.

My fastest solution does just this and since I've put too much time into this little puzzle already, I'm not planning on fixing it.

- Pauli

Quote:

---

So any solution should start with 2x RDN or DROP. ;-)

---

You're right. This makes my 12C program two steps longer (48 instead of 46). I thought of including Rv Rv in the beginning, but as it worked with the sample cases I just ignored it. Now checking the rules I see the radius should be entered first... That's how I got B- instead of B at school, by not reading the questions carefully :-)

Edited: 25 Sept 2011, 5:04 p.m.

Definitely agreed here. In the case of the 34S, a complex roll down or complex drop at the start.

- Pauli

34S after an integer mode bug fix to the firmware and I'm getting 7.6 seconds for r = 5,000. Without the fix and sticking to the same algorithm in floating point mode, 32.7 seconds for r = 5,000.

My best attempt (which is slightly broken but not due to a firmware issue and likely in a fixable way) 4.7 seconds for r = 5,000.

- Pauli

Or a RCL Z?

Yes. Or complex x<>y; complex R^ (default state being specified which is 4 level stack) or even x<> Z. I've probably still missed some options.

They'll all run sufficiently fast to make no noticeable difference to the execution time.

- Pauli