Task 306 - Line Drawing Algorithm - no spoilers
Back to General discussions forum
A cute little problem; thanks!
A small nitpick: I don't think that BASIC interpreter is in int mode (so most of my solution had to effectively hack an int mode :) ).
Oh, Vladimir, thanks a lot for quick check! Again and again I found that trying to complete the problem after midnight
is risky. Just mistyped intMode instead of intOnly and that's it :(
Now should be better! The easy way to check is to add LOG(1) to any expression - this function along with EXP and
trigonometry is disabled in "integer" mode.
most of my solution had to effectively hack an int mode
Yep, sorry for that.
But that seems obvious you haven't googled the intended algorithm - it doesn't use multiplications :)
Added "notes" to the problem. Also I unintentionally submitted my own solution when testing, but hopefully it is no harm and can provide some auxiliary hints.
Thank you.
But I am somewhat dissatisfied that our solutions try to avoid multiplications yet the hex output is based on / and mod.
I am somewhat dissatisfied that our solutions try to avoid multiplications yet the hex output is based on / and mod.
You can subtract 16 while you can, counting loops; that's your senior digit. Whatever remains, is the junior digit.
Of course. Or build an array of all 2-digit hex numbers for look-up. But none of these approaches feels particularly elegant (to me). That's probably a limitation of the simpler programming language used here.
yet the hex output is based on / and mod
I dare say it's pretty all right since it is not division really but SHR, which is even cheaper operation than
addition/subtraction. Moreover if you do this in assembly, you'll need it not at all as they are in separate nibbles.
I'm using Basic and I am not sure, after a couple weeks, why I get the wrong answer. I'm using an input box to enter X0 Y0 X1 Y1, by the way, if that makes any difference.
It says: Expected Answer was:
qEnter X0 Y0 X1 Y1: 3C283D293E293F2A402B412B422C ...490D591D692D793D893D994DA95DB95DC96 Any hints would be appreciated!
Hi! There are 3 issues, it seems!
Your code draws different line! See picture below - red is what my code outputs, green is what your code outputs
Your code prints extra output in beginning (that gives you extra green point dangling alone at beginning). Please only print the bytes of the line itself, no additional words, debug info etc - checker parses them unintentionally.
Checker obviously has mistake showing your result instead of the expected answer. Thanks for sharing this and sorry for inconvenience. I'll try to fix it soon (need to relogin as admin)
That's weird. Ok, I will look at my code some more, maybe the Bresenham algorithm some more. Thanks for your help!
Not sure, but perhaps you just swapped X and Y or something like this?
Meanwhile the bug with confusing error report is fixed hopefully.