What about the latest Update?

Discussion around the Swiss Micros DM42 calculator.
Post Reply
zeno333
Posts: 63
Joined: Fri Dec 29, 2017 12:34 am

What about the latest Update?

Post by zeno333 » Thu Jul 11, 2019 11:21 pm

On July 8th, there was a DMCP update posted for version 3.14, but the DM42 was not updated and remains at version 3.13...Should we just update the DMCP now, or should we wait for a DM42 update to come later??? Also, there is no notification of the DMCP 3.14 update in the forum new update notification area...is that because there are more updates for DM42 coming???

grsbanks
Posts: 847
Joined: Tue Apr 25, 2017 9:23 am
Location: Preston, Lancs, UK
Contact:

Re: What about the latest Update?

Post by grsbanks » Fri Jul 12, 2019 8:09 am

Yes, there is an update coming soon.
Not SwissMicros staff, just an enthusiast.

Thomas Okken
Posts: 589
Joined: Tue May 02, 2017 3:48 pm
Location: New Jersey, USA
Contact:

Re: What about the latest Update?

Post by Thomas Okken » Sun Jul 14, 2019 11:04 pm

Will that update include Free42 2.4.2? You mentioned some time ago that you were testing an update that included 2.2, and most of the Free42 updates since then have included only platform-specific updates and fixes, so no changes to the core, but 2.4 introduced configurable word size for BASE, and that would be nice to have in the DM42 as well.

N.B. I'm not aware of any bugs at the moment, and the only work I have planned is state file switching, which of course the DM42 has already. My implementation will be a bit different: I want to split the core and shell state into separate files, and change the core state format to something platform-independent, to allow sharing states between instances of Free42 running on different platforms. But I'm not going to be working on that very soon, probably sometime this fall or even later.

jch
Posts: 40
Joined: Fri Apr 28, 2017 7:11 am
Location: France

Re: What about the latest Update?

Post by jch » Mon Jul 15, 2019 7:46 pm

Thomas Okken wrote:
Sun Jul 14, 2019 11:04 pm
My implementation will be a bit different: I want to split the core and shell state into separate files, and change the core state format to something platform-independent, to allow sharing states between instances of Free42 running on different platforms. But I'm not going to be working on that very soon, probably sometime this fall or even later.
Hi Thomas,

I know this was on your todo list a long time ago.
So I have played with this idea since some time, still work in progress but I'm in the final step to have a platform (well only Android and Windows yet) independant state file.
You may have a look at my work there.

Cheers.
Jean-Christophe.
jch
DM42 Beta sn:00050

Thomas Okken
Posts: 589
Joined: Tue May 02, 2017 3:48 pm
Location: New Jersey, USA
Contact:

Re: What about the latest Update?

Post by Thomas Okken » Mon Jul 15, 2019 10:02 pm

Hmmm. I was thinking of using EBML as the basis of the state file at first, but when I started thinking about platform-neutral state files again a few weeks ago, it occurred to me that EBML may be overkill. It offers a degree of flexibility that Free42 doesn't really need, and that flexibility comes at a cost in terms of code complexity.

My thought right now is that the existing format is basically OK. It just needs to be modified so that the way integers, floats, and structures are stored does not depend on the platform's word size, endianness, and structure alignment. That could be achieved using EBML-like variable-length fields, without going all-out and using an actual EBML dialect. Or by using fixed-size fields and simply standardizing on certain field sizes.

But nothing is decided yet. I'll take a look at your code later, probably this weekend. Maybe I do like the idea of using EBML after all.

toml_12953
Posts: 507
Joined: Wed May 03, 2017 5:46 pm
Location: Malone, NY USA

Re: What about the latest Update?

Post by toml_12953 » Mon Jul 15, 2019 10:30 pm

Thomas Okken wrote:
Mon Jul 15, 2019 10:02 pm
Hmmm. I was thinking of using EBML as the basis of the state file at first, but when I started thinking about platform-neutral state files again a few weeks ago, it occurred to me that EBML may be overkill. It offers a degree of flexibility that Free42 doesn't really need, and that flexibility comes at a cost in terms of code complexity.

My thought right now is that the existing format is basically OK. It just needs to be modified so that the way integers, floats, and structures are stored does not depend on the platform's word size, endianness, and structure alignment. That could be achieved using EBML-like variable-length fields, without going all-out and using an actual EBML dialect. Or by using fixed-size fields and simply standardizing on certain field sizes.

But nothing is decided yet. I'll take a look at your code later, probably this weekend. Maybe I do like the idea of using EBML after all.
As long as you're looking at a substantial change, have you read about posits? Supposedly better and faster than the IEEE 754 floating point standard while using fewer bits and needing no modification to source code! It sounds too good to be true to me but I haven't read the whole article yet.

https://www.nextplatform.com/2019/07/08 ... mputation/
Tom L

Nerd Emeritus

DM42 SN: 00025 (Beta)
SN: 00221 (Shipping)

Thomas Okken
Posts: 589
Joined: Tue May 02, 2017 3:48 pm
Location: New Jersey, USA
Contact:

Re: What about the latest Update?

Post by Thomas Okken » Mon Jul 15, 2019 11:21 pm

toml_12953 wrote:
Mon Jul 15, 2019 10:30 pm
have you read about posits?
As a matter of fact, I have -- about an hour ago, on the MoHPC forum. :D It does sound too good to be true, and besides, the Intel library seems to me to be good enough™ for a calculator.

In principle, plugging in a different floating-point library in Free42 is easy, as long as it provides the full set of transcendental functions, including hyperbolics and gamma. The devil is in the details: number entry, number ↔ string conversion, and dealing with numbers in programs when loading a state file written by a version of Free42 using a different floating-point system.

Post Reply