キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

Sorting a Table

解決済み
解決策を見る

Both methods have problems sorting numbers that have differing numbers of digits past the decimal point. For example, 10.425 becomes 10.000000425, while 10.422425 becomes 10.0000422425. That I can control easily by formatting any numbers with a fixed number of decimal places. 

But both methods also have trouble with negative numbers, and I haven't figured out how to fix that yet...

 

 

FlatCat_0-1768148994602.png

0 件の賞賛
メッセージ21/36
692件の閲覧回数

@FlatCat wrote:

Both methods have problems sorting numbers that have differing numbers of digits past the decimal point. For example, 10.425 becomes 10.000000425, while 10.422425 becomes 10.0000422425. That I can control easily by formatting any numbers with a fixed number of decimal places. 

But both methods also have trouble with negative numbers, and I haven't figured out how to fix that yet...

 

 

FlatCat_0-1768148994602.png


I never considered supporting fractional numbers.  (But I might start thinking about it.)

0 件の賞賛
メッセージ22/36
687件の閲覧回数

It is not expected to work with floating point numbers, but that can be solved once we know what's allowed.

 

Can we assume that your floating point fields don't have any alphabetic characters, or can they also be "mixed" (e.g. "10.456OHM" , "ABC=1.456", etc. "R.45AX:, etc.) Of course if they have an "E", they might be in exponential format.

 

Note that my sorting is most useful for filenames, mirroring the default behavior of windows explorer (e.g. file names have other periods, delimiting the file extension, so you need to be careful.)

 

0 件の賞賛
メッセージ23/36
681件の閲覧回数

If we can assume that floating point numbers are cleanly formatted, here's what you could do:

 

altenbach_0-1768154509698.png

 

 

 

altenbach_0-1768153177051.png

 

 

 

Basically, we check if scanning the fields as floating point gives no error or no remaining string. Please test! No guarantees. Works fine with negative numbers, integers, and floating point in any recognized format.

 

See below for even simpler code...

0 件の賞賛
メッセージ24/36
678件の閲覧回数

@altenbach wrote:

Yes, I got the gist of it from the picture

 

You are padding with spaces (i.e. a non-numeric character) while I am padding with zeroes (i.e. a numeric character)..

I am curious if there could be edge cases where it would make a difference, but haven't explored that.

 

One simplification would be to use the upper input of the format, eliminating your inner concatenation.

 

altenbach_0-1768150554547.png

 


I briefly thought about space vs zero, but quickly convinced myself that it would be OK.

0 件の賞賛
メッセージ25/36
673件の閲覧回数
解決策
受理者 FlatCat

It's probably sufficient just to check for error and switch mode when an error occurs:

 

altenbach_0-1768155843067.png

 

You might want to implement some error handling to ensure that all fields were processed with the same algorithm. (not shown).

メッセージ26/36
660件の閲覧回数

This works. But, as I mentioned a few comments back when I described my first solution, I actually know beforehand whether the chosen column contains purely numeric or alphanumeric data. So I can chose the method on that basis. But the error check is nice if I just want to go by the contents of the table itself. 

0 件の賞賛
メッセージ27/36
647件の閲覧回数

Try this.  Works with floats, scientifics, arbitrary number width.

0 件の賞賛
メッセージ28/36
611件の閲覧回数

Does not seem to work right with negative floats and thinks that negative numbers are largest.

 

altenbach_0-1768232526519.png

 

0 件の賞賛
メッセージ29/36
570件の閲覧回数

The version I did yesterday seems to work better.

 

altenbach_0-1768232817347.png

 

Also works correctly with +inf, -inf, NaN, etc.

 

altenbach_1-1768233902828.png

 

 

 

 

0 件の賞賛
メッセージ30/36
567件の閲覧回数