More then 12 digit...

[salvomic]

hi,
there is a thing I wish to have in the Prime, after using Free42s (like HP 42s) and its "34 decimal digits of precision": more than 12 digits, even if "on demand" :-)

Maybe, in another possibile World, a Prime-42s (or an HP 42s Prime)...

***In the attached image π after the press of [shift][.] ([Show])***

Salvo

[Joe Horn]

It would SEEM like Prime has the "hooks" necessary to add the LongFloat library to its CAS, but for some reason HP decided not to do so. For example, type "approx(pi,15)" into CAS, and you get this message: "Longfloat library not available". Maybe some day they will add it, or make it available as a software add-on, so that Prime's accuracy can finally compete with the HP 50g with LongFloat installed.

[salvomic]

(12-17-2017 05:20 AM)Joe Horn Wrote:  It would SEEM like Prime has the "hooks" necessary to add the LongFloat library to its CAS, but for some reason HP decided not to do so. For example, type "approx(pi,15)" into CAS, and you get this message: "Longfloat library not available". Maybe some day they will add it, or make it available as a software add-on, so that Prime's accuracy can finally compete with the HP 50g with LongFloat installed.

Thank you Joe. In fact I do hope HP will ad LongFloat someday, if possible.
It would be great.

[Archanus]

Hey There is a program that I don't remember who has coded in the past

But yes, It shows a lot of floating point decimals

Try it

Example:
dec(Ln(57))
dec(pi)
dec(456/87891.2)

SEE THE ATTACHMENTS

[salvomic]

(12-17-2017 04:50 PM)Archanus Wrote:  Hey There is a program that I don't remember who has coded in the past

But yes, It shows a lot of floating point decimals

Try it

Example:
dec(Ln(57))
dec(pi)
dec(456/87891.2)

SEE THE ATTACHMENTS

yes!
thank you.
This program is made by Joe Horn (see here)!
I have it on the Prime...
Joe, please, could you kindly tell us what difference between the method that program use and the LongFloat library? (I'm reading again your post in the Library)

Anyway,

Code:


dec(pi):      "3.141592653589782457869270670413970947265625"
π in Free42:   3.141592653589793238462643383279503

they are different in the 14th digit... 8 or 9 and the rest...

[Archanus]

I guees the differences is that the output of DEC Program is like Char Value, Not Numeric (Double / Float) Value

[salvomic]

(12-17-2017 05:38 PM)Archanus Wrote:  I guees the differences is that the output of DEC Program is like Char Value, Not Numeric (Double / Float) Value

that is sure
I don't remember how to convert "" into numbers in the Prime...
However, above I've put also difference between the number returned and the output of Free42 (34 decimal digit of precision).
Same differences for e after that digit.
So: who is right?
EDIT: After that site Free42 is right. So I'm sure Joe will be so kind to explain us all differences...

[Joe Horn]

My "dec" program for the Prime does NOT perform extended-precision math. It merely outputs ALL the digits of CAS floating-point numbers, which are stored in binary form internally (not 12-digit BCD like traditional HP calculators, and Prime's Home view) and are therefore never fully displayed to the user (contrary to HP's tradition of "What You See Is What You Have"). So the output of the "dec" program is "exact" only in the sense that it lets you see the exact decimal representation of any CAS floating point number. That's dec's only purpose: to let the user see exactly what number they actually have. It does NOT increase Prime's math accuracy in any way.

Example: In Home, PI is stored exactly as the BCD value 3.14159265359 with each digit occupying one BCD position in the 12-digit mantissa. In CAS, however, all floating point numbers are stored internally as a 48-bit binary number with a binary exponent. Here's CAS's pi exactly represented in hex:

1.921FB54442Dp+1
... which means "1.921FB54442D in hex, times 2^1".

And here is the exactly equivalent number expressed in decimal form:
3.1415926535897824578569270670413970947265625

Notice that the above is the same as the ACTUAL value of pi (the irrational mathematical constant) only for the first 14 digits (underlined above), after which all the digits are WRONG.

Fun example: dec(.1) returns 9.99999999999994315658113919198513031005859375E-2 because in CAS what LOOKS like 0.1 is ACTUALLY that huge mess internally (or 1.999999999998p-4 if you prefer hex). Why? Because that's the largest number less than or equal to 0.1 which can be represented in 48 bits.

If Prime's CAS had the LongFloat library implemented, the user would be able to set DIGITS:=45 and then obtain the CORRECT value of pi to all 45 places. Maybe some day!

[cyrille de brébisson]

Hello,

Indeed the CAS is designed to work with arbitrary precision floats.

The problem is that the various libraries that can be used by the CAS are either GPL or LGPL.

Since HP Prime is staticaly linked, we can not easely use such licenced libraries :-(

Cyrille

[salvomic]

(12-18-2017 05:07 AM)Joe Horn Wrote:  My "dec" program for the Prime does NOT perform extended-precision math. ...

If Prime's CAS had the LongFloat library implemented, the user would be able to set DIGITS:=45 and then obtain the CORRECT value of pi to all 45 places. Maybe some day!

(12-18-2017 06:31 AM)cyrille de brébisson Wrote:  Hello,

Indeed the CAS is designed to work with arbitrary precision floats.
The problem is that the various libraries that can be used by the CAS are either GPL or LGPL.
Since HP Prime is staticaly linked, we can not easely use such licenced libraries :-(

Cyrille

thanks Joe and Cyrille!
It's a pity that the Prime has not the long float library...

[cyrille de brébisson]

Hello,

Yep... If I had time, I would recreate one to use...
Maybe one of you guys could develop such a library and allow us to use it with a license that we can use in embedded systems...

Cyrille

[pier4r]

For such a thing there is the Berkeley license . Not that I like it, but it exists.

[salvomic]

(12-19-2017 06:13 AM)cyrille de brébisson Wrote:  Yep... If I had time, I would recreate one to use...
Maybe one of you guys could develop such a library and allow us to use it with a license that we can use in embedded systems...
Cyrille

(12-19-2017 06:17 AM)pier4r Wrote:  For such a thing there is the Berkeley license . Not that I like it, but it exists.

Thank you both!
I hope other people on the forum also would like to help to get this advisable enhancement

Salvo

[GregLewis]

A while back I worked on a project requiring more than 16 digits of precision. I found that both IBM and Intel have a decimal floating point library that works with 16 and 32 digits. The IBM library is called decNumber and includes a version under the GPL license and a version under the ICU license. I'm not familiar with the ICU license, but their web site says it's simpler and less restrictive. I could not find the license for the Intel code, but the site comes up when searching on "intel decimal floating point math library". Both sets of code are in C and includes the transcendental functions. I believe the Intel code includes additional functions such as gamma. As for a "free" floating point package, there's some projects under LibTomProjects. I believe LibTomMath is an extended integer library, but there's also a LibTomFloat library that is based on the integer code but is an arbitrary floating point library. On the downside, the LibTomFloat library is at version 0.02 and hasn't been updated since 2004. If someone were to build out a floating point library, that's probably a descent place to start given the code is free to use and modify without restrictions.

[Tim Wessman]

(12-19-2017 01:53 PM)GregLewis Wrote:  I believe LibTomMath is an extended integer library,

Yup, it is already in your Prime! :-)

We use that instead of the GNU libraries which are the "default" normal in the CAS. The CAS author would need to add support for using an additional library, but there don't seem to be any libraries we've found that can be incorporated into a single binary with the current limitations we face.

We would like to get arbitrary precision in at some point, but that depends on being able to find a compatible license, or get support for dynamic libraries which isn't really supported on the underlying hardware OS.

I don't think it would be great for example to support that on the pc versions, but not on the apple one, or hardware calcs. It really would be a large difference in capability and features not shared uniformly across platforms so I've not been excited to push for it until the licensing issues can be figured out.

[Stevetuc]

(12-19-2017 06:13 AM)cyrille de brébisson Wrote:  Hello,

Yep... If I had time, I would recreate one to use...
Maybe one of you guys could develop such a library and allow us to use it with a license that we can use in embedded systems...

Cyrille

http://www.boost.org/doc/libs/1_66_0/lib...index.html
The license for the Boost libraries look pretty straightforward. Not sure if the code is suitable for embedded systems (single executable)

[grsbanks]

There's also the Intel Decimal Floating Point library, which supports real numbers from 10^-6144 to 10^6143 with 34 digits of precision.

It's the library embedded into Free42-decimal (and consequently the SwissMicros DM42).

[salvomic]

(12-20-2017 08:33 AM)grsbanks Wrote:  There's also the Intel Decimal Floating Point library, which supports real numbers from 10^-6144 to 10^6143 with 34 digits of precision.

It's the library embedded into Free42-decimal (and consequently the SwissMicros DM42).

in fact my initial post was inspired by DM42 (I'm waiting for it) and Free42 (that I'm using often) and their 34 digit of precision...
OT: I'd like to get a real HP-42s also...

I'd like to see that precision also in the Prime.

Salvo

[Claudio L.]

(12-18-2017 06:31 AM)cyrille de brébisson Wrote:  The problem is that the various libraries that can be used by the CAS are either GPL or LGPL.

(12-19-2017 06:13 AM)cyrille de brébisson Wrote:  Maybe one of you guys could develop such a library and allow us to use it with a license that we can use in embedded systems...

Cyrille

I was faced with the same challenge for newRPL. To make it worse, I wanted a decimal library, not binary. I started using mpdecimal, which was released with the ICU license, and can be embedded just fine.
However, I wasn't happy with performance, so I rolled my own, and I added transcendental functions. It's BSD licensed, single file for basic operations, a couple extra files for transcendental functions. Zero external dependencies, doesn't even need malloc/free, just throw the files in your project, define a few constants and compile.
If it works for you, I don't mind.

EDIT: I think I got confused: decNumber is ICU licensed, mpdecimal is BSD licensed and widely used for python, if you prefer something more tested than newRPL's decimal library.

[pier4r]

right! There is the newRPL project (Claudio, much love!) that contains a lot of interesting solutions.