PE 390
 

anyone tackle this one yet?

I've got a (very elegant) simplified formula but finding solutions to it is difficult to do quickly.

[QUOTE]a (very elegant) simplified formula
[/QUOTE]
There are two layers in this problem. Both elegant.

Yeah, last night at 3:35am (#38). I was plagued by precision errors at the last stage, so had to rewrite some parts. Sacrificed some quality sleep. Cranky today.

sent a pm

[QUOTE=voidme;303284]anyone tackle this one yet?

I've got a (very elegant) simplified formula but finding solutions to it is difficult to do quickly.[/QUOTE]
Would you mind [strike]trying out[/strike] atleast seeing off [URL="http://mersenneforum.org/showpost.php?p=300449"]my own problems[/URL] that which were being framed already

Even with a fast algorithm, precision issues are really stupid on this one. Hate problems like these

That's actually part of the beauty. The author pushes the problems to the ~60-bit value territory, so naked perl (for example) fails: in perl, internally values are stored as strings and as doubles, therefore have 53-bit precision. So you can either use Pari or Bigint in perl, ...or something in between like Math::Int128. (I do like to prototype in perl.)

Python has a neat [URL="http://docs.python.org/py3k/library/decimal.html#module-decimal"]decimal[/URL] module:
[quote]Unlike hardware based binary floating point, the decimal module has a user alterable precision (defaulting to 28 places) which can be as large as needed for a given problem:
[code]
>>>
>>> from decimal import *
>>> getcontext().prec = 6
>>> Decimal(1) / Decimal(7)
Decimal('0.142857')
>>> getcontext().prec = 28
>>> Decimal(1) / Decimal(7)
Decimal('0.1428571428571428571428571429')[/code]
Both binary and decimal floating point are implemented in terms of published standards. While the built-in float type exposes only a modest portion of its capabilities, the decimal module exposes all required parts of the standard. When needed, the programmer has full control over rounding and signal handling. This includes an option to enforce exact arithmetic by using exceptions to block any inexact operations.[/quote]
PS: There's also [URL="http://www.scipy.org/more_about_SciPy"]SciPy/NumPy[/URL].

I'm aware, but I'm just not a fan of problems that intentionally screw with precision. Nothing but extra tedium. Especially in C++, using big precision is a huge pain in the neck to get working, let alone use. I don't like having my options limited for no real reason other than to slow runtime.

update: when trying the decimal class on my program, it just slugs to an utter crawl and would probably take a month to finish. which is totally stupid considering my algorithm calculates most of the problem in under a second.

GMP?

Edit: [URL="http://mpir.org/#about"]MPIR[/URL] might work for Windows.
[quote]To maintain full interface support with GMP - MPIR is a drop-in replacement for GMP.
Support for building MPIR using Microsoft Visual Studio 2010 for use in both 32-bit and 64-bit versions of Windows.[/quote]

[QUOTE=Dubslow;303470]GMP?[/QUOTE]

GMP is nearly impossible to get working on Windows, and even if you get it working, it's really difficult to use because you have to treat everything in really quirky ways with specialized functions and what have you.

I'm just frustrated/ranting. I really hate having a completely workable solution only to find that precision errors render it useless unless you have Linux etc. My program only takes a couple minutes in C++ (but in interpreted languages + precision modules like mpmath/numpy/decimal/bigdecimal it would take probably months).

The main problem is twofold: Overflow in intermediary calculations of N (even when using unsigned long longs), and precision problems in the output of square roots. My program checks if certain square root outputs are integral, but without necessary precision, sometimes this gives the wrong answer.

If someone has a working GMP can I give them my program to run? It was enough of a nightmare getting problem 372 working... I had to go to a campus lab last time.

edit: I could never get MPIR working on my machine for some reason, but I think that's what the campus lab uses

I can't comment on GMP on Windows but I maintain the Windows Visual Studio build of MPIR, which should fairly easy to build with native tools (it should also build with mingw64).

If you can be more specific with the issues you ran into, I can look into them. It is also worth noting that there are C++ interface to MPIR and MPFR that hide all the gory details of using multiple precision. If variables have been typed in a way that allows an easy change of their types, it is then quite easy to develop without MPIR/MPFR and then simply change the types and rebuild with MPFR/MPIR support.

If you PM me with your code, I will see if it is easy to run with MPIR (you might need to document it a bit though :-)

Sent PM

Thank you, Brian, for taking the time to run my code!

[QUOTE=voidme;303596]Thank you, Brian, for taking the time to run my code![/QUOTE]
You are welcome.

Brian

391 is tricky too

i have a working brute force solution but that is all

2 3 5 7
 

I am cleaning up old problems, especially those that I postponed earlier (last summer and last March were two solving binges; now, this summer break also lends itself to some recreational activities...)

Here's a pretty funny numerological result (given what problem 118 actually deals with): :smile:

And of course the number itself is prime too.

why are there so few solvers for 391? are people busy or is it really that hard?

no love for 391?

"No time for love, Doctor Jones!"