compile error in free42

[Steve Falco]

I just did a pull which includes commit dd501eb.  I am getting a compile error:

core_commands6.cc: In function ‘int mappable_log_c(Phloat, Phloat, Phloat*, Phlo
at*)’:
core_commands6.cc:378:17: error: no match for ‘operator<’ (operand types are ‘do
uble’ and ‘Phloat’)
 378 |         if (0.5 < h && h < 3.0)
     |             ~~~ ^ ~
     |             |     |
     |             |     Phloat
     |             double
core_commands6.cc: In function ‘int mappable_ln_c(Phloat, Phloat, Phloat*, Phloa
t*)’:
core_commands6.cc:517:17: error: no match for ‘operator<’ (operand types are ‘do
uble’ and ‘Phloat’)
 517 |         if (0.5 < h && h < 3.0)
     |             ~~~ ^ ~
     |             |     |
     |             |     Phloat
     |             double
At global scope:
cc1plus: note: unrecognized command-line option ‘-Wno-unknown-warning-option’ ma
y have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option ‘-Wno-sometimes-uninitialized’ m
ay have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option ‘-Wno-constant-conversion’ may h
ave been intended to silence earlier diagnostics

[Steve Falco]

Attached is a small patch for the compile error.

[Thomas Okken]

That code is work in progress; I'm not surprised it doesn't compile. The latest commit that should compile is the tag v3.1.3a.

[Steve Falco]

Ok - sorry for the noise.

[Thomas Okken]

No problem!

Most of the time, most commits will compile, but not always. Since I work on this project by myself, I'm not too concerned about creating branches for development. I do use branches for work that I expect to take a long time, so I'll still be able to get bug fixes out the door, but for things like this (see the two issues for Free42 in GitHub), I'll just commit unfinished work straight to master. If you want to get the latest code and be sure it actually works, checkout the latest tag.

[Steve Falco]

Understood.  Thanks!

[Thomas Okken]

Despite my rationale for sometimes having non-compiling code in master, I was curious why the current head revision wouldn't compile, since I do remember actually testing that code.

The reason: the code compiles and runs, but only if you build the binary version.

I usually build the binary version while I'm developing, because it's much easier to debug numerical code that way. In the binary version, a phloat is just a double, so it's easy to check its value in the debugger. In the decimal version, a phloat is a class that encapsulates a BID_UINT128, which is... not so easy to translate to a human-compatible number.

When I write code that compiles in binary but not in decimal, I will find out eventually. Specifically, when I'm building the release versions. In this case, I would have found out sooner, because I was going to test the decimal version of the new code specifically, but I was waiting for some feedback from Albert Chan about what I had written so far. (Albert Chan is the person who submitted the issue I'm working on at the moment. He is an absolute guru when it comes to numerical algorithms for complex numbers.)

None of which is meant to suggest that it's wrong to alert me when you think you've found a problem! I do appreciate it, in fact. But I thought I should explain what is going on with the code at this particular moment.

[Thomas Okken]

(Albert Chan is the person who submitted the issue I'm working on at the moment. He is an absolute guru when it comes to numerical algorithms for complex numbers.)

Not just complex numbers, actually. He has also contributed a lot to the TVM code in Plus42.

[Steve Falco]

Thanks for the info.  It is great that you are so attentive to issues, and that you continue to improve the algorithms, features, etc.