Geometric Progression Tester

[Weregoose]

You have a list at least three elements in Ans, not necessarily containing integers. The goal is to write a routine of the smallest size that will say whether it represents a geometric progression, by printing either a zero or one to the home screen.

Again, program size is measured objectively as the number of bytes given next to the program on the memory screen, minus the number of characters in the program's name. I haven't asked for a specific number because I want to see what you guys can come up with, but I will say that any routine that beats mine will be stuck on my website for download. (See the bottom link in my signature.)

[Ed H]

I have the program in 23 bytes. However, I need to add 3 or 4 bytes to deal with small floating-point errors for sequences with a ratio of like 1/7 or something.

[Weregoose]

23 bytes..? :|

Example input: {‾2/3,4/9,‾8/27,19/81,‾32/243}

(Don't get me wrong – I'm half expecting you to surprise me with something here.)

[Ed H]

Yes, when you put in {-2/3,4/9,-8/27,16/81,-32/243}, it returns a 1.

However, if you put in seq(AR^X,X,0,N) with A=.1, R=1/3, and N=3, the program returns a 0. I need to add 3 or 4 bytes to take care of that.

Heheh, okay. Here we go.
[whiteout]:not(max(∆List(∆List(Ans)^-1∆List(cumSum(Ans[/whiteout]
Here's with 3 bytes added to take care of floating point errors.
[whiteout]:not(iPart(E9max(∆List(∆List(Ans)^-1∆List(cumSum(Ans[/whiteout]
However, the above version increases the tolerance enough to mistake the list {12,36.00000001,108.00000002,324.00000003} as a geometric sequence. This can be fixed by [whiteout]changing the 9 to a 14, or 20[/whiteout], adding a byte.

[Weregoose]

[bfr]

No, don't post it yet! :P

I just saw this topic a short while ago and I think I just came up with a pretty good method.

[Ed H]

Oops, too late! But don't worry, it's in spoiler tags and it's three posts up, so just don't Control + A and scroll up! :D

Edit: The fact that you didn't notice my solution 3 posts up is probably an indication that I need to stop putting my responses in edits of previous posts. Heh.

[Weregoose]

Hmm (looking at the Ed H's edit above)...

You'd need an [whiteout]abs([/whiteout] because of [whiteout]{‾1,‾2,4,8}[/whiteout], but then [whiteout]max(abs([/whiteout] can be replaced by [whiteout]stdDev([/whiteout] or [whiteout]variance([/whiteout], and you can also wedge a [whiteout]round([/whiteout] in between the two [whiteout][font="times new roman"]∆List('s[/whiteout]

[bfr]

Pretty much the best I could come up with before I got the temptation to look at yours :ninja: was something like (this doesn't work with lists with negative elements or lists that decrease though, by the way):

[Weregoose]

Cool, I was expecting some code like that.

I'll post my program later, as this challenge hasn't been open long enough yet.

[Ed H]

Hmm, the program works fine on {-1,-2,4,8}

The mathematical justification of this program is that [whiteout]The deltaList of a geometric sequence should be a geometric sequence with the same ratio. Therefore, the deltaList should a constant multiple of the original sequence sans the first element.

arⁿ - ar^n-1 = (r - 1)ar^n-1[/whiteout]

Using [whiteout]variance([/whiteout] instead of [whiteout]max(∆List([/whiteout] takes the size down to 22:
[whiteout]:not(variance(∆List(Ans)-1∆List(cumSum(Ans[/whiteout]

How exactly does the round( command work? I'm trying to use it but it keeps giving back what I put in. All I want is for anything less than 10^-24 to be recognized as 0.

[Weregoose]

Eep, another typo. The first generation code that you posted showed {‾1,‾2,4,‾8} (with the 8 negative) to be geometric. Your latest routine fixes this.

round( without a second argument only truncates digits past the tenth from the mantissa, which would explain why numbers close to zero aren't being zeroed out.

Hint: Try putting the round( someplace else.

[Ed H]

Ah, I see. I should have remembered to use [whiteout]variance or stdDev[/whiteout] to find out whether [whiteout]all the elements were the same[/whiteout]. Silly of me to forget. Thanks for pointing that out.

So here is a 25 byte version with tolerance for stupid fractional ratios.

[Weregoose]

Solid as a rock... I don't think we could possibly rearrange it any further without changing the algorithm.

[EDIT]

Is there any reason not to turn the inverse into a solidus at this point? It might fix some tolerance problems. *checks*

[EDIT×2]

Not sure why, but it worked. {12,36.00000001,108.00000002,324.00000003} is marked as not geometric.

[bfr]

Or how about [whiteout]not(variance(∆List(Ans)/∆List(cumSum(Ans[/whiteout], which is 22 bytes (I haven't really looked closely at it or tested it much yet, because I have to get back to my homework, but I know it at least detects {-2/3,4/9,-8/27,16/81,-32/243} as geometric and {1,2,16) as not geometric)

[Ed H]

[bfr]

Er, sorry, I didn't really read your solution nor Weregoose's post carefully. I actually just thought of this now and that it was something new.... That's the second time in this thread that I didn't read the other posts carefully. *hides*

EDIT: Actually, taking another shot at this after looking at DarkerLine's method below, something like... [whiteout]
∆List(ln(Ans
not(variance(real(Ansconj(Ans[/whiteout] which is 23 bytes. It's [whiteout]a shame that I need the real( there, even though I think the result would be real anyway[/whiteout].

[DarkerLine]

I'm looking at something based [whiteout]e^(∆List(ln(Ans[/whiteout], which should be a constant list for geometric series, and nonconstant otherwise -- check this with not(max(∆List or something. It works perfectly for positive geometric series; when some terms are negative, the complex numbers involved introduce round-off error. There's probably a way to fix this using round(... how about [whiteout]min(1=1+abs(∆List(e^(∆List(ln(Ans[/whiteout]?

[calc84maniac]

Yeah, I did the [whiteout]log[/whiteout] approach too. Works perfectly for positive numbers only so far.

[DarkerLine]

You'll need to be in complex number mode to use logs, since taking logs of negative numbers results in a complex answer. Another problem with these is that there's multiple branches for an inverse to exponentiation, so if you do things the naive way you might end up with certain elements differing by 2πi.