Feature Request: Handle different radices

38 views
Skip to first unread message

Tobias Johansson

unread,
Jan 25, 2012, 4:48:08 AM1/25/12
to last...@googlegroups.com
It would be very useful to be able to enter numbers in common radices other than decimal.
The most useful imo would be hexadecimal, binary and octal.

Tobias Johansson

unread,
Jan 25, 2012, 4:55:38 AM1/25/12
to last...@googlegroups.com
Along with this goes the ability to output results in a radix of choice

Ian Clarke

unread,
Jan 25, 2012, 8:46:06 AM1/25/12
to last...@googlegroups.com
Hmm, interesting, how would you like this to work?

For example, it could be that to convert a number to radix 8, you would do:

234 in/as/to radix 8

This would convert the decimal number 234 to radix 8, you could use either "in", "as", or "to".

The result of the conversion would be a string, I think.  Would you want to be able to do math with the result of the conversion?  That could be trickier.

Converting a string back to a decimal could be done using:

8f6 from radix 16

Would that make sense?

Ian.

On Wed, Jan 25, 2012 at 3:55 AM, Tobias Johansson <tobias.j.e...@gmail.com> wrote:
Along with this goes the ability to output results in a radix of choice



--
Ian Clarke
Message has been deleted
Message has been deleted

Tobias Johansson

unread,
Jan 25, 2012, 12:13:33 PM1/25/12
to last...@googlegroups.com
This is handled in many different ways in other tools/contexts.. 
The most natural to me is the way google calculator handles it (but it only allows for a fixed set of radices). Examples:

As for the type of these literals, they would always be used as the values that they represent. The only difference would be that they are parsed and rendered differently.

(dammit i'm not getting the links right..)

Ian Clarke

unread,
Jan 25, 2012, 3:26:57 PM1/25/12
to last...@googlegroups.com
Yes, that does make sense.

How much does it matter to be limited to, say, binary, octal, decimal, and hex?

Google relies on the various syntaxes like 0x… and 0o… and others to indicate that a number is in a non-decimal format (as does Java for that matter).  I'm wondering if this is the best approach, as opposed to specifying the type more explicitly.  There is a tension with LastCalc between what is familiar to programmers, and the desire to keep it accessible to non-programmers.  I guess if you're dealing with non-base-10 radices then you're probably a programmer though.

It seems like the best approach internally would be to create a radix "wrapper" class for LargeIntegers, that the various math functions understand how to unwrap and re-wrap (if both a and be are of a particular radix then the result should be the same radix, however if they are different radices then the result should probably be decimal, I think).

Thoughts?

Ian.

On Wed, Jan 25, 2012 at 11:08 AM, Tobias Johansson <tobias.j.e...@gmail.com> wrote:
This is handled in many different ways in other tools/contexts.. 

As for the type of these literals, they would always be used as the values that they represent. The only difference would be that they are parsed and rendered differently.

--
You received this message because you are subscribed to the LastCalc Group
http://groups.google.com/group/lastcalc?hl=en?hl=en

--
Ian Clarke

Tobias Johansson

unread,
Jan 25, 2012, 4:26:33 PM1/25/12
to last...@googlegroups.com


On Wednesday, January 25, 2012 9:26:57 PM UTC+1, Ian (LastCalc author) wrote:
Yes, that does make sense.

How much does it matter to be limited to, say, binary, octal, decimal, and hex?
 
Those four are by a very long way the most common, so I say that the best approach would be to include the format for those hard in the syntax in some form (ie like google and many languages before them: "0x.., 0o.., 0b.."). The gain in having additional syntax for representing numbers in arbitrary radix, I think, is very small.
 
Google relies on the various syntaxes like 0x… and 0o… and others to indicate that a number is in a non-decimal format (as does Java for that matter).  I'm wondering if this is the best approach, as opposed to specifying the type more explicitly.  There is a tension with LastCalc between what is familiar to programmers, and the desire to keep it accessible to non-programmers.  I guess if you're dealing with non-base-10 radices then you're probably a programmer though.
 
It seems like the best approach internally would be to create a radix "wrapper" class for LargeIntegers, that the various math functions understand how to unwrap and re-wrap (if both a and be are of a particular radix then the result should be the same radix, however if they are different radices then the result should probably be decimal, I think).

I'd say a common pattern for doing this is to parse the values up front before the entered string is evaluated and extract the values into some internal format, forgetting everything about the concrete syntax (like radix etc.) (or perhaps referencing it somehow). This creates a nice separation of the the concrete syntax (the actual characters of the string) from the abstract syntax (the structure of the statement) and the evaluation thereof.
But that is all up to you :) 

/Tobias

Ian Clarke

unread,
Jan 25, 2012, 4:48:11 PM1/25/12
to last...@googlegroups.com
On Wed, Jan 25, 2012 at 3:26 PM, Tobias Johansson <tobias.j.e...@gmail.com> wrote:
I'd say a common pattern for doing this is to parse the values up front before the entered string is evaluated and extract the values into some internal format, forgetting everything about the concrete syntax (like radix etc.) (or perhaps referencing it somehow). This creates a nice separation of the the concrete syntax (the actual characters of the string) from the abstract syntax (the structure of the statement) and the evaluation thereof.
But that is all up to you :) 

Yes, I think I now have an idea of the right™ way to do this.  I'll try to get to it this afternoon.

Ian.

Ian Clarke

unread,
Jan 25, 2012, 6:01:06 PM1/25/12
to last...@googlegroups.com
Ok, it's done, you can try:

 (0x1b + 0o20 + 0b101) in bin
 (0x1b + 0o20 + 0b101) in hex
 (0x1b + 0o20 + 0b101) in dec
 (0x1b + 0o20 + 0b101) in oct

You can also use "binary", "hexadecimal", "decimal" and "octal" if you wish.

Tobias Johansson

unread,
Jan 25, 2012, 6:48:14 PM1/25/12
to last...@googlegroups.com
Great! works like a charm!
Reply all
Reply to author
Forward
0 new messages