0

Currently, something like 0.9*120 returns 1.08+2 whereas I'd like to set the default for all numbers to be returned in non-scientific notation.

I found fix in the documentation; however, this solution is only appropriate for integer values.

I found some old posts on the Maxima mailing list on source forge, but the suggestion is to use printf with ~f -- is there no way to make this the default format? or does one really have to convert every value, individually?

Rax Adaam
  • 790
  • 3
  • 11
  • Hmm, I don't see that. When I enter `0.9*120;` in wxMaxima, the result which is displayed is `108.0`. Have you changed any display settings? In the function called to format floats for display, both in wxMaxima and command line Maxima, floats are printed without scientific notation for 0.001 <= x <= 10000000.0, and with scientific notation otherwise. Are you looking at the wxMaxima display or some other output? Maybe an example will help illustrate the problem. – Robert Dodier Jun 06 '21 at 07:08
  • Thanks Robert -- it seems our system admin had changed the defaults for `pfprec` to 4 and `fpprintprec` to 3, and I wasn't aware that they had been changed from the defaults. Sorry about that: I should've verified on (wx)Maxima before posting, I didn't expect these defaults to have been modified, but I'll be sure to double check, in the future, before posting :) I assume that this is the expected behaviour, with those changes to the settings (& will verify on the terminal version). Thanks for your help. Hope all is well! – Rax Adaam Jun 12 '21 at 14:36
  • @RobertDodier is it possible to have values > 10000000.0 print without scientific notation? `fpprintprec` doesn't seem like the relevant command for this, but I couldn't find anything else in the docs. – Rax Adaam Dec 15 '21 at 18:49
  • I looked at the code in question and the limits for the format with `nnne-nn` and `nnne+nn` are fixed at 0.001 and 1e7. Working around that could be pretty involved. Maybe the simplest way is to convert to an integer via `round` and display that. Changing the limits seems like a good feature to have; let me think about it. – Robert Dodier Dec 15 '21 at 19:04
  • Thank you @RobertDodier! `round` worked for me. This came up while generating data for visualizations, so I had to use an if-statement, so as not to round small values, but the combination worked perfectly. Thanks for the suggestion -- I don't think I would've thought of that on my own (for some reason I assumed integers would be truncated the same way; probably because I was thinking of it as a display-related issue) – Rax Adaam Dec 16 '21 at 20:48
  • @RobertDodier is there any way to distinguish between terminating floating points & non-terminating floating points? Or, alternatively, to have the same number of digits printed, in either case? e.g. getting `0.200 000` instead of `0.2` so that the precision implied is the same for every value in a table? – Rax Adaam Dec 24 '21 at 16:38
  • There isn't a way to distinguish terminating and nonterminating decimals, but about the second point, you can have the same number of decimals printed. There is a Lisp flag which you can disable in order to leave trailing 0's in place, namely `:lisp (setq *exploden-strip-float-zeros* nil)`. Also set `fpprintprec` to the number of decimals you want. If the `:lisp` is hard to work with, let me know and we'll try to figure out something else. Let me ask you this, are you working with any Lisp code (either via `:lisp` or any other means) at present? – Robert Dodier Dec 24 '21 at 18:51
  • @RobertDodier Thank you, that's very helpful! I'll see if our programmer can add this to our setup; I don't see why there'd be any issue. RE: working with lisp, ATM our parser is home-made and suffers from many limitations, including not supporting `:lisp` commands, so no, I'm not working with it very much -- any reason you ask? – Rax Adaam Dec 29 '21 at 17:47
  • Re: Lisp, the reason I ask is that Lisp code can be input into Maxima either via `:lisp` in the Maxima console or a batch file, or in a file of only Lisp code and loaded via `load("myfile.lisp");`. You mentioned `:lisp` isn't available, in that case you can put that one line of code (I mean the `(setq ...)` bit above) into a file and load it. – Robert Dodier Dec 29 '21 at 19:01
  • @RobertDodier -- sorry, I should've been more clear: it's not available to me in our editor for creating content, but it can be added directly to the files on the server, without any problem. I think we're going to do an overhaul of our tech stack in a few months so that these kinds of things aren't an issue -- the parser has been esp. problematic & I keep crashing the server :\ Thanks again. Hope all is well on your end! – Rax Adaam Dec 29 '21 at 19:07

1 Answers1

0

In my case, the defaults for the floating-point precision fpprec and the floating-point print precision fpprintprec had been changed by our system administrator, and I wasn't aware. Changing their values back to the default resolved the issue.

The defaults, according to the documentation, at the time of writing, are:

  • fpprec:16;
  • fpprintprec:0

As the documentation for fpprintprec explains:

For ordinary floating point numbers, when fpprintprec has a value between 2 and 16 (inclusive), the number of digits printed is equal to fpprintprec. Otherwise, fpprintprec is 0, or greater than 16, and the number of digits printed is 16.

Rax Adaam
  • 790
  • 3
  • 11