Open rtoy opened 3 months ago
Imported from SourceForge on 2024-07-08 21:12:38 Created by robert_dodier on 2022-06-23 20:14:11 Original: https://sourceforge.net/p/maxima/bugs/3995/#05ed
Hi Jimis, thanks for your interest in Maxima. Do I understand correctly that you are creating the data file which is later to be read back into Maxima? i.e., you are not reading a file that was created by someone else using some system other than Maxima.
Imported from SourceForge on 2024-07-08 21:12:41 Created by jimishol on 2022-06-23 21:47:05 Original: https://sourceforge.net/p/maxima/bugs/3995/#d8bd
Thank you for the quick reply. You understand well. I make a list with maxima, i store it and then read it back. As in the example. Since i worked around it, it is not a big problem for me but i wanted to inform developers that i expected a 'correct' for me behavior that would be x[5]=y[5] in the above case. Thank you
Imported from SourceForge on 2024-07-08 21:12:45 Created by jimishol on 2022-06-23 22:00:20 Original: https://sourceforge.net/p/maxima/bugs/3995/#05ed/ed18
Thank you for the quick reply. You understand well. I make a list with maxima, i store and then read back. As in the example. Since i worked around it, it is not a big problem but i wanted to inform developers that i expected a 'correct' for me behaviour. Thank you
Imported from SourceForge on 2024-07-08 21:12:49 Created by macrakis on 2022-06-23 23:07:48 Original: https://sourceforge.net/p/maxima/bugs/3995/#eee2
The documentation of read_list is very poor, so it's hard to know what it's supposed to be doing.
The intent seems to be to read the input file as a series of Maxima tokens . This is stated nowhere in the documentation. It parses tokens greedily, and does not require a separator between tokens. Numerical tokens are interpreted as numbers, and all others are interpreted as strings. Note that Maxima syntax considers the rational number 1/2 to be composed of three tokens, not one.
For example:
abc => ["abc"]
abc123 => ["abc123"]
123abc => [123, "abc"]
2..3 => [2, 0.3]
2...3 => [2, ".", 0.3]
2e3 => [2000.0]
1/2 => [1, "/", "2"] <<< these are three Maxima tokens
1//2 => [1, "/", "/", 2]
1^^2 => [1, "^^", 2] << ^^ is a single Maxima token
It gives errors for the following cases, because it expects an exponent:
2e => error
2e* => error
It doesn't clean up state correctly after errors:
2e* => error
x => ["*", "x"]
Apparently the lookahead character stays in the input buffer. The other behavior we can consider strange; this one is clearly a bug.
This behavior seems very idiosyncratic, and I have no idea why anyone would find it useful, but that's what it does.
So I guess this is "not a bug", though the documentation clearly needs to be improved.
Imported from SourceForge on 2024-07-08 21:12:52 Created by peterpall on 2022-06-24 05:09:37 Original: https://sourceforge.net/p/maxima/bugs/3995/#e231
I believe read_list currently only reads floating -point numbers. If you want more flexibility you can use openr read_line, schoncat and Close in order to write a function that reads in comma-separated maxima commands.
Imported from SourceForge on 2024-07-08 21:12:37 Created by jimishol on 2022-06-23 11:47:38 Original: https://sourceforge.net/p/maxima/bugs/3995
read_list or read_nested_list functions do not work as expected, when object includes operands. I may use these functions wrongly but for now my workaround is to store strings and evaluate those strings later. In next simple example i expected x to be equal to y but 5th element 1/3 is not loaded correctly . By my workaround z is actually equal to x. Here is the simple example: