number format for prompts inconsistent with obase >10

[rtoy]

Imported from SourceForge on 2024-07-04 23:14:27 Created by peterpall on 2019-07-29 16:10:32 Original: https://sourceforge.net/p/maxima/bugs/3572

---

If obase is >10 the first prompts will be named %i0..9 or %o0..9 as normal. But then there will be a %i0A or a %o0A, while %i1A or %o1A won't start with a number. For the original report see https://github.com/wxMaxima-developers/wxmaxima/issues/1144

[rtoy]

Imported from SourceForge on 2024-07-04 23:14:28 Created by l_butler on 2019-07-31 03:32:26 Original: https://sourceforge.net/p/maxima/bugs/3572/#8a46

---

I don't think there is any inconsistency here. If you try to "fix" this, you will break concat for example:

obase:16$
makelist([k,concat('%i,k)],k,1,2*obase);

IMO Maxima is consistent here, and the user expectation is not. I think this should be marked as won't fix because it is not a bug.

[rtoy]

Imported from SourceForge on 2024-07-04 23:14:32 Created by robert_dodier on 2019-08-26 06:05:03 Original: https://sourceforge.net/p/maxima/bugs/3572/#de52

---

Yeah, I'm inclined to consider this "won't fix" because there's no requirements about the trailing part of labels; the labels work OK as identifiers whatever the value of obase.

I gather that wxMaxima has trouble with labels which have non-base-10 digits -- it appears that wxMaxima is making an unnecessarily restrictive assumption there. I am inclined to say that it should be fixed in wxMaxima.

Is there any way in which %i / %o labels are used in Maxima which requires the digits to be base-10? I can't think of anything, but I haven't thought about it too hard.

[rtoy]

Imported from SourceForge on 2024-07-04 23:14:35 Created by peterpall on 2019-08-26 09:55:58 Original: https://sourceforge.net/p/maxima/bugs/3572/#de52/c15c

---

In wxMaxima this is already fixed as I, too, am convinced that the program was too restrictive; With an "won't fix" I can live as I weren't completely sure if the inconsistency can be seen as an actual bug. If it should be to be fixed the inconsistency in leo's example would have to be fixed, too, naturally.

[rtoy]

Imported from SourceForge on 2024-07-04 23:14:39 Created by robert_dodier on 2019-08-27 04:56:48 Original: https://sourceforge.net/p/maxima/bugs/3572/#d266

---

• labels: --> obase, labels
• status: open --> wont-fix

[rtoy]

Imported from SourceForge on 2024-07-04 23:14:42 Created by robert_dodier on 2019-08-27 04:56:48 Original: https://sourceforge.net/p/maxima/bugs/3572/#b256

---

Closing this item as "won't fix" according to preceding discussion.